[swiftc/msvc] Compiling with MSVC library

[tinysun212]

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.

[jckarter]

You can trim down this fixme a bit now.

[gribozavr]

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]

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

[jckarter]

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

[jckarter]

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]

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]

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]

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

[jckarter]

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

[tinysun212]

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]

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

[tinysun212]

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]

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]

@tinysun212 Can you smoosh together the patches?

[gribozavr]

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]

Ping?

[tinysun212]

@jxyang has more changes than me in his repository.

[tinysun212]

@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]

ping?

[CodaFi]

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

[jrose-apple]

Why is LLVM_ON_UNIX even set for MSVC?

[tinysun212]

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

[jrose-apple]

Can I ask why this change was necessary?

[tinysun212]

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.

[jrose-apple]

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

[jrose-apple]

Looks reasonable to me. Thanks, @tinysun212!

@swift-ci Please test

[tinysun212]

@jrose-apple, I applied your reviews.

[jrose-apple]

Thanks, merged!

[tinysun212]

Thanks, this merging I have long awaited. ^^