Slartibarty wrote:

Sorry about the long delay on this, I have some time now to dedicate to this 
pull request. I'd like to discuss how we should handle the problem of the 
charize operator and `/##/` paste trick remaining usable even when 
`_MSVC_TRADITIONAL` is defined to 0, which is a divergence from MSVC.
I mentioned in a reply that:
> Perhaps the right thing to do here is to not define `_MSVC_TRADITIONAL` at 
> all when using `-fms-extensions`, and relegate it to just 
> `-fms-preprocessor-compat` / `-fno-ms-preprocessor-compat`? I think this 
> would work for most use cases, but I feel that this might go against the 
> expectation of `-fms-extensions` in creating an MSVC-esque environment. These 
> two extensions felt safe enough to leave enabled, but I can see where there 
> would be confusion with a macro that works with Clang, but not MSVC.

There's currently several layers to preprocessor compatibility, and disabling 
the charize operator and paste trick would add extra complexity where I think 
the divergence is warranted. Right now `-fms-extensions` enables those two 
features, and a handful of other small quirks or extensions. There isn't a 
straightforward way for `-fms-preprocessor-compat-` to disable these tricks, as 
`/Zc:preprocessor` does in MSVC, because `-fms-extensions` is responsible for 
those features, so you'd end up with a situation where:

- `-fms-extensions` = can use charize operator and paste trick.
- `-fms-extensions -fms-preprocessor-compat` = ditto.
- `-fms-extensions -fms-preprocessor-compat-` = charize and paste trick are 
errors.

I don't think either solution is great, trying to match MSVC makes this 
confusing, and diverging from it isn't great either, I'd appreciate thoughts 
from others.

https://github.com/llvm/llvm-project/pull/167200
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to