[clang] [Clang] Allow raw string literals in C as an extension (PR #88265)

Aaron Ballman via cfe-commits cfe-commits at lists.llvm.org
Thu Apr 18 11:10:51 PDT 2024


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


More information about the cfe-commits mailing list