https://github.com/AaronBallman commented:

Thank you for working on this! Broadly speaking, I think the idea makes a lot 
of sense.

>  GCC does not seem to support raw string literals in C++ before C++11, even 
> if e.g. -std=gnu++03 is passed. Should we follow this behaviour or should we 
> enable raw string literals in earlier C++ language modes as well if -gnu++XY 
> is passed? -fraw-string-literals currently makes it possible to enable them 
> in e.g. C++03.

I think we should follow that behavior; because `R` can be a valid macro 
identifier, being conservative is defensible.

>  -fno-raw-string-literals allows users to disable raw string literals in 
> -gnuXY mode. I thought it might be useful to have this, but do we want it?

I think it's reasonable to have it, but I don't think we should allow it for 
C++11 and later modes unless there's some rationale I'm missing. (I don't think 
we want to let users disable language features in standards modes where the 
feature is standardized without some sort of reasonable justification.)

> The implementation of this currently adds a RawStringLiterals option to the 
> LangOpts; -f[no-]raw-string-literals overrides the default value for it which 
> depends on the language standard. As a consequence, passing e.g. -std=c++11 
> -fno-raw-string-literals will disable raw string literals even though we’re 
> in C++11 mode. Do we want to allow this or should we just ignore 
> -f[no-]raw-string-literals if we’re in C++11 or later?

I think we should either ignore or diagnose it in C++11 or later.

>  This probably deserves a note in LanguageExtensions.rst, but I’m not exactly 
> sure where.

It definitely should be noted in there; I would probably recommend 
https://clang.llvm.org/docs/LanguageExtensions.html#c-11-raw-string-literals 
for the C++ side of things and then something similar for C around where we 
document those.

> Should we add a flag for this to __has_feature/__has_extension?

Yes, but it's a fun question as to which one. We currently use `__has_feature` 
for it in C++:
```
FEATURE(cxx_raw_string_literals, LangOpts.CPlusPlus11)
```
and it seems like it would make sense to continue to do so for C++. But this 
isn't a language feature of C, so `__has_extension` makes sense there. But 
that's confusing because then we've got both, so I'm not entirely certain 
that's the right approach. Perhaps using `__has_feature` for both C and C++ 
makes the most sense?

https://github.com/llvm/llvm-project/pull/88265
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to