aaron.ballman added inline comments.
================ Comment at: clang/docs/CommandGuide/clang.rst:206-210 + Working draft for ISO C++ 2026 + + | ``gnu++2c`` + + Working draft for ISO C++ 2026 with GNU extensions ---------------- We shouldn't call it `ISO C++ 2026` until it's published by ISO. (I don't have strong opinions about 2c vs 26 in there, but since we need to update it anyway when 26 is released, I figured it'd be easier to find again with 2c.) ================ Comment at: clang/docs/ReleaseNotes.rst:114 +^^^^^^^^^^^^^^^^^^^^^ +- Compiler flags -std=c++2c and -std=gnu++2c have been added for experimental C++2c implementation work. + ---------------- ================ Comment at: clang/include/clang/Basic/DiagnosticGroups.td:1120 +// earlier C++ versions. +def CXX26 : DiagGroup<"c++26-extensions">; + ---------------- Same here as above. ================ Comment at: clang/include/clang/Basic/DiagnosticGroups.td:310 DiagGroup<"pre-c++23-compat-pedantic", [CXXPre23Compat]>; +def CXXPre26Compat : DiagGroup<"pre-c++26-compat">; +def CXXPre26CompatPedantic : ---------------- erichkeane wrote: > Aaron: note the names of the diag groups: would you prefer this to be `c++2c`? Let's go ahead and add the alias so that either c++2c or c++26 works. ================ Comment at: clang/include/clang/Basic/LangOptions.def:101 LANGOPT(CPlusPlus23 , 1, 0, "C++23") +LANGOPT(CPlusPlus26 , 1, 0, "C++26") LANGOPT(ObjC , 1, 0, "Objective-C") ---------------- erichkeane wrote: > It isn't clear to me what the string here is used to output, so not sure if > this should be 2c. The only place this matters is when dumping information about a module file for debugging purposes, so I don't think it's critical this be named 2c. ================ Comment at: clang/include/clang/Basic/LangStandard.h:128 + + // hasDigraphs - Language supports digraphs. bool hasDigraphs() const { return Flags & Digraphs; } ---------------- h-vetinari wrote: > Spuriously removed slash ================ Comment at: clang/include/clang/Basic/LangStandards.def:167 +LANGSTANDARD(cxx26, "c++2c", + CXX, "Working draft for ISO C++ 2026 DIS", + LineComment | CPlusPlus | CPlusPlus11 | CPlusPlus14 | CPlusPlus17 | ---------------- We should probably drop `ISO` from this as we did above? ================ Comment at: clang/lib/Frontend/InitPreprocessor.cpp:456 + // FIXME: Use correct value for C++26. + Builder.defineMacro("__cplusplus", "202402L"); + else if (LangOpts.CPlusPlus23) ---------------- This value is fine by me, but we should probably coordinate with the GCC folks so we don't wind up with two different values between us. ================ Comment at: clang/lib/Frontend/InitPreprocessor.cpp:458 + else if (LangOpts.CPlusPlus23) + Builder.defineMacro("__cplusplus", "202302L"); // [C++20] The integer literal 202002L. ---------------- xbolva00 wrote: > Separate patch / commit? Agreed, the change for C++23 should be done in a separate patch. ================ Comment at: clang/www/OpenProjects.html:126 -<li><b>Continue work on C++20, C++23, and C2x support</b>: +<li><b>Continue work on C++20, C++23, C++26, and C2x support</b>: There are still several C++20 features to complete, and work has begun on ---------------- cor3ntin wrote: > erichkeane wrote: > > Should this spot in the docs be `C++2c`? > I think so Agreed -- basically, if it's user-facing, it should be 2c, and if it's internal to the project, it should be 26. ================ Comment at: clang/www/cxx_status.html:1568 +<h2 id="cxx26">C++2c implementation status</h2> + ---------------- cor3ntin wrote: > h-vetinari wrote: > > The longer this page gets, the more I feel it should be sorted in reverse > > chronological order of the standard versions. It's bothersome IMO to keep > > scrolling past almost-fully implemented standards (currently the tables for > > C++17 & C++20) before getting to see the status of the latest & greatest. > > > > https://en.cppreference.com/w/cpp/compiler_support is sorted in reverse > > order as well. > This sounds like an excellent improvement. > Erich, would you rather do that in this pr, or i can submit a different patch > afterwards? I love the idea, and I think it should be done in a separate patch. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D150450/new/ https://reviews.llvm.org/D150450 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits