Rewrite the VS Integration Scripts

[zturner]

Summary

Not sure who knows MSBuild, so I'm adding several random people in hopes that someone can review this.

I expect this to need to go through a couple of iterations, but this represents a complete re-write of the Clang Visual Studio Integration. I'll try to summarize the high level differences between how this works now and how it used to work, as well as mention some future work I think we should do:

1. Previously we would install into %ProgramFiles%\MSBuild. At least with 2017, this no longer appears to be what you do. You now have to install to the VS instance. Rather than try to detect Installed VS Instances from a batch file, for now I just hardcode the path to the default installation path, and in follow-up patches we can port this to using a VSIX installer, which should handle all of this for us.

2. Previously we had separate .props and .targets files for every version of VS. This turns out to be unnecessary, so all of those have been removed and now there is just 1. The good news is that this means we should continue to work in subsequent versions of VS without any additional maintenance.

3. Previously would do a configure-style modification of the props and targets file to fill in with compile time values. The only one of these that's tricky is the LLVM Version number, the rest are already available via existing MSBuild substitutions. So all of those are fixed, and to handle the version number the installer is updated to write an additional value to the registry, which the MSBuild files pull. Decoupling these values from the particular build of LLVM opens the door for us to be able to package this in a VSIX and distribute it on the marketplace and update it independently of the actual toolchain.

4. An xml file is provided to present a custom view of compiler options (e.g. Project > Properties > C/C++). Options we don't support or ignore are grouped together under special tabs in the UI, while the settings we do support are in the original locations. This is done because we additionally will now warn (or error) on certain options which could have been enabled in a project prior to changing the toolset, and we like to be able to point the user exactly to which setting to change to silence the warning / error.

5. Previously we would copy clang-cl.exe to $(InstallDir)\bin\cl.exe because this is how MSBuild would find the compiler. This is now fixed so that it locates clang-cl.exe directly.

6. Options that we ignore are now not even passed to clang-cl. This might seem unimportant because if we ignore the option, there's no harm in passing it in. But some of these options trigger additional MSBuild logic that happens before the compiler even has a chance to run. For example, in llvm.org/pr36140, a user noted that using /Zi triggered a full rebuild every time, even if nothing changed. In any case, having smaller command lines makes for easier diagnostics. An additional side benefit of this is that whereas before you would get lots of -Wunused-command-line-argument warnings, now there will be no such warnings.

Future Work (in rough order of priority):

1. Wrap this all in a VSIX so that it can be properly installed, instead of relying on batch file hackery.
2. Expose all of clang warnings through a custom UI page.
3. Expose all of clang optimizations through a custom UI page.
4. Replace link.exe with lld-link.exe similar to how we currently replace cl.exe with clang-cl.exe
5. Install a clang platform (in additional to a platform toolset), so that we have Clang (x86) and Clang (x64) platforms for people to enable building side-by-side configurations.
6. Add a Clang (Cross-Platform) platform that exposes the clang++ driver in all of its glory and allows the user to set the target triple.

[zturner]

+asmith

[hans]

llvm/tools/msbuild/Clang.Cpp.Common.props

41 ↗

