Port swift/basic to Windows using MSVC#5949
Conversation
There was a problem hiding this comment.
What if you are using msvcprt with clang-cl?
There was a problem hiding this comment.
Right, that was my concern. Would || (defined(_MSC_VER) && !defined(__clang__) work? I dunno how to detect clang-cl!
Maybe its a version thing - we should check _MSC_VER >= X?
There was a problem hiding this comment.
The value for _MSC_VER will be the same across clang and clang-cl. What exactly are you trying to protect against?
There was a problem hiding this comment.
Well if we don't have this check, I get a fatal error saying "not implemented" at compile time. We need this, but need to figure out how to detect msvcprt
There was a problem hiding this comment.
Okay - I've addressed this by changing it to:
#if _LIBCPP_VERSION || (defined(_MSC_VER) && !defined(__clang__))
There was a problem hiding this comment.
This works, since this works __has_feature(is_trivially_copyable) with clang-cl
There was a problem hiding this comment.
Why the additional _WIN32 check?
There was a problem hiding this comment.
no idea, I'll remove when we get a better idea about the other stuff
There was a problem hiding this comment.
Hmm, I wonder if there is a better way to handle this. Something like using a __pragma(warning(supress:????)))). In that case, we could have a SWIFT_USED macro.
There was a problem hiding this comment.
This is the only place __attribute((used)) is used in the entire library I think, so I'm not sure its worth the effort!
There was a problem hiding this comment.
What does LLVM_ATTRIBUTE_USED do?
There was a problem hiding this comment.
Might be nice to #define WIN32_LEAN_AND_MEAN here.
There was a problem hiding this comment.
cleanliness and consistency
There was a problem hiding this comment.
The old way is meant to show #if nesting.
There was a problem hiding this comment.
right - will revert.
|
I believe that the only place we use UUIDs in the compiler is to print "opened archetypes" in SIL in a way that lets them be reliably parsed back as unique types. We could probably use a better uniquing scheme in SIL printing now that we have better tracking of opened type uses in SIL, and kill the UUID dependency. |
|
@hughbe Sure, no problem. |
|
@jckarter what exactly did you have in mind for replacing the naming scheme with? It sounds simple enough that I might be able to take that on. |
There was a problem hiding this comment.
Nitpick: comments should end with periods. (Although I don't really think you need this one; the alternate formulation isn't so bad that anyone would be tempted to change it.)
There was a problem hiding this comment.
Removed the comment as suggested.
There was a problem hiding this comment.
No need for the comment here.
There was a problem hiding this comment.
memcpy already takes a void *, so you don't need this.
There was a problem hiding this comment.
I'm not sure I can entirely remove this. We use this conversion union in methods such as UUIDCompare and UUIDToString that require a UUID passed. I have removed all the conversions from memcpy though as you suggested.
There was a problem hiding this comment.
Either ::UUID is a POD type, in which case you can just memcpy into one directly, or it's not, in which case the union isn't safe either.
There was a problem hiding this comment.
I had no idea you can just memcpy like that - you learn something new everyday:
This works, and the file builds, so we're good:
#include <rpc.h>
int main()
{
::UUID uuid1;
unsigned char data[16] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 };
memcpy(&uuid1, data, 16);
// uuid1 = {04030201-0605-0807-090A-0B0C0D0E0F10}
return 0;
}
There was a problem hiding this comment.
Hm. This isn't 100% correct, then, because these files won't exist when the source root isn't a Git or SVN repo. Maybe we should just have CMake generate empty files in those cases?
There was a problem hiding this comment.
Strange - I see lines in the build log on Windows saying "Generating LLVMRevision.inc" etc. etc. for each file. Seems like CMake already does this and has already generated these files by the time Version.cpp is built.
There was a problem hiding this comment.
It only does that if you're in a checkout of a Git or SVN repo.
There was a problem hiding this comment.
Ah I understand now. I've modified lib/Basic/CMakeLists.txt file to generate an empty file if these files are not found. I've made it a seperate commit because its not necessarily Windows/MSVC specific.
There was a problem hiding this comment.
These shouldn't be necessary now, since we decided to allow unknown pragmas.
There was a problem hiding this comment.
(If we did have them, we should check for Clang instead of for !MSVC.)
There was a problem hiding this comment.
Either ::UUID is a POD type, in which case you can just memcpy into one directly, or it's not, in which case the union isn't safe either.
|
@swift-ci Please smoke test and merge |
|
Also this one didn't merge although tests passed |
|
sigh |
| } | ||
|
|
||
| using iterator = typename decltype(Data)::iterator; | ||
| using iterator = typename ArrayRef<PtrTy>::iterator; |
There was a problem hiding this comment.
| static const size_t Size = (sizeof(void*) - 1) / sizeof(Chunk); | ||
| static const size_t ActualSize = max<size_t>(Size, 1); | ||
|
|
||
| using MapBase = PrefixMap<Chunk, ValueType, ActualSize>; |
There was a problem hiding this comment.
|
|
||
| public: | ||
| using SequenceIterator = EncodedSequence::iterator; | ||
| using SequenceIterator = typename EncodedSequence::iterator; |
There was a problem hiding this comment.
This seems to be a Clang deficiency rather than an MSVC deficiency
There was a problem hiding this comment.
Agreed, typename ought to be required by the standard. (Assuming EncodedSequence is dependent, of course.)
The UUID stuff is the heart of this PR, and relies on linking rpcrt4.lib, found in #5904. We can merge these PRs in any order, however.
The only limitation is that we can't generate a UUID based on the current time, but this isn't terrible.