RFC: Removing clang-cl's /fallback option

clang-cl's /fallback option was added back in 2013 [1] as part of
bringing up clang's native Windows support.

Since then, the Windows support has become quite stable, and I'm not
aware of anyone using /fallback anymore. In Chromium we stopped using
it in 2015 [2].

While /fallback doesn't require a lot of code, it does add a bit of
complexity to the driver (for example it added a special type of Job),
and I worry about the code rotting since it's not getting updated to
handle new flags.

So, are there any objections to removing the /fallback mode? My
proposal is to put a note in the upcoming Clang 12 release, and then
delete the code after the branch point, meaning it would be gone in
Clang 13.

Please let me know what you think.

Thanks,
Hans

1. https://github.com/llvm/llvm-project/commit/87cfa71071d73c702a833f19c9fe035f31c1275d
2. http://crrev.com/340533

+1 from me, fwiw - though I don't have much connection to the Windows
side of things.

[Hans Wennborg]

So, are there any objections to removing the /fallback mode?

None from me - we've never used this while testing MSVC's STL with clang-cl.

Thanks,
STL

Can't say I was aware of /fallback at all.
--paulr

clang-cl's /fallback option was added back in 2013 [1] as part of
bringing up clang's native Windows support.

Since then, the Windows support has become quite stable, and I'm not
aware of anyone using /fallback anymore. In Chromium we stopped using
it in 2015 [2].

While /fallback doesn't require a lot of code, it does add a bit of
complexity to the driver (for example it added a special type of Job),
and I worry about the code rotting since it's not getting updated to
handle new flags.

So, are there any objections to removing the /fallback mode? My
proposal is to put a note in the upcoming Clang 12 release, and then
delete the code after the branch point, meaning it would be gone in
Clang 13.

Please let me know what you think.

No concerns from me, thank you for looking into it!

~Aaron

Although we don’t use fallback mode, we do use /ZW for WinRT extensions, and this isn’t supported by clang-cl (the corollary of this is that we don’t use clang-cl). I’m mostly just posting this as a way to say that /ZW is important for many users of cl, and without /fallback I think those users will be prevented from using clang-cl.

What currently happens when you use clang for Windows support that comes with recent versions of Visual Studio? Does it silently append /fallback on the user’s behalf? Or does it just give you an error if you try to use an unsupported option?

I just checked, and Microsoft's Visual Studio integration doesn't use
the /fallback flag.

Probably users who build with /ZW would apply that to the whole
project, which wouldn't make clang-cl /fallback any different from
using MSVC in the first place.

Since there were no objections, here's a patch: https://reviews.llvm.org/D95876

Farewell, /fallback, we hardly knew ye.

Csaba