(On Diff #132243)

As I mentioned before, separating the toolset config from the actual toolchain installation makes me a little nervous.

But if we're doing it, the version checks below should probably include the .1 versions too, i.e. at least 5.0.1 and 6.0.1.

49 ↗

(On Diff #132243)

It's embarrassing that we didn't figure this out before :-)

With this, we can remove

if (MSVC)
   list(APPEND CLANG_LINKS_TO_CREATE ../msbuild-bin/cl)
 endif()

from Clang's tools/driver/CMakeLists.txt

llvm/tools/msbuild/LLVM.props

8 ↗

(On Diff #132243)

Hmm, we previously intentionally called the toolset "LLVM" with the thinking that it would eventually include lld and designated the complete llvm toolchain, not just Clang. And is the "for Windows" part necessary?

llvm/tools/msbuild/Toolset.targets

38 ↗

(On Diff #132243)

This seems to duplicate a lot of logic from clang-cl. It's nice to provide a good UI for the user, but maintaining this seems a lot of work. Are you not concerned that this will rot?

46 ↗

(On Diff #132243)

But maybe we want clang-cl to map this to -flto one day. Now we need to update two places. And with the toolset/toolchain install split, the two places may be installed separately :-/

73 ↗

(On Diff #132243)

Comment copy-paste-o?

83 ↗

(On Diff #132243)

Keeping up with all these flags seems like a huge amount of work. Why not just let clang-cl ignore it?

[hans]

llvm/tools/msbuild/Toolset.targets

111 ↗

(On Diff #132243)

Maybe it will one day. The OpenMP folks claim their runtime works on Windows and we've shipped it for some releases. It seems better to keep this logic tied to the toolchain?

128 ↗

(On Diff #132243)

More stuff to keep in sync with MSVC's options and clang-cl :-/

166 ↗

(On Diff #132243)

I guess we'll need to update the fork with each VS release (but still stay compatible with old versions?)

llvm/tools/msbuild/clang-cl.xml

1 ↗

(On Diff #132243)

Maybe add a short top-level comment about what this file is.

343 ↗

(On Diff #132243)

This seems like a huge amount of stuff to keep in sync with MSVC and clang-cl's flags.

llvm/tools/msbuild/install.bat

1

Don't we want to support at least 2015 too?

1

This should probably have quotes just to be safe.

[zturner]

llvm/tools/msbuild/Clang.Cpp.Common.props

41 ↗

(On Diff #132243)

Unless we're going to release the full thing including the compiler, linker, etc through the marketplace I don't see an alternative. In any case, I actually think this it's preferable this way. There's nothing really about the two that benefits from having them coupled together, as far as I can see. I'm willing to be convinced though, if we can figure out how to to do it so that we can still ship it on the marketplace.

llvm/tools/msbuild/LLVM.props

8 ↗

(On Diff #132243)

Do you think there's any value in having a toolset that does Clang+Link and a second one that does Clang+LLD? Or do you think we should stick with only a single one? I can change the name to LLVM though.

llvm/tools/msbuild/Toolset.targets

38 ↗

(On Diff #132243)

I don't think it will. Maybe I'm being overly optimistic here, but the only case we would ever need to maintain this again is if we started supporting these options. Fiber Safe Optimizations, for example, I'm pretty sure we will never support. If MSVC ever removes the option, for example, we can do nothing and continue to work.

We could also just silently ignore them and just pass the option through to clang-cl, but these are pretty unusual options with pretty specialized use cases, so I feel like if I had gone out of my way to enable such a strange option I would want to know if the compiler was not going to respect it.

46 ↗

(On Diff #132243)

That's even better then. All we have to do is change this xml, push a new build to the market place, and the VS UI will update their extension for them.

Note that we could do the mapping at the MSBuild level, in this file down below where we have an ItemGroup. Just add a line that says <AdditionalOptions Condition="%(ClCompile.WholeProgramOptimization)' == 'true'>-flto=thin %(AdditionalOptions)</AdditionalOptions>

and we can do this without touching clang.

83 ↗

(On Diff #132243)

See the large comment at the top of the file. For some options, we could probably get by with this. Maybe even this one, I debated on this particular one.

My bar was "If the option fundamentally changes assumptions about the way code could be compiled, we should generate an error. If it changes the behavior of the language in a way we don't support, changes the way we generate code in a meaningful way, or causes specialized output files to be written, warn, and if it's an option we ignore then drop it"

The last category there we could probably just pass through in some cases, but in that comment I also mentioned a case where setting an option that clang-cl ignores impacts MSBuild's ability to figure out dependencies and ends up causing a full rebuild every time even when nothing changed.

We can scour the entire cl build tasks and try to discover if any other ones have unintended consequences, but I think it's easier to just turn them off at the MSBuild level. And as a side benefit, the user gets shorter command lines, which is always nice.

As for maintenance, this all looks like zero-maintenance code to me. Did you have an example in mind of where we'd need to update this? Whether it be a new VS version, or VS dropping support for one of these options or deprecating them, I don't think we'd have to do anything.

111 ↗

(On Diff #132243)

I can put some conditions that only cause it to error if clang version is less than or equal to 7, but that seems higher maintenance because we'll probably have many new releases before that ever happens. Even if we do tie it to the toolchain, the user is still going to have an error in their code if they have /openmp on, they'll just have to spend more time figuring out that the underlying cause is we don't currently support this option. I'd rather err on the side of improving the user experience today and worrying about what we might do in the future when it happens.

Even if we do have to push a new version of the extension every so often, that's less trouble for the user than downloading a new installer because they get auto-updated through the VS Extension Manager.

128 ↗

(On Diff #132243)

Mentioned before, but I dont' think we have to do anything to keep this in sync with MSVC. All of these lines should be able to remain forever, regardless of what MSVC does.

166 ↗

(On Diff #132243)

I don't think it would be necessary to update every release unless they fundamentally change the way the UI looks. The logic didn't change between 2015 and 2017 for example. Unless they redesign the entire Project Settings dialog, I think we should be future proof.

llvm/tools/msbuild/clang-cl.xml

343 ↗

(On Diff #132243)

This stuff almost never changes though. Most of these options have been here since at least VS 2010, which is about as far back as I can remember. The only one that wasn't here in 2015 is /diagonstics

llvm/tools/msbuild/install.bat

1

Mentioned in the other review, but the install.bat file shouldn't really be used anymore except for during development. The VSIX supports both 2015 and 2017 (I tested it in both and confirmed it works)

[hans]

llvm/tools/msbuild/Clang.Cpp.Common.props

41 ↗

(On Diff #132243)

"There's nothing really about the two that benefits from having them coupled together,"

The toolset needs to know at least where to find the toolchain and how to invoke it. If we decouple them, there needs to be an interface between them that can't change: in this case the LLVM path and version number in the registry.

But at the same time you're baking in all this logic in the toolset about how to invoke the toolchain, what flags are supported, etc. Those things are strongly dependent on the toolchain, which in this de-coupled world seems problematic. It seems like you're actually making the coupling tighter in that way, except you still want to ship the two parts separately.

Are there restrictions in the marketplace about how big a vsix can be? Because if not, I think we could just package up clang+headers+runtime into a vsix and ship the whole thing, and maybe that would be the best thing.

Or we could just stick to the current installer version and make it a little smarter about finding VS2017. Maybe instead of the batch files we write an actual program that finds the installation and copies the files.

llvm/tools/msbuild/LLVM.props

8 ↗

(On Diff #132243)

The best would be to only have one, but where the user could select between the two linkers, I think.

llvm/tools/msbuild/Toolset.targets

38 ↗

(On Diff #132243)

I feel pretty strongly that we should handle this clang-cl side. If a flag is not supported, either we should ignore it, or if it's something the user would want to know about us not supporting, we should warn. That's what clang-cl tries to do currently, and if there are flags we don't get right, we should fix it.

And we do move flags from the unsupported to supported category now and then, so the "only case we would ever need to maintain this again is if we started supporting these options" scenario is real.

46 ↗

(On Diff #132243)

But the toolset is decoupled from the toolchain in your proposal.

Not only would we need to update both clang-cl and this file, but this file would need to handle clang-cl versions both before and after.

83 ↗

(On Diff #132243)

The maintenance would come from when clang-cl changes how it handles some option, or when VS adds new options.

llvm/tools/msbuild/install.bat

1

Hmm, but then we should delete it, or at least take it out of the installer, and we need a replacement. As it is now, if we land this, it breaks the installer for versions before 2017.

[zturner]

1. Removed the option remapping. I will be adding this back in a follow up patch. The clang-cl specific "limited options view" is still here.
2. Removed the dependency on writing the version number to the registry. This was originally done so that we could add the clang resource dir to the include path, but clang can always figure out its own resource path anyway, so it turns out this was unnecessary. This has the nice property that it will automatically work with all past, present, and future clang versions without modification.
3. Changed "clang" to "llvm"
4. Merged D42769 into this patch.
5. Remove the batch files (and for that matter all other files as well) from being installed by CMake. The vsix is now the installer, which we can publish on the marketplace.

[zturner]

Don't install the batch files for real. The previous patch didn't copy them to the output directory on install, but it failed to remove the invocation of install.bat and uninstall.bat from the actual installer.

[hans]

llvm/CMakeLists.txt

237

Now that the LLVM toolchain installer no longer includes the VS integration, is there some way we could point the user to the marketplace to install the integration, or could we include the vsix in the installer and launch it for them?

llvm/tools/msbuild/LLVM.Cpp.Common.props

2

Do we know what other versions this works with besides VS 2017?

48

Is there a way for the user to point to another LLVM installation? This was one of the reasons for separating the toolset from the toolchain, right?

llvm/tools/msbuild/clang-cl.xml

1 ↗

(On Diff #132645)

I thought you were going to leave the flag logic out of this patch?

llvm/tools/msbuild/install.bat

0–1

I thought you meant to delete this file? I can see that it's still useful for development, but maybe then we should rename it or put a comment on the top or something explaining what it does, since its purpose is now changing from what it was before.

llvm/tools/msbuild/license.txt

2

Can't we use the old file? Checking in another copy seems unfortunate.

llvm/tools/msbuild/llvm.sln

2

Should we have a cmake build target to build this vsix, similar to what we do for the clang-format one, which gets built by the "clang_format_vsix" target?

[zturner]

llvm/CMakeLists.txt

237

Do we have a Release Notes file that we install? That could be a good place to include a link to the marketplace?

Although, we'd probably want to wait until it's actually published on the marketplace before we do anything.

llvm/tools/msbuild/LLVM.Cpp.Common.props

48

At the moment, you can do this by changing the registry key. In subsequent patches I can add a UI setting under C/C++ > General.

llvm/tools/msbuild/clang-cl.xml

1 ↗

(On Diff #132645)

I thought Nico said to only separate out the option remapping into another patch. I took all of that out.

llvm/tools/msbuild/license.txt

2

I copied this one from the clang-format vs integration folder. The one at the top level llvm directory has some extra stuff at the bottom which doesn't apply to this, but I don't know if it would still work just as well even with all that extra stuff in it.

llvm/tools/msbuild/llvm.sln

2

Yea that seems reasonable. I'll look into how that works.

[hans]

llvm/tools/msbuild/LLVM.Cpp.Common.props

48

Is it hard to add, or can you add it to this patch? Changing the registry isn't very good UI and is also global.

llvm/tools/msbuild/clang-cl.xml

1 ↗

(On Diff #132645)

This file still attempts to duplicate the logic of what flags clang-cl supports, which are ignored, etc. I'd prefer if we didn't do that.

To repeat my concerns:

1. This list of flags would need to be maintained, and I expect it will always end up being incomplete or inaccurate in some other way. The only way to keep it accurate would be if it's auto-generated from clang-cl's tablegen file. But that ties it to a specific clang-cl version, which is the next problem

2. It ties it to a particular clang-cl version, which goes against the point of decoupling the VS integration from the toolchain. As a concrete example, your file is missing /arch:AVX512 and /arch:AVX512F, so those should be added, but only when the user is using a Clang >= r323433. Of course the user could them manually, but why should some flags be listed and some not? And maybe we could handle this with version logic, but now we're getting into *really* hairy maintenance.

llvm/tools/msbuild/license.txt

2

Right, the clang-format one is my fault :-) It's formated to fit better in the vsix installer window. Could we make the build system copy it instead of checking in another copy? If that's not easy, never mind this is not important obviously.

[zturner]

llvm/tools/msbuild/LLVM.Cpp.Common.props

48

I can add it to this patch, but there's also no way to do this without forking the UI file, which gets to your next comment.

llvm/tools/msbuild/clang-cl.xml

1 ↗

(On Diff #132645)

I can move this to another patch if you want, but I have to say that presenting a clang-cl tailored UI of the options is something that I feel very strongly about. In fact, the main reason I volunteered to take on this effort is specifically because I wanted to make sure we do this.

We can get into how it would have to be maintained etc, but all of that is irrelevant IMO because I'm approaching this from the perspective of the user. As someone who has used VS pretty heavily for close to 20 years, this is absolutely a large value-add for the user.

To re-iterate though, I don't see where the perceived maintenance comes from. You're already suggesting that I do nothing, which means that the user will already have to manually add options anyway if the version of VS doesn't match up with the version of clang-cl exactly. So what I'm doing here is imperfect (as is the alternative of doing nothing), but is strictly better. I don't see how that could be perceived as anything other than a win.

Version logic isn't even that hairy of maintenance. Every time we ship a new LLVM release (which seems to be about once a year), we copy the file and make the 1 or 2 necessary modifications to the copied file.

[hans]

llvm/tools/msbuild/LLVM.Cpp.Common.props

48

Aww :-(

llvm/tools/msbuild/clang-cl.xml

1 ↗

(On Diff #132645)

I think a clang-cl tailored UI would be really nice, but I don't think it's sustainable to maintain this file by hand. If we want to expose clang-cl's options this way, I think we need to auto-generate it from the .td file, and that it needs to be tied to the clang-cl version whose options are being exposed.

We ship a major release twice a year, typically two more stable (x.0.1) releases per year, and in addition to that I ship snapshots about once or twice a month. If we're going to present clang-cl's options here, I think the file needs to stay in sync with clang-cl's options.

[zturner]

llvm/tools/msbuild/clang-cl.xml

1 ↗

(On Diff #132645)

Having it be auto-generated from the .td file is a good idea, but it's quite a bit of extra work and it may not be possible to do it in a useful way (for example, MSVC's UI displays the options in categories, which are defined just below this comment in Phab. Having the auto-generated options be correctly categorized seems difficult / impossible).

It's worth trying, and if we can do it then I agree it would be worth doing, but in the meantime I think the approach here is still strictly better than doing nothing, even if this file were never touched again (which is unlikely).

[hans]

llvm/tools/msbuild/clang-cl.xml

1 ↗

(On Diff #132645)

We can add categories to the flags in the .td file.

The "doing nothing" that we currently do is expose Visual Studio's choice of flags and then let clang-cl handle them. I don't think that's terribly bad.

[zturner]

llvm/tools/msbuild/clang-cl.xml

1 ↗

(On Diff #132645)

Sure, it's not terribly bad. But I'd like to do something better than just "not terribly bad". :)

There are other issues with auto-generating the file from the td as well. When an option takes multiple values (such as /arch:), the specific values it takes are not always present in the TD file. You mentioned /arch:AVX512 earlier, but that value is not in the td file anywhere.

That doesn't mean it's impossible, we can probably address all of the various issues to get the td file to a point where this file could be auto-generated. But I don't think that work should hold this up, as I still maintain that the solution here is strictly better from the user's perspective than the old method of doing nothing.

[• olgaark]

llvm/tools/msbuild/Clang.Cpp.Common.props

49 ↗

(On Diff #132243)

Yes, you can redefine CLToolExe/Path if you want to use 'cl' task, but have you looked at using 'ClangCompile' task instead (see Microsoft.Cpp.Clang.props & targets, as well as clang c2 toolset)? Would it work better for you? If not, we'll interested to know why.

llvm/tools/msbuild/LLVM.props

8 ↗

(On Diff #132243)

I believe the debugging is different for LLD produced binaries, so if this is the case, I'd recommend creating separate msbuild toolsets for Clang+Link and Clang+LLD.

VS has extensibility to support different debugging and it is expected that when toolset changes the set of available debuggers can change, but not when some arbitrary property is changed.

llvm/tools/msbuild/Toolset.targets

38 ↗

(On Diff #132243)

There is a way currently to extend a rule (not override it) where you can add/remove properties, but I am not sure it will make it better from maintenance perspective for clang-cl rule. You might want to use it for ConfigGeneral page though.

https://github.com/Microsoft/VSProjectSystem/commit/3e2e9c7ea2f3155de9932ab53d9ec37b6bdafa17

Also, if you decide to use ClangCompile task, clang.xml it the one which is matching it.

166 ↗

(On Diff #132243)

If you don't need to remove rules added by default and want just replace some of them (like cl one with clang-cl) you can allow default rules to be added and then include yours, If several rules in the list have the same name, the last one will be used.

So if you name your rule as "CL" (instead of "clang-cl") and make sure you include it to PropertyPageSchema items after importing MS targets which add 'real' cl rule, your rule will be used instead.

[zturner]

llvm/tools/msbuild/Clang.Cpp.Common.props

49 ↗

(On Diff #132243)

My understanding of the ClangCompile task is that it invokes clang.exe or clang++.exe and that it passes gcc style command line options (for example, clang.xml looks like it passes all gcc style options such as -fno-exceptions, etc.

The clang cl driver (clang-cl.exe) is designed to be a drop in replacement for cl.exe, and accepts MSVC style command line arguments. It's also the only supported way to produce native Windows exes (that's not to say you can't construct a clang++.exe command line that will do it, just that we only support it via the cl driver).

[zturner]

llvm/tools/msbuild/LLVM.props

8 ↗

(On Diff #132243)

Recent versions of LLD produce PDBs that are supposed to be completely compatible with link.exe PDBs. So, debugging should not change (we don't support managed debugging and certain other things like that, but on the other hand we don't generate managed code either, so it should be fine).

[zturner]

Question for @olgaark. Is there any way to get a page that looks like PageTemplate="generic" (i.e. with the expanding categories, such as the General page), but as a subpage of a PageTemplate="tool" page? For example, imagine you click Properties > C/C++ > Warnings, and then when you click the warnings page, I'd like that page to look like PageTemplate="generic". Is that possible?

[rnk]

llvm/tools/msbuild/clang-cl.xml

1 ↗

(On Diff #132645)

I don't think we'd get much value from table generating them. This file contains a lot of information and organization that we'd have to encode in tablegen. Every option would need its property sheet category, name, and display name, none of which we currently encode.

If we did want to automatically fill in undescribed options somehow, I'd suggest storing the property sheet information separately kind of like we currently do for the attribute documentation, and then "joining" the two files in tablegen to make this XML file. I just don't think it's worth it, though.

[rnk]

llvm/tools/msbuild/clang-cl.xml

1 ↗

(On Diff #132645)

I think part of the reason why I don't like the idea of loading this all into tablegen is that editing tablegen files sucks. We have all these ad-hoc conventions for adding line breaks, but there's no editor support for them or anything. I think if they were YAML files, it would be a lot easier to add new fields to options to help us auto-generate property sheets like this or even full HTML command line reference, something we sorely lack today.

Maybe this is just dreaming, but I expect YAML would also make it easier to automatically parse enum values to options, like /arch:avx512 etc. We could do that today, but it requires hacking on and extending this janky Record abstraction that's not well understood. Or maybe it just requires effort and motivation.

[zturner]

Added a UI setting that allows the user to choose a custom path to clang. It defaults to $(LLVMInstallDir)bin\clang-cl.exe. I added this to the general page of the UI. I then initialize the value of $(CLToolExe) with the value of this setting in the .targets file. And since I'm mucking with that page anyway, removed some settings that don't apply to clang-cl, surrounding managed code and App Store stuff.

Also fixed a bug where DebuggerFlavor wasn't being initialized in the .props file, the effect of which was that you couldn't debug unless you explicitly went to the debugger page and chose Local Windows Debugger.

[• olgaark]

llvm/tools/msbuild/Clang.Cpp.Common.props

49 ↗

(On Diff #132243)

Ok, it makes sense to use 'cl' task then

[hans]

llvm/tools/msbuild/clang-cl.xml

1 ↗

(On Diff #132645)

But this file is effectively duplicating the information about what flags clang-cl supports. Am I the only one that's concerned about how to maintain that, and the two getting out of sync?

Olga mentioned (https://reviews.llvm.org/D42762?id=132243#inline-375127) something about extending rules rather than overwriting them. Would that be an option for us, i.e. just exposing the regular cl options and maybe do a few tweaks where really necessary?

[rnk]

llvm/tools/msbuild/clang-cl.xml

1 ↗

(On Diff #132645)

I am concerned about the duplication, but I think encoding the information in this XML into TableGen is going to be really ugly. Even if we stored this info outside the tablegen, we'd need some way to "join" the property sheet data with the .td data, which effectively duplicates the list of flags, or at least the supported flags with documentation and display names, similar to the way the attribute reference docs work.

Re: Olga's comment, maybe that would work, but I suspect we won't have as much control over the organization.

[zturner]

llvm/tools/msbuild/clang-cl.xml

1 ↗

(On Diff #132645)

extending a rules file only works when you want to add a new category or option, not when you want to remove some options but keep others. So it's not going to save us from the duplication. Personally though I'm not at all concerned about the duplication. If we take the duplicated file as it exists in this CL, and never touch it or maintain it ever again, we would still be providing a better user experience than doing nothing and relying on whatever version happens to ship with Visual Studio.

It's extremely unlikely that we would never touch it again, however. And in the worst case scenario, if we do ultimately find out that it's too much maintenance, we can change 4 or 5 lines of xml to disable our custom rules file, push an update to the marketplace, and people will automatically get updated to the new version.

[hans]

llvm/tools/msbuild/clang-cl.xml

1 ↗

(On Diff #132645)

"If we take the duplicated file as it exists in this CL, and never touch it or maintain it ever again, we would still be providing a better user experience than doing nothing and relying on whatever version happens to ship with Visual Studio."

I'm not sure I agree, but I think this has been reviewed to exhaustion. Go ahead and submit, please publish under the [e-mail] account, and I guess we'll see how it works out.

[rnk]

lgtm, thanks for revamping the VS integration!

[chandlerc]

FYI, Andrew Pardoe from Microsoft and I were talking and he wanted to express really strong support for getting this in and deployed. He's also offered any help that would be useful to sorting this out so there is a solid installer for VS 2017.

Anything this is waiting on (since it already got an LGTM some time ago)?

[zturner]

In D42762#1041034, @chandlerc wrote:

FYI, Andrew Pardoe from Microsoft and I were talking and he wanted to express really strong support for getting this in and deployed. He's also offered any help that would be useful to sorting this out so there is a solid installer for VS 2017.

Anything this is waiting on (since it already got an LGTM some time ago)?

I think the biggest reason I've been dragging my feet on this is that there was never really a strong consensus that this was the right direction, and I don't feel great about committing without consensus. I guess I was subconsciously hoping someone else would show up and chime in with their opinion. Part of the problem is that there's not many LLVM developers who are also VS users, and of the ones that actually are, most are VS users of CMake generated projects as opposed to VS users of hand-maintained projects. And that is ultimately who we are targeting with this VS integration, so it would be good to have their feedback.

But since it looks like that probably isn't gonna happen, I guess I can wait until the end of this week and see if the discussion magically picks up again. If not, I suppose I can commit as-is at the end of the week.

[smeenai]

Any updates here?

[zturner]

I've got a new version of the VS integration here. Below I'll outline the changes from the previous iteration. Most of this is based on feedback from David Tarditi (who I'm now adding as a reviewer) and Hans. But I also added something new that was my own idea.

1. We no longer present a custom UI of the options. We do not change the layout of any builtin Microsoft UI page in any way.

2. We now silently discard certain command line options before passing them to clang-cl. We only do this for options that generate -Wunused-command-line warnings and for which we never plan to support the option anyway (for example Fiber Safe Optimizations).

3. We hard-error on options that fundamentally change the assumptions about the way in which code should be compiled. For example, /clr. These types of options would result in an error anyway because clang wouldn't understand the code, but at least now the user has a more meaningful error message.

4. We remap /ZI and /Zi to /Z7. See the comment in LLVM.Cpp.Common.Targets for a longer explanation.

5. Previously we let the user specify the Path to clang-cl.exe in the General page. We did this by forking the general page and adding a field to it. While this is arguably a "cleaner" user experience, it's more maintenance for us (and requires us to change a builtin UI page, which point #1 explains that we are no longer doing), and it may not continue to be a cleaner experience if we ever want to add more than just 1 field here (for example, path to lld-link.exe if/when we update the extension to support LLD). So I made a separate page called LLVM. This page appears whenever the LLVM Platform Toolset is selected. For now it only contains one option (path to clang-cl.exe), but in the future it could contain other options such as "Use clang-cl (True/False)", "Path to clang-cl.exe", "Use LLD", "Path to lld-link.exe", and maybe some other ones we could come up with.

Hopefully this is a nice middle ground and addresses all of the issues we were discussing earlier in the thread.

[smeenai]

llvm/tools/msbuild/LLVM.Cpp.Common.props

7

I think this should say LLVM.Cpp.Common.props instead of Clang.Cpp.Common.props?

43

Is there a way to add some sort of error here if LLVMInstallDir is still empty? Is it worth it?

73

Not that it really matters right now, but this wouldn't do the right thing for arm or arm64, right?

llvm/tools/msbuild/LLVM.Cpp.Common.targets

57

If users want to use LTO with clang-cl + lld-link, are they just expected to set the appropriate compiler and linker options manually?

86

This comment is swapped...

91

...with this.

119

I think it's more accurate to describe this as not supporting C++/CX, since clang does support WinRT using straight up COM.

[zturner]

Fixed issues pointed out by @smeenai

[zturner]

llvm/tools/msbuild/LLVM.Cpp.Common.props

43

I'm not sure it's worth it. We could maybe warn when the project is loaded if the path is invalid, but I don't think we should do anything special for $(LLVMInstallDir) specifically, because ultimately the user can just change this to something else, so having a valid install dir is not even necessary. So for a user that never wants to install LLVM and just set the path to clang, they might get annoyed by constantly seeing a warning which they don't care about. If they do try to use it, they'll get an error pretty quickly along the lines of Unable to find path file \bin\clang-cl.exe so hopefully that's a sufficient clue? I could probably try to catch this in BeforeClCompile and print a better error message if you think the standard error message isn't clear enough.

73

Right, we'd need something else here for arm.

llvm/tools/msbuild/LLVM.Cpp.Common.targets

57

For now yes. Even though they are conceptually the same thing, they are incompatible with each other from an implementation standpoint. So, for example, you couldn't use MSVC WPO object files with lld-link, for example, or vice versa. This VS integration right now, for example, doesn't even add support for using lld-link (only clang-cl), so use of this option right now would break the build, as link.exe would be trying to link llvm bitcode files. So I think it makes sense to (eventually) provide a separate UI option for LLVM LTO, perhaps under the new LLVM UI page.

[zturner]

Deleted clang-cl.xml. We no longer modify the existing settings UI so this file was stale. Also fixed the csproj to properly refer to llvm-general.xml.

[rnk]

I think that addresses @hans's concerns of duplicating all our options, so let's go ahead and land this.

[hans]

Thanks for pushing this through!

Will you upload the vsix to the marketplace? (Use the [e-mail] account, which despite the name is also used for the clang-format vs plugin etc.)

Then I can update the docs to point at it.

clang/tools/driver/CMakeLists.txt

 if(CLANG_PLUGIN_SUPPORT)
   export_executable_symbols(clang)
 endif()
 
 add_dependencies(clang clang-headers)
 
 if(NOT CLANG_LINKS_TO_CREATE)
   set(CLANG_LINKS_TO_CREATE clang++ clang-cl clang-cpp)
-
-  if (MSVC)
-    list(APPEND CLANG_LINKS_TO_CREATE ../msbuild-bin/cl)
-  endif()
 endif()
 
 foreach(link ${CLANG_LINKS_TO_CREATE})
   add_clang_symlink(${link} clang)
 endforeach()
 
 # Configure plist creation for OS X.
 set (TOOL_INFO_PLIST "Info.plist" CACHE STRING "Plist name")

llvm/CMakeLists.txt

 set(CPACK_NSIS_COMPRESSOR "/SOLID lzma \r\n SetCompressorDictSize 32")
 if(WIN32 AND NOT UNIX)
   set(CPACK_PACKAGE_INSTALL_REGISTRY_KEY "LLVM")
   set(CPACK_PACKAGE_ICON "${CMAKE_CURRENT_SOURCE_DIR}\\\\cmake\\\\nsis_logo.bmp")
   set(CPACK_NSIS_MUI_ICON "${CMAKE_CURRENT_SOURCE_DIR}\\\\cmake\\\\nsis_icon.ico")
   set(CPACK_NSIS_MUI_UNIICON "${CMAKE_CURRENT_SOURCE_DIR}\\\\cmake\\\\nsis_icon.ico")
   set(CPACK_NSIS_MODIFY_PATH "ON")
   set(CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL "ON")
-  set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS
-    "ExecWait '$INSTDIR/tools/msbuild/install.bat'")
-  set(CPACK_NSIS_EXTRA_UNINSTALL_COMMANDS
-    "ExecWait '$INSTDIR/tools/msbuild/uninstall.bat'")
   if( CMAKE_CL_64 )
     set(CPACK_NSIS_INSTALL_ROOT "$PROGRAMFILES64")
   endif()
 endif()
 include(CPack)
 
 # Sanity check our source directory to make sure that we are not trying to
 # generate an in-source build (unless on MSVC_IDE, where it is ok), and to make

llvm/tools/msbuild/.gitignore

+bin
+obj

llvm/tools/msbuild/CMakeLists.txt

-if (MSVC)
-  # CPack will install a registry key in this format that we wish to reference.
-  set(REG_KEY "${CPACK_PACKAGE_INSTALL_REGISTRY_KEY}")
-  set(LIB_PATH_VERSION "${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}")
-
-  foreach (platform "Win32" "x64")
-    set(prop_file_in "Microsoft.Cpp.Win32.llvm.props.in")
-    set(prop_file_v100 "Microsoft.Cpp.${platform}.LLVM-vs2010.props")
-    set(prop_file_v110 "Microsoft.Cpp.${platform}.LLVM-vs2012.props")
-    set(prop_file_v110_xp "Microsoft.Cpp.${platform}.LLVM-vs2012_xp.props")
-    set(prop_file_v120 "toolset-vs2013.props")
-    set(prop_file_v120_xp "toolset-vs2013_xp.props")
-    set(prop_file_v140 "toolset-vs2014.props")
-    set(prop_file_v140_xp "toolset-vs2014_xp.props")
-
-    if (platform STREQUAL "Win32")
-      set(mflag "m32")
-    else()
-      set(mflag "m64")
-    endif()
-    set(VS_VERSION "v100")
-    set(MSC_VERSION "1600")
-    configure_file(${prop_file_in} ${platform}/${prop_file_v100})
-    set(VS_VERSION "v110")
-    set(MSC_VERSION "1700")
-    configure_file(${prop_file_in} ${platform}/${prop_file_v110})
-    set(VS_VERSION "v110_xp")
-    configure_file(${prop_file_in} ${platform}/${prop_file_v110_xp})
-    set(VS_VERSION "v120")
-    set(MSC_VERSION "1800")
-    configure_file(${prop_file_in} ${platform}/${prop_file_v120})
-    set(VS_VERSION "v120_xp")
-    configure_file(${prop_file_in} ${platform}/${prop_file_v120_xp})
-    set(VS_VERSION "v140")
-    set(MSC_VERSION "1900")
-    configure_file(${prop_file_in} ${platform}/${prop_file_v140})
-    set(VS_VERSION "v140_xp")
-    configure_file(${prop_file_in} ${platform}/${prop_file_v140_xp})
-    set(VS_VERSION)
-    set(MSC_VERSION)
-    set(mflag)
-
-    install(FILES "${CMAKE_CURRENT_BINARY_DIR}/${platform}/${prop_file_v100}" DESTINATION tools/msbuild/${platform})
-    install(FILES "${CMAKE_CURRENT_BINARY_DIR}/${platform}/${prop_file_v110}" DESTINATION tools/msbuild/${platform})
-    install(FILES "${CMAKE_CURRENT_BINARY_DIR}/${platform}/${prop_file_v110_xp}" DESTINATION tools/msbuild/${platform})
-    install(FILES "${CMAKE_CURRENT_BINARY_DIR}/${platform}/${prop_file_v120}" DESTINATION tools/msbuild/${platform})
-    install(FILES "${CMAKE_CURRENT_BINARY_DIR}/${platform}/${prop_file_v120_xp}" DESTINATION tools/msbuild/${platform})
-    install(FILES "${CMAKE_CURRENT_BINARY_DIR}/${platform}/${prop_file_v140}" DESTINATION tools/msbuild/${platform})
-    install(FILES "${CMAKE_CURRENT_BINARY_DIR}/${platform}/${prop_file_v140_xp}" DESTINATION tools/msbuild/${platform})
-
-    install(FILES "Microsoft.Cpp.Win32.LLVM-vs2010.targets" DESTINATION "tools/msbuild/${platform}" RENAME "Microsoft.Cpp.${platform}.LLVM-vs2010.targets")
-    install(FILES "Microsoft.Cpp.Win32.LLVM-vs2012.targets" DESTINATION "tools/msbuild/${platform}" RENAME "Microsoft.Cpp.${platform}.LLVM-vs2012.targets")
-    install(FILES "Microsoft.Cpp.Win32.LLVM-vs2012_xp.targets" DESTINATION "tools/msbuild/${platform}" RENAME "Microsoft.Cpp.${platform}.LLVM-vs2012_xp.targets")
-    install(FILES "toolset-vs2013.targets" DESTINATION "tools/msbuild/${platform}")
-    install(FILES "toolset-vs2013_xp.targets" DESTINATION "tools/msbuild/${platform}")
-    install(FILES "toolset-vs2014.targets" DESTINATION "tools/msbuild/${platform}")
-    install(FILES "toolset-vs2014_xp.targets" DESTINATION "tools/msbuild/${platform}")
-  endforeach()
-
-  set(LIB_PATH_VERSION)
-  set(REG_KEY)
-
-  install(DIRECTORY .
-    DESTINATION tools/msbuild
-    FILES_MATCHING
-    PATTERN "*.bat"
-    PATTERN ".svn" EXCLUDE
-    )
-endif()

llvm/tools/msbuild/LLVM.Cpp.Common.props

+<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
+  <!-- The general order of executing an MSBuild file is roughly:
+       1) vcxproj file
+       2) ├─ Import Microsoft.Cpp.props
+       3) │  └─ Import Toolset specific props (e.g. $(VCTargets)Platforms\Win32\PlatformToolsets\llvm\Toolset.props)
+       4) │     └─ Import This File (LLVM.Cpp.Common.props)
+       5) │─ Core logic of vcxproj (define files, override properties, etc)
+       6) └─ Import Microsoft.Cpp.targets
+       7)    │─ Import Toolset specific targets file (e.g. $(VCTargets)Platforms\Win32\PlatformToolsets\llvm\Toolset.targets)
+       8)    └─ Run the compiler.
+       The important thing is that we have hooks at 3, 4, and 7.  3 and 4 give
+       us the ability to provide initial values for toolchain settings (where
+       is the compiler, what values are considered "default" for a given
+       setting, etc), 7 gives us the ability to act on anything that the user
+       has overridden (such as warning or erroring on incompatible settings,
+       mapping settings to other settings, etc).
+       -->
+
+  <PropertyGroup>
+    <!-- This initializes the values in Properties > General > Output Directory.
+       Builds will fail without this. -->
+    <OutDirWasSpecified Condition=" '$(OutDir)'!='' AND '$(OutDirWasSpecified)'=='' ">true</OutDirWasSpecified>
+    <OutDirWasSpecified Condition=" '$(OutDir)'=='' AND '$(OutDirWasSpecified)'=='' ">false</OutDirWasSpecified>
+
+    <IntDir Condition="'$(IntDir)'=='' AND '$(IntermediateOutputPath)'!=''">$(IntermediateOutputPath)</IntDir>
+    <IntDir Condition="'$(IntDir)'=='' AND '$(IntermediateOutputPath)'==''">$(Configuration)\</IntDir>
+    <OutDir Condition="'$(OutDir)'=='' AND '$(SolutionDir)' != ''">$(SolutionDir)$(Configuration)\</OutDir>
+    <OutDir Condition="'$(OutDir)'=='' AND '$(SolutionDir)' == ''">$(IntDir)</OutDir>
+    <DebuggerFlavor Condition="'$(DebuggerFlavor)'==''">WindowsLocalDebugger</DebuggerFlavor>
+  </PropertyGroup>
+
+  <PropertyGroup>
+    <!-- Short names for platform toolsets (added to project name in Solution Explorer) -->
+    <_PlatformToolsetShortNameFor_llvm>LLVM</_PlatformToolsetShortNameFor_llvm>
+    <_PlatformToolsetFriendlyNameFor_llvm>LLVM</_PlatformToolsetFriendlyNameFor_llvm>
+  </PropertyGroup>
+
+  <!-- Find an installed LLVM and set up our paths. -->
+  <PropertyGroup>
+    <LLVMInstallDir>$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\LLVM@LLVM)</LLVMInstallDir>
+    <LLVMInstallDir Condition="'$(LLVMInstallDir)' == ''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\LLVM@LLVM)</LLVMInstallDir>
+    <ClangClExecutable>$(LLVMInstallDir)bin\clang-cl.exe</ClangClExecutable>
+  </PropertyGroup>
+
+  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.WindowsSDK.props" Condition="Exists('$(VCTargetsPath)\Microsoft.Cpp.WindowsSDK.props')"/>
+  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Common.props" />
+
+  <PropertyGroup>
+    <!-- Set some paths (such as include paths) that are common to all platforms.  This is the same as what
+         the default paths for cl will use.
+         -->
+    <IncludePath Condition="'$(IncludePath)' == ''">$(IncludePath);$(VC_IncludePath);$(WindowsSDK_IncludePath);</IncludePath>
+    <LibraryWPath Condition="'$(LibraryWPath)' == ''">$(WindowsSDK_MetadataPath);</LibraryWPath>
+    <SourcePath Condition="'$(SourcePath)' == ''">$(VC_SourcePath);</SourcePath>
+  </PropertyGroup>
+
+
+  <!-- Set values which are reflected in the property UI by default.  The user can override these
+       by editing the vcxproj file (or making changes via the UI, which has the same effect).
+       -->
+  <ItemDefinitionGroup>
+    <ClCompile>
+      <!-- Set this to "Default" (which means not passing any /RTC option) so that any other value will
+           be treated as having been overridden by the user.  This Serves as a hint to the user that
+           Default is the value we support, and other values will generate a warning.  It also means
+           that if the user simply creates a new project in MSVC (which uses /RTCu by default), then
+           switches the toolset to Clang, we will still treat the value as default (which for us is to
+           not pass the option).  Only if the user explicitly overrode this setting in a project to use
+           /RTCu would we see the warning. -->
+      <BasicRuntimeChecks>Default</BasicRuntimeChecks>
+
+      <AdditionalOptions>-m$(PlatformArchitecture) %(AdditionalOptions)</AdditionalOptions>
+    </ClCompile>
+  </ItemDefinitionGroup>
+</Project>

llvm/tools/msbuild/LLVM.Cpp.Common.targets

+<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
+  <Import Project="$(VCTargetsPath)\Microsoft.CppCommon.targets" />
+
+  <PropertyGroup>
+    <!-- Set the path to clang-cl executable based on the value of the project-
+         level setting.  This has to be done in the .targets file since values
+         selected via the settings UI appear in the vcxproj (which is imported
+         before the targets file but after the props file) and we need the path
+         that the user may have overridden in the UI. -->
+    <CLToolExe>$(ClangClExecutable)</CLToolExe>
+  </PropertyGroup>
+
+  <ItemGroup>
+    <PropertyPageSchema Include="$(VCTargetsPath)$(LangID)\llvm-general.xml">
+      <Context>Project</Context>
+    </PropertyPageSchema>
+  </ItemGroup>
+
+  <!-- We hook up a target to run every time ClCompile is about to run, the
+       purpose of which is to sanitize the command line before it gets passed to
+       the compiler.  Some options we silently discard, other options we warn on
+       and then discard, and other options we generate a hard error.
+
+       We try to keep hard errors to a minimum and reserve it for cases where
+       the option implies fundamentally different assumptions about the way code
+       should be compiled.  This code would probably generate an error anyway,
+       but at least this way we give the user a more useful message about what
+       the actual problem is, rather than relying on some obscure compilation
+       error.
+
+       For any options that clang-cl discards, we would prefer to not even pass
+       them in on the command line.  So if a user starts with a cl projects and
+       changes the toolset to clang, they could have set options such as /Gm
+       (minimal rebuild), /sdl (Security Checks), etc.  The ClCompile task would
+       then notice this and pass these through to clang-cl.exe.  Clang would of
+       course ignore them, but in some cases (such as /Gm), they would generate
+       -Wunused-command-line-argument warnings, so it's better if we can just
+       strip them from the command line entirely.  This also has the side
+       benefit of making command lines shorter which is always nice when trying
+       to look at the tool output.
+      -->
+  <Target Name="BeforeClCompile" BeforeTargets="ClCompile">
+    <!-- Warn on /Zi and /ZI, then map them both to /Z7. -->
+    <Warning Condition="'%(ClCompile.DebugInformationFormat)' == 'ProgramDatabase'"
+             File="@(ClCompile)(0,0)"
+             Text="clang-cl does not support /Zi (Program Database).  The file will be compiled as if /Z7 (C7 Compatible Debug Info) had been passed.  Update the Debug Information Format in project settings to silence this warning."/>
+    <Warning Condition="'%(ClCompile.DebugInformationFormat)' == 'EditAndContinue'"
+             File="@(ClCompile)(0,0)"
+           Text="clang-cl does not support /ZI (Program Database for Edit and Continue).  The file will be compiled as if /Z7 (C7 Compatible Debug Info) had been passed.  Update the Debug Information Format in project settings to silence this warning."/>
+
+    <!-- Warn if Fiber Safe Optimizations are enabled, and then ignore them. -->
+    <Warning Condition="'%(ClCompile.EnableFiberSafeOptimizations)' == 'true'"
+             File="@(ClCompile)(0,0)"
+             Text="clang-cl does not support fiber safe optimizations (/GT).  Disable this option in compatibility settings to silence this warning."/>
+
+    <!-- Warn if Whole Program Optimization is enabled, and then ignore it. -->
+    <Warning Condition="'%(ClCompile.WholeProgramOptimization)' == 'true'"
+             File="@(ClCompile)(0,0)"
+             Text="clang-cl does not support MSVC Link Time Optimization.  Disable this option in compatibility settings to silence this warning."/>
+
+    <!-- Warn if Ignore Standard Include Paths is non-empty, then ignore it. -->
+    <Warning Condition="'%(ClCompile.IgnoreStandardIncludePath)' == 'true'"
+             File="@(ClCompile)(0,0)"
+             Text="clang-cl does not support Ignore Standard Include Path (/X).  Disable this option in compatibility settings to silence this warning."/>
+
+    <!-- Warn if Smaller Type Check is enabled, then ignore it.-->
+    <Warning Condition="'%(ClCompile.SmallerTypeCheck)' == 'true'"
+             File="@(ClCompile)(0,0)"
+             Text="clang-cl does not support Smaller Type Check (/RTCc).  Disable this option in compatibility settings to silence this warning."/>
+
+    <!-- Warn if Runtime Checks are enabled, then ignore them.-->
+    <Warning Condition="'%(ClCompile.BasicRuntimeChecks)' != 'Default'"
+             File="@(ClCompile)(0,0)"
+             Text="clang-cl does not support Basic Runtime Checks (/RTCu, /RTC1, /RTCs).  Disable this option in compatibility settings to silence this warning."/>
+
+    <!-- Warn if parallel code generation on #pragma loop is enabled, then ignore. -->
+    <Warning Condition="'(ClCompile.EnableParallelCodeGeneration)' == 'true'"
+             File="@(ClCompile)(0,0)"
+             Text="clang-cl does not support parallel code generation with #pragma loop(hint) (/Qpar).  Disable this option in compatibility settings to silence this warning."/>
+
+    <!-- Warn if hotpatchable images are turned on -->
+    <Warning Condition="'%(ClCompile.CreateHotpatchableImage)' == 'true'"
+             File="@(ClCompile)(0,0)"
+             Text="clang-cl does not support creating hotpatchable images (/hotpatch).  Disable this option in compatibility settings to silence this warning."/>
+
+    <!-- Warn if /Zc:forScope- is specified, and then ignore it. -->
+    <Warning Condition="'%(ClCompile.ForceConformanceInForLoopScope)' == 'false'"
+             File="@(ClCompile)(0,0)"
+             Text="clang-cl does not support disabling for loop scope conformance (/Zc:forScope-).  Disable this option in compatibility settings to silence this warning."/>
+
+    <!-- Warn if /Zc:wchar_t- is specified, and then ignore it. -->
+    <Warning Condition="'%(ClCompile.TreatWChar_tAsBuiltInType)' == 'false'"
+             File="@(ClCompile)(0,0)"
+             Text="clang-cl does not support treating wchar_t as a non builtin type (/Zc:wchar_t-).  Disable this option in compatibility settings to silence this warning."/>
+
+    <!-- Warn if XML Documentation is generated, and then ignore it. -->
+    <Warning Condition="'%(ClCompile.GenerateXMLDocumentationFiles)' == 'true'"
+             File="@(ClCompile)(0,0)"
+             Text="clang-cl does not support generating xml documentation comment files (/doc).  Disable this option in compatibility settings to silence this warning."/>
+
+    <!-- Warn if Browse Information is generated, and then ignore it. -->
+    <Warning Condition="'%(ClCompile.BrowseInformation)' == 'true'"
+             File="@(ClCompile)(0,0)"
+             Text="clang-cl does not support generating browse information (/FR).  Disable this option in compatibility settings to silence this warning."/>
+
+    <!-- Warn if /analyze is passed, then ignore it. -->
+    <Warning Condition="'%(ClCompile.EnablePREfast)' == 'true'"
+             File="@(ClCompile)(0,0)"
+             Text="clang-cl does not support MSVC code analysis functionality (/analyze).  Disable this option in compatibility settings to silence this warning."/>
+
+    <!-- Error if they're trying to compile this file as managed code. -->
+    <Error Condition="('%(ClCompile.CompileAsManaged)' != 'false') AND ('%(ClCompile.CompileAsManaged)' != '')"
+           File="@(ClCompile)(0,0)"
+           Text="clang-cl does not support compiling managed code (/clr).  This file cannot be compiled."/>
+
+    <!-- Error if WinRT is being used. -->
+    <Error Condition="('%(ClCompile.CompileAsWinRT)' == 'true') OR ('%(ClCompile.WinRTNoStdLib)' == 'true')"
+           File="@(ClCompile)(0,0)"
+           Text="clang-cl does not support Windows Runtime Language Extensions (/ZW, /ZW:nostdlib).  This file cannot be compiled."/>
+
+    <!-- Error if OpenMP language extensions are enabled. -->
+    <Error Condition="'%(ClCompile.OpenMPSupport)' == 'true'"
+           File="@(ClCompile)(0,0)"
+           Text="clang-cl does not support OpenMP (/openmp).  This file cannot be compiled."/>
+
+    <!-- Error if C++ Modules are enabled.  Clang has its own notion of modules that are not compatible. -->
+    <Error Condition="'%(ClCompile.EnableModules)' == 'true'"
+           File="@(ClCompile)(0,0)"
+           Text="clang-cl does not support MSVC Modules (/experimental:module).  This file cannot be compiled."/>
+
+    <ItemGroup>
+      <ClCompile>
+        <!-- Map /ZI and /Zi to /Z7.  Clang internally does this, so if we were
+             to just pass the option through, clang would work.  The problem is
+             that MSBuild would not.  MSBuild detects /ZI and /Zi and then
+             assumes (rightly) that there will be a compiler-generated PDB (e.g.
+             vc141.pdb).  Since clang-cl will not emit this, MSBuild will always
+             think that the compiler-generated PDB needs to be re-generated from
+             scratch and trigger a full build.  The way to avoid this is to
+             always give MSBuild accurate information about how we plan to
+             generate debug info (which is to always using /Z7 semantics).
+             -->
+        <DebugInformationFormat Condition="'%(ClCompile.DebugInformationFormat)' == 'ProgramDatabase'">OldStyle</DebugInformationFormat>
+        <DebugInformationFormat Condition="'%(ClCompile.DebugInformationFormat)' == 'EditAndContinue'">OldStyle</DebugInformationFormat>
+
+        <!-- Unset any options that we either silently ignore or warn about due to compatibility.
+             Generally when an option is set to no value, that means "Don't pass an option to the
+             compiler at all."
+             -->
+        <WholeProgramOptimization/>
+        <EnableFiberSafeOptimizations/>
+        <IgnoreStandardIncludePath/>
+        <EnableParallelCodeGeneration/>
+        <ForceConformanceInForLoopScope/>
+        <TreatWChar_tAsBuiltInType/>
+        <SDLCheck/>
+        <GenerateXMLDocumentationFiles/>
+        <BrowseInformation/>
+        <EnablePREfast/>
+        <MinimalRebuild/>
+        <StringPooling/>
+        <ExpandAttributedSource/>
+        <EnforceTypeConversionRules/>
+        <ErrorReporting/>
+        <DisableLanguageExtensions/>
+        <ProgramDataBaseFileName/>
+        <DisableSpecificWarnings/>
+        <TreatSpecificWarningsAsErrors/>
+        <ForcedUsingFiles/>
+        <PREfastLog/>
+        <PREfastAdditionalOptions/>
+        <PREfastAdditionalPlugins/>
+        <MultiProcessorCompilation/>
+        <UseFullPaths/>
+        <RemoveUnreferencedCodeData/>
+
+        <!-- We can't just unset BasicRuntimeChecks, as that will pass /RTCu to the compiler.
+             We have to explicitly set it to 'Default' to avoid passing anything. -->
+        <BasicRuntimeChecks>Default</BasicRuntimeChecks>
+      </ClCompile>
+    </ItemGroup>
+  </Target>
+
+</Project>

llvm/tools/msbuild/Microsoft.Cpp.Win32.LLVM-vs2010.targets

-<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
-</Project>

llvm/tools/msbuild/Microsoft.Cpp.Win32.LLVM-vs2012.targets

-<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
-  <Import Project="$(VCTargetsPath)\Microsoft.CppCommon.targets" />
-</Project>

llvm/tools/msbuild/Microsoft.Cpp.Win32.LLVM-vs2012_xp.targets

-<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
-  <!-- Force TargetFrameworkVersion to v4.0 to support XP-->
-  <PropertyGroup>
-    <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
-    <BeforeClCompileTargets>NoSupportCodeAnalysisXP;$(BeforeClCompileTargets)</BeforeClCompileTargets>
-  </PropertyGroup>
-
-  <Import Project="$(VCTargetsPath)\Microsoft.CppCommon.targets" />
-
-  <Target Name="NoSupportCodeAnalysisXP" Condition="'$(ErrorNoSupportCodeAnalysisXP)' != 'false'">
-    <VCMessage Condition="'$(DesignTimeBuild)' != 'true' and '@(ClCompile->AnyHaveMetadataValue('EnablePREfast', 'true'))'=='true'" Code="MSB8026" Type="Error"/>
-  </Target>
-
-  <PropertyGroup>
-    <PrepareForBuildDependsOn>CheckWindowsSDK71A;$(PrepareForBuildDependsOn)</PrepareForBuildDependsOn>
-  </PropertyGroup>
-
-  <Target Name="CheckWindowsSDK71A">
-    <VCMessage Code="MSB8003" Type="Warning" Arguments="WindowsSdkDir_71A" Condition="'$(WindowsSdkDir_71A)'=='' and '$(UseEnv)' != 'true'" />
-  </Target>
-</Project>

llvm/tools/msbuild/Microsoft.Cpp.Win32.llvm.props.in

-<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">  
-  <Import Project="$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\@VS_VERSION@\Microsoft.Cpp.$(Platform).@VS_VERSION@.props" Condition="Exists('$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\@VS_VERSION@\Microsoft.Cpp.$(Platform).@VS_VERSION@.props')"/>
-  <Import Project="$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\@VS_VERSION@\Toolset.props" Condition="Exists('$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\@VS_VERSION@\Toolset.props')"/>
-
-  <PropertyGroup>
-    <LLVMInstallDir>$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\LLVM\@REG_KEY@)</LLVMInstallDir>
-    <LLVMInstallDir Condition="'$(LLVMInstallDir)' == ''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\LLVM\@REG_KEY@)</LLVMInstallDir>
-    <ExecutablePath>$(LLVMInstallDir)\msbuild-bin;$(ExecutablePath)</ExecutablePath>
-    <LibraryPath>$(LLVMInstallDir)\lib\clang\@LIB_PATH_VERSION@\lib\windows;$(LibraryPath)</LibraryPath>
-  </PropertyGroup>
-
-  <ItemDefinitionGroup>
-    <ClCompile>
-      <!-- Set the value of _MSC_VER to claim for compatibility -->
-      <AdditionalOptions>-@mflag@ -fmsc-version=@MSC_VERSION@ %(AdditionalOptions)</AdditionalOptions>
-    </ClCompile>
-  </ItemDefinitionGroup>
-</Project>

llvm/tools/msbuild/Platformx64/Toolset.props

+<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
+  <Import Project="$(VCTargetsPath)\LLVM.Cpp.Common.props"/>
+
+  <PropertyGroup>
+    <ExecutablePath Condition="'$(ExecutablePath)' == ''">$(VC_ExecutablePath_x64);$(WindowsSDK_ExecutablePath);$(VS_ExecutablePath);$(MSBuild_ExecutablePath);$(FxCopDir);$(PATH);</ExecutablePath>
+    <ReferencePath Condition="'$(ReferencePath)' == ''">$(VC_ReferencesPath_x64);</ReferencePath>
+    <LibraryPath Condition="'$(LibraryPath)' == ''">$(VC_LibraryPath_x64);$(WindowsSDK_LibraryPath_x64);$(NETFXKitsDir)Lib\um\x64</LibraryPath>
+    <ExcludePath Condition="'$(ExcludePath)' == ''">$(VC_IncludePath);$(WindowsSDK_IncludePath);$(MSBuild_ExecutablePath);$(VC_LibraryPath_x64);</ExcludePath>
+    <DebugCppRuntimeFilesPath Condition="'$(DebugCppRuntimeFilesPath)' == ''">$(VCToolsInstallDir)redist\Debug_NonRedist\x64</DebugCppRuntimeFilesPath>
+  </PropertyGroup>
+</Project>

llvm/tools/msbuild/Platformx64/Toolset.targets

+<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
+  <Import Project="$(VCTargetsPath)\LLVM.Cpp.Common.targets"/>
+</Project>

llvm/tools/msbuild/Platformx86/Toolset.props

+<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
+  <Import Project="$(VCTargetsPath)\LLVM.Cpp.Common.props"/>
+
+  <PropertyGroup>
+    <ExecutablePath Condition="'$(ExecutablePath)' == ''">$(VC_ExecutablePath_x86);$(WindowsSDK_ExecutablePath);$(VS_ExecutablePath);$(MSBuild_ExecutablePath);$(SystemRoot)\SysWow64;$(FxCopDir);$(PATH);</ExecutablePath>
+    <ReferencePath Condition="'$(ReferencePath)' == ''">$(VC_ReferencesPath_x86);</ReferencePath>
+    <LibraryPath Condition="'$(LibraryPath)' == ''">$(VC_LibraryPath_x86);$(WindowsSDK_LibraryPath_x86);$(NETFXKitsDir)Lib\um\x86</LibraryPath>
+    <ExcludePath Condition="'$(ExcludePath)' == ''">$(VC_IncludePath);$(WindowsSDK_IncludePath);$(MSBuild_ExecutablePath);$(VC_LibraryPath_x86);</ExcludePath>
+    <DebugCppRuntimeFilesPath Condition="'$(DebugCppRuntimeFilesPath)' == ''">$(VCToolsInstallDir)redist\Debug_NonRedist\x86</DebugCppRuntimeFilesPath>
+  </PropertyGroup>
+</Project>

llvm/tools/msbuild/Platformx86/Toolset.targets

+<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
+  <Import Project="$(VCTargetsPath)\LLVM.Cpp.Common.targets"/>
+</Project>

llvm/tools/msbuild/install.bat

-@echo off
-
-echo Installing MSVC integration...
-set SUCCESS=0
-
-REM Change to the directory of this batch file.
-cd /d %~dp0
-
-REM Loop over the two platforms in awkward batch file fashion.
-set PLATFORM=None
-:PLATFORMLOOPHEAD
-IF %PLATFORM% == x64 GOTO PLATFORMLOOPEND
-IF %PLATFORM% == Win32 SET PLATFORM=x64
-IF %PLATFORM% == None SET PLATFORM=Win32
-
-REM Search for the MSBuild toolsets directory.
-
-SET D="%ProgramFiles%\MSBuild\Microsoft.Cpp\v4.0\Platforms\%PLATFORM%\PlatformToolsets"
-IF EXIST %D% GOTO FOUND_V100
-SET D="%ProgramFiles(x86)%\MSBuild\Microsoft.Cpp\v4.0\Platforms\%PLATFORM%\PlatformToolsets"
-IF EXIST %D% GOTO FOUND_V100
-
-:TRY_V110
-SET D="%ProgramFiles%\MSBuild\Microsoft.Cpp\v4.0\V110\Platforms\%PLATFORM%\PlatformToolsets"
-IF EXIST %D% GOTO FOUND_V110
-SET D="%ProgramFiles(x86)%\MSBuild\Microsoft.Cpp\v4.0\V110\Platforms\%PLATFORM%\PlatformToolsets"
-IF EXIST %D% GOTO FOUND_V110
-
-:TRY_V120
-SET D="%ProgramFiles%\MSBuild\Microsoft.Cpp\v4.0\V120\Platforms\%PLATFORM%\PlatformToolsets"
-IF EXIST %D% GOTO FOUND_V120
-SET D="%ProgramFiles(x86)%\MSBuild\Microsoft.Cpp\v4.0\V120\Platforms\%PLATFORM%\PlatformToolsets"
-IF EXIST %D% GOTO FOUND_V120
-
-:TRY_V140
-SET D="%ProgramFiles%\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\%PLATFORM%\PlatformToolsets"
-IF EXIST %D% GOTO FOUND_V140
-SET D="%ProgramFiles(x86)%\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\%PLATFORM%\PlatformToolsets"
-IF EXIST %D% GOTO FOUND_V140
-
-:TRY_V150
-
-GOTO PLATFORMLOOPHEAD
-
-:PLATFORMLOOPEND
-IF %SUCCESS% == 1 goto DONE
-echo Failed to find MSBuild toolsets directory.
-goto FAILED
-
-
-:FOUND_V100
-REM Routine for installing v100 toolchain.
-IF NOT EXIST %D%\LLVM-vs2010 mkdir %D%\LLVM-vs2010
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-copy %PLATFORM%\Microsoft.Cpp.%PLATFORM%.LLVM-vs2010.props %D%\LLVM-vs2010
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-copy %PLATFORM%\Microsoft.Cpp.%PLATFORM%.LLVM-vs2010.targets %D%\LLVM-vs2010
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-set SUCCESS=1
-GOTO TRY_V110
-
-:FOUND_V110
-REM Routine for installing v110 toolchain.
-IF NOT EXIST %D%\LLVM-vs2012 mkdir %D%\LLVM-vs2012
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-copy %PLATFORM%\Microsoft.Cpp.%PLATFORM%.LLVM-vs2012.props %D%\LLVM-vs2012
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-copy %PLATFORM%\Microsoft.Cpp.%PLATFORM%.LLVM-vs2012.targets %D%\LLVM-vs2012
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-IF NOT EXIST %D%\LLVM-vs2012_xp mkdir %D%\LLVM-vs2012_xp
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-copy %PLATFORM%\Microsoft.Cpp.%PLATFORM%.LLVM-vs2012_xp.props %D%\LLVM-vs2012_xp
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-copy %PLATFORM%\Microsoft.Cpp.%PLATFORM%.LLVM-vs2012_xp.targets %D%\LLVM-vs2012_xp
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-set SUCCESS=1
-GOTO TRY_V120
-
-:FOUND_V120
-REM Routine for installing v120 toolchain.
-IF NOT EXIST %D%\LLVM-vs2013 mkdir %D%\LLVM-vs2013
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-copy %PLATFORM%\toolset-vs2013.props %D%\LLVM-vs2013\toolset.props
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-copy %PLATFORM%\toolset-vs2013.targets %D%\LLVM-vs2013\toolset.targets
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-IF NOT EXIST %D%\LLVM-vs2013_xp mkdir %D%\LLVM-vs2013_xp
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-copy %PLATFORM%\toolset-vs2013_xp.props %D%\LLVM-vs2013_xp\toolset.props
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-copy %PLATFORM%\toolset-vs2013_xp.targets %D%\LLVM-vs2013_xp\toolset.targets
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-set SUCCESS=1
-GOTO TRY_V140
-
-:FOUND_V140
-REM Routine for installing v140 toolchain.
-IF NOT EXIST %D%\LLVM-vs2014 mkdir %D%\LLVM-vs2014
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-copy %PLATFORM%\toolset-vs2014.props %D%\LLVM-vs2014\toolset.props
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-copy %PLATFORM%\toolset-vs2014.targets %D%\LLVM-vs2014\toolset.targets
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-IF NOT EXIST %D%\LLVM-vs2014_xp mkdir %D%\LLVM-vs2014_xp
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-copy %PLATFORM%\toolset-vs2014_xp.props %D%\LLVM-vs2014_xp\toolset.props
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-copy %PLATFORM%\toolset-vs2014_xp.targets %D%\LLVM-vs2014_xp\toolset.targets
-IF NOT %ERRORLEVEL% == 0 GOTO FAILED
-set SUCCESS=1
-GOTO TRY_V150
-
-
-:DONE
-echo Done!
-goto END
-
-:FAILED
-echo MSVC integration install failed.
-pause
-goto END
-
-:END
+@echo off
+
+echo Installing MSVC integration...
+set SUCCESS=0
+
+REM In general this script should not be used except for development and testing
+REM purposes.  The proper way to install is via the VSIX, and the proper way to
+REM uninstall is through the Visual Studio extension manager.
+
+REM Change to the directory of this batch file.
+cd /d %~dp0
+
+REM Older versions of VS would look for these files in the Program Files\MSBuild directory
+REM but with VS2017 it seems to look for these directly in the Visual Studio instance.
+REM This means we'll need to do a little extra work to properly detect all the various
+REM instances, but in reality we can probably sidestep all of this by just wrapping this
+REM in a vsix and calling it a day, as that should handle everything for us.
+SET VCTargets=%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Professional\Common7\IDE\VC\VCTargets
+
+ECHO Installing Common Files
+copy LLVM.Cpp.Common.props "%VCTargets%"
+IF NOT %ERRORLEVEL% == 0 GOTO FAILED
+copy LLVM.Cpp.Common.targets "%VCTargets%"
+IF NOT %ERRORLEVEL% == 0 GOTO FAILED
+
+ECHO Installing x64 Platform Toolset
+SET PlatformToolsets=%VCTargets%\Platforms\x64\PlatformToolsets
+IF NOT EXIST "%PlatformToolsets%\llvm" mkdir "%PlatformToolsets%\llvm"
+IF NOT %ERRORLEVEL% == 0 GOTO FAILED
+copy PlatformX64\Toolset.props "%PlatformToolsets%\llvm"
+IF NOT %ERRORLEVEL% == 0 GOTO FAILED
+copy PlatformX64\Toolset.targets "%PlatformToolsets%\llvm"
+IF NOT %ERRORLEVEL% == 0 GOTO FAILED
+
+ECHO Installing Win32 Platform Toolset
+SET PlatformToolsets=%VCTargets%\Platforms\Win32\PlatformToolsets
+IF NOT EXIST "%PlatformToolsets%\llvm" mkdir "%PlatformToolsets%\llvm"
+IF NOT %ERRORLEVEL% == 0 GOTO FAILED
+copy PlatformX86\Toolset.props "%PlatformToolsets%\llvm"
+IF NOT %ERRORLEVEL% == 0 GOTO FAILED
+copy PlatformX86\Toolset.targets "%PlatformToolsets%\llvm"
+IF NOT %ERRORLEVEL% == 0 GOTO FAILED
+
+ECHO Installing C++ Settings UI
+copy llvm-general.xml "%VCTargets%\1033"
+IF NOT %ERRORLEVEL% == 0 GOTO FAILED
+
+:DONE
+echo Done!
+goto END
+
+:FAILED
+echo MSVC integration install failed.
+pause
+goto END
+
+:END

llvm/tools/msbuild/license.txt

+====================
+LLVM Release License
+====================
+University of Illinois/NCSA
+Open Source License
+
+Copyright (c) 2007-2018 University of Illinois at Urbana-Champaign.
+All rights reserved.
+
+Developed by:
+
+    LLVM Team
+
+    University of Illinois at Urbana-Champaign
+
+    http://llvm.org
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal with the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+    * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimers.
+
+    * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimers in the documentation and/or other materials provided with the distribution.
+
+    * Neither the names of the LLVM Team, University of Illinois at Urbana-Champaign, nor the names of its contributors may be used to endorse or promote products derived from this Software without specific prior written permission.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS WITH THE SOFTWARE.
+
+====================
+The LLVM software contains code written by third parties.  Such software will have its own individual LICENSE.TXT file in the directory in which it appears.  This file will describe the copyrights, license, and restrictions which apply
+to that code.
+
+The disclaimer of warranty in the University of Illinois Open Source License applies to all code in the LLVM Distribution, and nothing in any of the other licenses gives permission to use the names of the LLVM Team or the University of Illinois to endorse or promote products derived from this Software.
+
+The following pieces of software have additional or alternate copyrights, licenses, and/or restrictions:
+
+Program             Directory
+-------             ---------
+<none yet>
+

llvm/tools/msbuild/llvm-general.xml

+<?xml version="1.0" encoding="utf-8"?>
+<Rule
+      Name="LLVMGeneral"
+      DisplayName="LLVM"
+      PageTemplate="generic"
+      Description="LLVM"
+      xmlns="http://schemas.microsoft.com/build/2009/properties">
+  <Rule.Categories>
+    <Category Name="General" DisplayName="General" Description="General" />
+  </Rule.Categories>
+  <Rule.DataSource>
+    <DataSource Persistence="ProjectFile" Label="Configuration" />
+  </Rule.DataSource>
+
+  <StringProperty Name="ClangClExecutable"
+                  DisplayName="Clang-CL Executable"
+                  Description="Specifies the path to clang-cl.exe."
+                  Category="General"
+                  Default="$(LLVMInstallDir)bin\clang-cl.exe"
+                  Subtype="file">
+    <StringProperty.DataSource>
+      <DataSource Persistence="ProjectFile" Label="" />
+    </StringProperty.DataSource>
+  </StringProperty>
+</Rule>

llvm/tools/msbuild/llvm.csproj

+<?xml version="1.0" encoding="utf-8"?>
+<Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
+  <PropertyGroup>
+    <MinimumVisualStudioVersion>15.0</MinimumVisualStudioVersion>
+    <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
+  </PropertyGroup>
+  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
+  <PropertyGroup>
+    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
+    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
+    <SchemaVersion>2.0</SchemaVersion>
+    <ProjectTypeGuids>{82b43b9b-a64c-4715-b499-d71e9ca2bd60};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
+    <ProjectGuid>{62530D9E-1B24-4C31-8DC9-AE47E9E5DC53}</ProjectGuid>
+    <OutputType>Library</OutputType>
+    <AppDesignerFolder>Properties</AppDesignerFolder>
+    <RootNamespace>llvm</RootNamespace>
+    <AssemblyName>llvm</AssemblyName>
+    <TargetFrameworkVersion>v4.6.1</TargetFrameworkVersion>
+    <GeneratePkgDefFile>false</GeneratePkgDefFile>
+    <IncludeAssemblyInVSIXContainer>false</IncludeAssemblyInVSIXContainer>
+    <IncludeDebugSymbolsInVSIXContainer>false</IncludeDebugSymbolsInVSIXContainer>
+    <IncludeDebugSymbolsInLocalVSIXDeployment>false</IncludeDebugSymbolsInLocalVSIXDeployment>
+    <CopyBuildOutputToOutputDirectory>false</CopyBuildOutputToOutputDirectory>
+    <CopyOutputSymbolsToOutputDirectory>false</CopyOutputSymbolsToOutputDirectory>
+    <StartAction>Program</StartAction>
+    <StartProgram Condition="'$(DevEnvDir)' != ''">$(DevEnvDir)devenv.exe</StartProgram>
+    <StartArguments>/rootsuffix Exp</StartArguments>
+  </PropertyGroup>
+  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
+    <DebugSymbols>true</DebugSymbols>
+    <DebugType>full</DebugType>
+    <Optimize>false</Optimize>
+    <OutputPath>bin\Debug\</OutputPath>
+    <DefineConstants>DEBUG;TRACE</DefineConstants>
+    <ErrorReport>prompt</ErrorReport>
+    <WarningLevel>4</WarningLevel>
+  </PropertyGroup>
+  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
+    <DebugType>pdbonly</DebugType>
+    <Optimize>true</Optimize>
+    <OutputPath>bin\Release\</OutputPath>
+    <DefineConstants>TRACE</DefineConstants>
+    <ErrorReport>prompt</ErrorReport>
+    <WarningLevel>4</WarningLevel>
+  </PropertyGroup>
+  <ItemGroup>
+    <Content Include="llvm-general.xml">
+      <IncludeInVSIX>true</IncludeInVSIX>
+      <InstallRoot>VCTargets</InstallRoot>
+      <VSIXSubPath>1033</VSIXSubPath>
+    </Content>
+    <Content Include="LLVM.Cpp.Common.props">
+      <IncludeInVSIX>true</IncludeInVSIX>
+      <InstallRoot>VCTargets</InstallRoot>
+    </Content>
+    <Content Include="license.txt">
+      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
+      <IncludeInVSIX>true</IncludeInVSIX>
+    </Content>
+    <Content Include="LLVM.Cpp.Common.targets">
+      <IncludeInVSIX>true</IncludeInVSIX>
+      <InstallRoot>VCTargets</InstallRoot>
+    </Content>
+    <None Include="source.extension.vsixmanifest">
+      <SubType>Designer</SubType>
+    </None>
+    <Content Include="Platformx64\Toolset.props">
+      <IncludeInVSIX>true</IncludeInVSIX>
+      <InstallRoot>VCTargets</InstallRoot>
+      <VSIXSubPath>Platforms\x64\PlatformToolsets\llvm</VSIXSubPath>
+    </Content>
+    <Content Include="Platformx64\Toolset.targets">
+      <IncludeInVSIX>true</IncludeInVSIX>
+      <InstallRoot>VCTargets</InstallRoot>
+      <VSIXSubPath>Platforms\x64\PlatformToolsets\llvm</VSIXSubPath>
+    </Content>
+    <Content Include="Platformx86\Toolset.props">
+      <IncludeInVSIX>true</IncludeInVSIX>
+      <InstallRoot>VCTargets</InstallRoot>
+      <VSIXSubPath>Platforms\Win32\PlatformToolsets\llvm</VSIXSubPath>
+    </Content>
+    <Content Include="Platformx86\Toolset.targets">
+      <IncludeInVSIX>true</IncludeInVSIX>
+      <InstallRoot>VCTargets</InstallRoot>
+      <VSIXSubPath>Platforms\Win32\PlatformToolsets\llvm</VSIXSubPath>
+    </Content>
+  </ItemGroup>
+  <ItemGroup>
+    <Folder Include="Properties\" />
+  </ItemGroup>
+  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
+  <Import Project="$(VSToolsPath)\VSSDK\Microsoft.VsSDK.targets" Condition="'$(VSToolsPath)' != ''" />
+  <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
+       Other similar extension points exist, see Microsoft.Common.targets.
+  <Target Name="BeforeBuild">
+  </Target>
+  <Target Name="AfterBuild">
+  </Target>
+  -->
+</Project>
 No newline at end of file

llvm/tools/msbuild/llvm.sln

+
+Microsoft Visual Studio Solution File, Format Version 12.00
+# Visual Studio 15
+VisualStudioVersion = 15.0.27004.2006
+MinimumVisualStudioVersion = 10.0.40219.1
+Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "llvm", "llvm.csproj", "{62530D9E-1B24-4C31-8DC9-AE47E9E5DC53}"
+EndProject
+Global
+  GlobalSection(SolutionConfigurationPlatforms) = preSolution
+    Debug|Any CPU = Debug|Any CPU
+    Release|Any CPU = Release|Any CPU
+  EndGlobalSection
+  GlobalSection(ProjectConfigurationPlatforms) = postSolution
+    {62530D9E-1B24-4C31-8DC9-AE47E9E5DC53}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
+    {62530D9E-1B24-4C31-8DC9-AE47E9E5DC53}.Debug|Any CPU.Build.0 = Debug|Any CPU
+    {62530D9E-1B24-4C31-8DC9-AE47E9E5DC53}.Release|Any CPU.ActiveCfg = Release|Any CPU
+    {62530D9E-1B24-4C31-8DC9-AE47E9E5DC53}.Release|Any CPU.Build.0 = Release|Any CPU
+  EndGlobalSection
+  GlobalSection(SolutionProperties) = preSolution
+    HideSolutionNode = FALSE
+  EndGlobalSection
+  GlobalSection(ExtensibilityGlobals) = postSolution
+    SolutionGuid = {BD0FC803-C28B-4327-A129-CFB35C873897}
+  EndGlobalSection
+EndGlobal

llvm/tools/msbuild/source.extension.vsixmanifest

+<?xml version="1.0" encoding="utf-8"?>
+<PackageManifest Version="2.0.0" xmlns="http://schemas.microsoft.com/developer/vsx-schema/2011" xmlns:d="http://schemas.microsoft.com/developer/vsx-schema-design/2011">
+    <Metadata>
+        <Identity Id="llvm.d29c51f0-961f-4e20-aad6-356af569907f" Version="1.0" Language="en-US" Publisher="The LLVM Foundation" />
+        <DisplayName>LLVM Compiler Toolchain</DisplayName>
+        <Description xml:space="preserve">Allows the LLVM Compiler Toolchain (installed separately) to be used from within Visual Studio to build C/C++ Projects.</Description>
+        <License>license.txt</License>
+    </Metadata>
+    <Installation AllUsers="true">
+        <InstallationTarget Id="Microsoft.VisualStudio.Community" Version="[14.0,16.0)" />
+        <InstallationTarget Version="[14.0,16.0)" Id="Microsoft.VisualStudio.Pro" />
+        <InstallationTarget Version="[14.0,16.0)" Id="Microsoft.VisualStudio.Enterprise" />
+    </Installation>
+    <Dependencies>
+        <Dependency Id="Microsoft.Framework.NDP" DisplayName="Microsoft .NET Framework" d:Source="Manual" Version="[4.5,)" />
+    </Dependencies>
+    <Prerequisites>
+        <Prerequisite Id="Microsoft.VisualStudio.Component.CoreEditor" Version="[15.0,16.0)" DisplayName="Visual Studio core editor" />
+        <Prerequisite Id="Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Core" Version="[15.0.26621.2,16.0)" DisplayName="Visual C++ core desktop features" />
+        <Prerequisite Id="Microsoft.VisualStudio.Component.VC.CoreIde" Version="[15.0.26606.0,16.0)" DisplayName="Visual Studio C++ core features" />
+    </Prerequisites>
+</PackageManifest>

llvm/tools/msbuild/toolset-vs2013.targets

-<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
-  <Import Project="$(VCTargetsPath)\Microsoft.CppCommon.targets" />
-</Project>

llvm/tools/msbuild/toolset-vs2013_xp.targets

-<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
-  <!-- Force TargetFrameworkVersion to v4.0 to support XP-->
-  <PropertyGroup>
-    <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
-    <BeforeClCompileTargets>NoSupportCodeAnalysisXP;$(BeforeClCompileTargets)</BeforeClCompileTargets>
-  </PropertyGroup>
-
-  <Import Project="$(VCTargetsPath)\Microsoft.CppCommon.targets" />
-
-  <Target Name="NoSupportCodeAnalysisXP" Condition="'$(ErrorNoSupportCodeAnalysisXP)' != 'false'">
-    <VCMessage Condition="'$(DesignTimeBuild)' != 'true' and '@(ClCompile->AnyHaveMetadataValue('EnablePREfast', 'true'))'=='true'" Code="MSB8026" Type="Error"/>
-  </Target>
-
-  <PropertyGroup>
-    <PrepareForBuildDependsOn>CheckWindowsSDK71A;$(PrepareForBuildDependsOn)</PrepareForBuildDependsOn>
-  </PropertyGroup>
-
-  <Target Name="CheckWindowsSDK71A">
-    <VCMessage Code="MSB8003" Type="Warning" Arguments="WindowsSdkDir_71A" Condition="'$(WindowsSdkDir_71A)'=='' and '$(UseEnv)' != 'true'" />
-  </Target>
-</Project>

llvm/tools/msbuild/toolset-vs2014.targets

-<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
-  <Import Project="$(VCTargetsPath)\Microsoft.CppCommon.targets" />
-</Project>

llvm/tools/msbuild/toolset-vs2014_xp.targets

-<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
-  <!-- Force TargetFrameworkVersion to v4.0 to support XP-->
-  <PropertyGroup>
-    <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
-    <BeforeClCompileTargets>NoSupportCodeAnalysisXP;$(BeforeClCompileTargets)</BeforeClCompileTargets>
-  </PropertyGroup>
-
-  <Import Project="$(VCTargetsPath)\Microsoft.CppCommon.targets" />
-
-  <Target Name="NoSupportCodeAnalysisXP" Condition="'$(ErrorNoSupportCodeAnalysisXP)' != 'false'">
-    <VCMessage Condition="'$(DesignTimeBuild)' != 'true' and '@(ClCompile->AnyHaveMetadataValue('EnablePREfast', 'true'))'=='true'" Code="MSB8026" Type="Error"/>
-  </Target>
-
-  <PropertyGroup>
-    <PrepareForBuildDependsOn>CheckWindowsSDK71A;$(PrepareForBuildDependsOn)</PrepareForBuildDependsOn>
-  </PropertyGroup>
-
-  <Target Name="CheckWindowsSDK71A">
-    <VCMessage Code="MSB8003" Type="Warning" Arguments="WindowsSdkDir_71A" Condition="'$(WindowsSdkDir_71A)'=='' and '$(UseEnv)' != 'true'" />
-  </Target>
-</Project>

llvm/tools/msbuild/uninstall.bat

-@echo off
-
-echo Uninstalling MSVC integration...
-
-REM CD to the directory of this batch file.
-cd /d %~dp0
-
-set PLATFORM=None
-:LOOPHEAD
-IF %PLATFORM% == x64 GOTO LOOPEND
-IF %PLATFORM% == Win32 SET PLATFORM=x64
-IF %PLATFORM% == None SET PLATFORM=Win32
-
-
-SET D="%ProgramFiles%\MSBuild\Microsoft.Cpp\v4.0\Platforms\%PLATFORM%\PlatformToolsets"
-IF EXIST %D%\LLVM-vs2010 del %D%\LLVM-vs2010\Microsoft.Cpp.%PLATFORM%.LLVM-vs2010.props
-IF EXIST %D%\LLVM-vs2010 del %D%\LLVM-vs2010\Microsoft.Cpp.%PLATFORM%.LLVM-vs2010.targets
-IF EXIST %D%\LLVM-vs2010 rmdir %D%\LLVM-vs2010
-SET D="%ProgramFiles(x86)%\MSBuild\Microsoft.Cpp\v4.0\Platforms\%PLATFORM%\PlatformToolsets"
-IF EXIST %D%\LLVM-vs2010 del %D%\LLVM-vs2010\Microsoft.Cpp.%PLATFORM%.LLVM-vs2010.props
-IF EXIST %D%\LLVM-vs2010 del %D%\LLVM-vs2010\Microsoft.Cpp.%PLATFORM%.LLVM-vs2010.targets
-IF EXIST %D%\LLVM-vs2010 rmdir %D%\LLVM-vs2010
-
-SET D="%ProgramFiles%\MSBuild\Microsoft.Cpp\v4.0\V110\Platforms\%PLATFORM%\PlatformToolsets"
-IF EXIST %D%\LLVM-vs2012 del %D%\LLVM-vs2012\Microsoft.Cpp.%PLATFORM%.LLVM-vs2012.props
-IF EXIST %D%\LLVM-vs2012 del %D%\LLVM-vs2012\Microsoft.Cpp.%PLATFORM%.LLVM-vs2012.targets
-IF EXIST %D%\LLVM-vs2012 rmdir %D%\LLVM-vs2012
-IF EXIST %D%\LLVM-vs2012_xp del %D%\LLVM-vs2012_xp\Microsoft.Cpp.%PLATFORM%.LLVM-vs2012_xp.props
-IF EXIST %D%\LLVM-vs2012_xp del %D%\LLVM-vs2012_xp\Microsoft.Cpp.%PLATFORM%.LLVM-vs2012_xp.targets
-IF EXIST %D%\LLVM-vs2012_xp rmdir %D%\LLVM-vs2012_xp
-SET D="%ProgramFiles(x86)%\MSBuild\Microsoft.Cpp\v4.0\V110\Platforms\%PLATFORM%\PlatformToolsets"
-IF EXIST %D%\LLVM-vs2012 del %D%\LLVM-vs2012\Microsoft.Cpp.%PLATFORM%.LLVM-vs2012.props
-IF EXIST %D%\LLVM-vs2012 del %D%\LLVM-vs2012\Microsoft.Cpp.%PLATFORM%.LLVM-vs2012.targets
-IF EXIST %D%\LLVM-vs2012 rmdir %D%\LLVM-vs2012
-IF EXIST %D%\LLVM-vs2012_xp del %D%\LLVM-vs2012_xp\Microsoft.Cpp.%PLATFORM%.LLVM-vs2012_xp.props
-IF EXIST %D%\LLVM-vs2012_xp del %D%\LLVM-vs2012_xp\Microsoft.Cpp.%PLATFORM%.LLVM-vs2012_xp.targets
-IF EXIST %D%\LLVM-vs2012_xp rmdir %D%\LLVM-vs2012_xp
-
-SET D="%ProgramFiles%\MSBuild\Microsoft.Cpp\v4.0\V120\Platforms\%PLATFORM%\PlatformToolsets"
-IF EXIST %D%\LLVM-vs2013 del %D%\LLVM-vs2013\toolset.props
-IF EXIST %D%\LLVM-vs2013 del %D%\LLVM-vs2013\toolset.targets
-IF EXIST %D%\LLVM-vs2013 rmdir %D%\LLVM-vs2013
-IF EXIST %D%\LLVM-vs2013_xp del %D%\LLVM-vs2013_xp\toolset.props
-IF EXIST %D%\LLVM-vs2013_xp del %D%\LLVM-vs2013_xp\toolset.targets
-IF EXIST %D%\LLVM-vs2013_xp rmdir %D%\LLVM-vs2013_xp
-SET D="%ProgramFiles(x86)%\MSBuild\Microsoft.Cpp\v4.0\V120\Platforms\%PLATFORM%\PlatformToolsets"
-IF EXIST %D%\LLVM-vs2013 del %D%\LLVM-vs2013\toolset.props
-IF EXIST %D%\LLVM-vs2013 del %D%\LLVM-vs2013\toolset.targets
-IF EXIST %D%\LLVM-vs2013 rmdir %D%\LLVM-vs2013
-IF EXIST %D%\LLVM-vs2013_xp del %D%\LLVM-vs2013_xp\toolset.props
-IF EXIST %D%\LLVM-vs2013_xp del %D%\LLVM-vs2013_xp\toolset.targets
-IF EXIST %D%\LLVM-vs2013_xp rmdir %D%\LLVM-vs2013_xp
-
-SET D="%ProgramFiles%\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\%PLATFORM%\PlatformToolsets"
-IF EXIST %D%\LLVM-vs2014 del %D%\LLVM-vs2014\toolset.props
-IF EXIST %D%\LLVM-vs2014 del %D%\LLVM-vs2014\toolset.targets
-IF EXIST %D%\LLVM-vs2014 rmdir %D%\LLVM-vs2014
-IF EXIST %D%\LLVM-vs2014_xp del %D%\LLVM-vs2014_xp\toolset.props
-IF EXIST %D%\LLVM-vs2014_xp del %D%\LLVM-vs2014_xp\toolset.targets
-IF EXIST %D%\LLVM-vs2014_xp rmdir %D%\LLVM-vs2014_xp
-SET D="%ProgramFiles(x86)%\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\%PLATFORM%\PlatformToolsets"
-IF EXIST %D%\LLVM-vs2014 del %D%\LLVM-vs2014\toolset.props
-IF EXIST %D%\LLVM-vs2014 del %D%\LLVM-vs2014\toolset.targets
-IF EXIST %D%\LLVM-vs2014 rmdir %D%\LLVM-vs2014
-IF EXIST %D%\LLVM-vs2014_xp del %D%\LLVM-vs2014_xp\toolset.props
-IF EXIST %D%\LLVM-vs2014_xp del %D%\LLVM-vs2014_xp\toolset.targets
-IF EXIST %D%\LLVM-vs2014_xp rmdir %D%\LLVM-vs2014_xp
-
-
-GOTO LOOPHEAD
-
-:LOOPEND
-echo Done!
+@echo off
+
+echo Uninstalling MSVC integration...
+
+REM In general this script should not be used except for development and testing
+REM purposes.  The proper way to install is via the VSIX, and the proper way to
+REM uninstall is through the Visual Studio extension manager.
+
+REM CD to the directory of this batch file.
+cd /d %~dp0
+
+SET VCTargets=%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Professional\Common7\IDE\VC\VCTargets
+
+ECHO Uninstalling Common Files
+IF EXIST "%VCTargets%\LLVM.Cpp.Common.props" del "%VCTargets%\LLVM.Cpp.Common.props"
+IF EXIST "%VCTargets%\LLVM.Cpp.Common.targets" del "%VCTargets%\LLVM.Cpp.Common.targets"
+
+ECHO Uninstalling x64 Platform Toolset
+SET PlatformToolsets=%VCTargets%\Platforms\x64\PlatformToolsets
+IF EXIST "%PlatformToolsets%\llvm\Toolset.props" del "%PlatformToolsets%\llvm\Toolset.props"
+IF EXIST "%PlatformToolsets%\llvm\Toolset.targets" del "%PlatformToolsets%\llvm\Toolset.targets"
+IF EXIST "%PlatformToolsets%\llvm" rd "%PlatformToolsets%\llvm"
+
+ECHO Uninstalling Win32 Platform Toolset
+SET PlatformToolsets=%VCTargets%\Platforms\Win32\PlatformToolsets
+IF EXIST "%PlatformToolsets%\llvm\Toolset.props" del "%PlatformToolsets%\llvm\Toolset.props"
+IF EXIST "%PlatformToolsets%\llvm\Toolset.targets" del "%PlatformToolsets%\llvm\Toolset.targets"
+IF EXIST "%PlatformToolsets%\llvm" rd "%PlatformToolsets%\llvm"
+
+ECHO Uninstalling C++ Settings UI
+IF EXIST "%VCTargets%\1033\llvm-general.xml" del "%VCTargets%\1033\llvm-general.xml"
+
+echo Done!