simon_tatham added a comment. I now realise that my previous comment was nonsense: looking at @thakis's link more carefully, there are actually 5 failing tests that are nothing to do with the one I modified, and a lot of them don't even have any obvious `-fms-extension` option in the cc1 command line at all. (Perhaps clang will even turn //that// on automatically when it autodetects MSVC in the environment?) So just fixing my own test differently wouldn't help.
So I don't know what to propose. I'd like to see this error check reland, but I see that it will take some work before the test suite is sufficiently environment-independent to not make it cause this kind of problem all over the place. Right off the top of my head, one thought that strikes me is: why is auto-detection of MS compat mode from the environment happening in //cc1?// (Which I assume it must be, if those cc1 tests are failing.) If the point of it is to make clang-cl a drop-in replacement for the `cl.exe` installed on the same system, would it not make more sense to do the auto-detection in the clang-cl driver, and pass explicit options to cc1 containing whatever was detected (if it wasn't overridden by the driver command line)? Then cc1 would behave the same everywhere given the same command line, and all the cc1 runs in the test suite would be automatically stable, and the only place you'd have to take care would be in tests of the clang-cl driver itself. But that's the kind of structural change that would surely cause a completely different collection of failures in places nobody would have thought of :-) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D73457/new/ https://reviews.llvm.org/D73457 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
