Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[swiftc/msvc] Compiling with MSVC library #1516

Merged
merged 1 commit into from Jul 9, 2016

Conversation

tinysun212
Copy link
Contributor

@tinysun212 tinysun212 commented Mar 2, 2016

What's in this pull request?

Some modifications for the ms-extension option of the clang.exe in the Visual Studio 2015 development environment

This patch is only for swiftc.exe. For the standard library or build script, other PR's will be used in later.
I used the library set of Visual Studio 2015 Update 1 and recent version of swift-clang as the compiler. If you are using the real MSVC compiler, more patch might be required.

Related bug number: (SR-34) Port Swift to Windows


Before merging this pull request to apple/swift repository:

  • Test pull request on Swift continuous integration.

Triggering Swift CI

The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:

Smoke Testing

Platform Comment
All supported platforms @swift-ci Please smoke test
OS X platform @swift-ci Please smoke test OS X platform
Linux platform @swift-ci Please smoke test Linux platform

Validation Testing

Platform Comment
All supported platforms @swift-ci Please test
OS X platform @swift-ci Please test OS X platform
Linux platform @swift-ci Please test Linux platform

Note: Only members of the Apple organization can trigger swift-ci.

#include <cstdlib>
#endif

namespace swift {

// FIXME: Use C11 aligned_alloc or Windows _aligned_malloc if available.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can trim down this fixme a bit now.

@gribozavr
Copy link
Collaborator

Some modifications for the ms-compatibility mode of the clang-cl.exe in the Visual Studio 2015 development environment

Why is that interesting to support? If you can use clang, why not use clang in its native mode?

@tinysun212
Copy link
Contributor Author

For build and link with MS C runtime library, including their headers are necessary. Without ms-compatibility mode, they are cannot be compiled.

@jckarter
Copy link
Member

jckarter commented Mar 2, 2016

Could we use native Clang mode for swiftc, but MS compatibility mode for the runtime?

@jckarter
Copy link
Member

jckarter commented Mar 2, 2016

Or could we avoid needing to parse Visual C++'s libraries by using libc++? Do pure C windows.h-level headers really need MSVC compatibility?

@tinysun212
Copy link
Contributor Author

I'm confused about options in comments.
I enabled two options -fms-extension, -fms-compatibility. The former required for understanding MS includes (even for stdio.h). I'll check if any issue occurs when the latter option is removed.

@jckarter
Copy link
Member

jckarter commented Mar 3, 2016

Sounds good. AIUI -fms-extension should be fine, since that enables purely additive MSVC features, whereas -fms-compatibility causes Clang to deliberately emulate MSVC bugs. We'd prefer not to have to deal with the latter.

@tinysun212
Copy link
Contributor Author

After remove -fms-compatibility option, some files can be removed from PR. Also, I modified some comments and rebranched.


#if defined(_MSC_VER)
#include "Windows.h"
#define dlopen(x, y) LoadLibrary(x)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of a macro, can we use a wrapper function with a conditional implementation?

@tinysun212 tinysun212 changed the title [swiftc/msvc] Compiling with MSVC [swiftc/msvc] Compiling with MSVC library Mar 4, 2016
@tinysun212
Copy link
Contributor Author

After removing -fms-compatablitity-version=19, return { }; in ClangImporter.cpp is revoked. I think the option is not ignored even if -fno-ms-compatibility was used.

But the patch which the [](){} are required in ConstantPropagation.cpp could not be revoked by removing the option. I think it is related to the <functional> header implemention.

Two or more default parameters of functional in constructor were not resolved. Removing ifdefs in ConstantPropagation.cpp, I changed one constructor of three default parameters in Local.h to two constructors of one default parameter.

@tinysun212
Copy link
Contributor Author

For the patch of ConstantPropagation.cpp, I'll check more if it can be revoked.

@tinysun212
Copy link
Contributor Author

The error of return { }; in ClangImporter.cpp was not for the bug emulation in ms-compatibility. I think it was the difference between c++11 and c++14. I wrote following simple code and tested it.

tt.cpp
------

enum class MyType { SampleValue };

class Opt {
public:
    explicit Opt() {}
};

struct Astr {
    MyType  myt = MyType::SampleValue;
    Opt  opt;
};

Astr Foo2() {
    return{};
}
$ clang++ -c  tt.cpp  -std=c++11   -->  NO ERROR
$ clang++ -c  tt.cpp  -std=c++14
tt.cpp:15:9: error: chosen constructor is explicit in copy-initialization
        return{};
               ^
tt.cpp:6:11: note: constructor declared here
        explicit Opt() {}
                 ^
tt.cpp:11:7: note: in implicit initialization of field 'opt' with omitted initializer
        Opt  opt;
             ^
1 error generated.

By verifying clang -v, when the -fms-compatablitity-version=19 option is used, clang driver inserted -std=c++14 option to the fronted.

Anyway, we will not use the compatibility option, no problem.

@tinysun212
Copy link
Contributor Author

For the patch of ConstantPropagation.cpp, it can be revoked, but has a little problem.

I have two clang version for Windows.
One is the clang.exe I built from swift-clang repository, and I made this PR with it.
Other is the clang 3.7 with MS CodeGen which released by MS last year.

MS clang and MS cl compiler recognize well two or more functional default parameter in constructor.
But my clang was not recognize it. I think MS clang has some different code not yet applied to swift-clang.

I cannot use MS clang for ConstantPropagation.cpp now, it generates a fatal error at other position instead. I want to keep this patch.

@gottesmm
Copy link
Member

gottesmm commented Mar 7, 2016

@tinysun212 Can you smoosh together the patches?

@gribozavr
Copy link
Collaborator

Do we really need to make any changes to the compiler? Why can't we use clang.exe to build the compiler, and clang-cl.exe to build the runtime?

@stefanstefan2001
Copy link

Ping?

@tinysun212
Copy link
Contributor Author

@jxyang has more changes than me in his repository.

@tinysun212
Copy link
Contributor Author

@gribozavr, The difference between clang.exe and clang-cl.exe is the driver options for clang frontend. Anyway, this PR is suitable to clang.exe with the option -fms-extension and not use'-fms-compatibility. In clang-cl.exe, both of them are enabled.

To build the compiler swift.exe on Windows (MSVC, not Cygwin), we should use the MS standard C++ library and headers. We can not drop the option -fms-extension because the library can't be used without the option.

Unfortunately, the option -fms-extension caused some code changes, but this is the minimum patch to build the compiler on Windows.

@tinysun212
Copy link
Contributor Author

ping?

@CodaFi
Copy link
Member

CodaFi commented Jul 6, 2016

@tinysun212 It looks like you have merge conflicts. Could you please rebase onto master.

@@ -23,7 +23,7 @@ using namespace swift;
using namespace swift::sys;

// Include the correct TaskQueue implementation.
#if LLVM_ON_UNIX && !defined(__CYGWIN__)
#if LLVM_ON_UNIX && !defined(__CYGWIN__) && !defined(_MSC_VER)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is LLVM_ON_UNIX even set for MSVC?

@tinysun212
Copy link
Contributor Author

@CodaFi, @jrose-apple, thanks for your reviews, it is rebased and changed.

@@ -485,14 +485,18 @@ class CastOptimizer {

public:
CastOptimizer(std::function<void (SILInstruction *I, ValueBase *V)> ReplaceInstUsesAction,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can I ask why this change was necessary?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the clang with the ms-extension option (not ms-compatibility option), the line of the constructor having two default value of dummy lambda expression is compiled, but three default value constructor is not compiled.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's very strange. Mind leaving a comment before I merge?

@jrose-apple
Copy link
Contributor

Looks reasonable to me. Thanks, @tinysun212!

@swift-ci Please test

Some modifications for the ms-extension option of the clang.exe in the Visual Studio 2015 development environment

This patch is only for swiftc.exe. I used the library set of Visual Studio 2015 Update 1 and recent version of swift-clang as the compiler. If you are using the real MSVC compiler, more patch might be required.
@tinysun212
Copy link
Contributor Author

@jrose-apple, I applied your reviews.

@jrose-apple jrose-apple merged commit cccfbf4 into apple:master Jul 9, 2016
@jrose-apple
Copy link
Contributor

Thanks, merged!

@tinysun212
Copy link
Contributor Author

Thanks, this merging I have long awaited. ^^

@tinysun212 tinysun212 deleted the pr-swiftc-msvc-1 branch October 21, 2018 00:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants