Quuxplusone added inline comments.

================
Comment at: clang/include/clang/Basic/DiagnosticGroups.td:269
+def CXXPre2BCompatPedantic :
+  DiagGroup<"c++98-c++11-c++14-c++17-c++20-compat-pedantic", [CXXPre2BCompat]>;
 
----------------
aaron.ballman wrote:
> rjmccall wrote:
> > Uh, I think we're a couple standard releases past the point at which we 
> > should have reconsidered this schema.  I guess the problem is that we can't 
> > say `-Wpre-c++23-compat` without jumping the gun.  Is there a problem with 
> > `-Wc++20-compat` and then having the earlier warning groups imply the later 
> > ones?  That seems to be what we do with `-Wc++98-compat`; did we abandon 
> > that approach intentionally?
> @rsmith may have more background here. I was following the pattern already in 
> the file, but I tend to agree that this pattern is not leading us somewhere 
> good. FWIW, I ran into a similar situation with this on the C side of things 
> in D95396, so we should probably be consistent there too.
My understanding is that the //command-line user// is expected to pass
- `clang++ -std=c++20 -Wc++11-compat` to indicate "I want //actually// to 
compile in C++20 mode, but give me warnings about anything that would prevent 
compiling in C++11 mode"
- `clang++ -std=c++17 -Wc++14-compat` to indicate "I want //actually// to 
compile in C++17 mode, but give me warnings about anything that would prevent 
compiling in C++14 mode"
- `clang++ -std=c++14 -Wc++20-compat` to indicate "I want //actually// to 
compile in C++14 mode, but give me warnings about anything that would prevent 
compiling in C++20 mode" — EXCEPT that I think this is not supported. My 
impression is that forward-compatibility warnings are generally just rolled 
into `-Wall` and not handled separately beyond that?

I don't think any human user is expected to pass 
`-Wc++98-c++11-c++14-c++17-c++20-compat` by hand; it's just an internal name 
for a particular subset of `-Wc++98-compat`.

IOW, we could choose a new naming scheme for it, but that would be a purely 
internal change that won't affect how command-line users interact with Clang at 
all (for better and for worse).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95691

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

Reply via email to