sammccall added a comment.
So there's precedent for this in rL185149 <https://reviews.llvm.org/rL185149>
(D1028 <https://reviews.llvm.org/D1028>). @klimek may have historical context.
Overall, this makes sense.
Since the coroutines flag flip landed on the 9.x release branch, we may want
this merged into the branch too.
The configuration (and particularly defaults) is difficult though. I think due
to some excessive cleverness in the past, we're dug into a bit of a hole.
- the default behavior needs to work well for projects using c++20. Given
ambiguous input (e.g. use of `co_yield`, with `LS_Auto`), we should resolve in
favor of this being C++20 rather than a funny-named identifier. 5 years from
now, the former is going to be **much** more common than the latter, and
there's no better time than now to switch the default. The most obvious
implementation of this is having `LS_Auto` run the lexer in C++20 mode, and
requiring users who don't want that to specify C++1x.
- By bucketing C++11/14/17 together, the LS option has effectively evolved into
a tristate: "old/new/detect". The result is we're not capturing user intent
well: lots of `.clang-format` files specify `Cpp11` to mean "new". If we're
going to add a `Cpp20` option, our only sane alternative is to disable C++20
features for such people. It's not actually a backwards-incompatible change at
this point (assuming we get this on the 9.x branch), but it's an unfortunate
situation and it's our fault. We need to improve the system so users have
better options, because next time (when C++23 rolls around) things will be more
complicated. Or if we need to change the behavior for C++17 vs 11...
I think the user intents we should capture here are:
1. pinning to **any** specific version, that's what the codebase uses and we
have a process for bumping it
2. (maybe) floating with the latest language version, the codebase continuously
adopts new constructs and fixes conflicts in old code
3. I don't know/haven't bothered to configure
The reason I'm unsure about 2 is I don't know whether the people setting
`Cpp11` today (in projects using post-C++11 features) have a specific standard
in mind. Maybe we should be conservative and leave it out for now.
This would lead to something like:
enum LanguageStandard {
// Default: attempt to guess based on the file.
// Lexer always runs in the latest standard.
// Preserves backwards-compatible formatting (e.g. vector<vector<int> >) if
the
// input uses it consistently.
LS_Auto,
LS_Cpp03, // Parse and format in C++03-compatible mode
LS_Cpp11, // No longer enables C++14 in the lexer
LS_Cpp14,
LS_Cpp17, // Equivalent to today's Cpp11!
LS_Cpp2a, // Later to be renamed to Cpp23, but we'll keep accepting `Cpp2a`
in the config parser forever
};
The obvious problem here is that this may well break existing projects that use
`Cpp11` and C++14/17 features.
I think we can punt on this by making Cpp11/14 still enable 14/17 in LangOpts
for now (so we don't change behavior, just give people a better way to specify
their intent) and change it later if needed.
What do you think?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D65043/new/
https://reviews.llvm.org/D65043
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
