aaron.ballman added reviewers: urnathan, iains, ChuanqiXu.
aaron.ballman added a comment.

In D121497#3383910 <https://reviews.llvm.org/D121497#3383910>, @compnerd wrote:

> This was something that I was hitting an issue with.

Does cl hit the same issue when building a module that includes intsafe.h?

> In particular, it was a module build for a module which pulled in intsafe.h.  
> Now, given that it is a preprocessor macro, it would stand to reason that it 
> will normally be dropped and thus won't matter if the frontend doesn't 
> actually support a 128-bit type.  However, with a module, we would attempt to 
> process the expression. I do admit it is on a slightly more tenuous ground as 
> Microsoft may somehow do something different.

I am by no means a modules expert (so I'm adding folks to the review who are 
for their input), but I guess I am naively surprised that a module build would 
evaluate the macro's expansion list when no code in the module actually expands 
the macro. So I can't tell whether the issue is that Clang is emitting an error 
when it shouldn't, or whether cl.exe is failing to emit an error when it 
should, or something else. But it seems wrong to me to add a Microsoft 
extension that cl.exe doesn't actually support; that's likely to lead to a fair 
amount of user confusion. But it could also lead to ABI issues later if 
Microsoft did decide to support this type but using slightly different calling 
conventions than Clang uses.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121497/new/

https://reviews.llvm.org/D121497

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to