1. Teach -Wuser-defined-literals to warn on using double underscores in
literal suffix identifiers.
2. Add -Wdeprecated-literal-operator to warn about the use of the first
grammar production of literal-operator-id, which defaults to off for now.
Differential Revision: https://reviews.llvm.org/D152632
This patch proposes to handle in an uniform fashion
the parsing of strings that are never evaluated,
in asm statement, static assert, attrributes, extern,
etc.
Unevaluated strings are UTF-8 internally and so currently
behave as narrow strings, but these things will diverge with
D93031.
The big question both for this patch and the P2361 paper
is whether we risk breaking code by disallowing
encoding prefixes in this context.
I hope this patch may allow to gather some data on that.
Future work:
Improve the rendering of unicode characters, line break
and so forth in static-assert messages
Reviewed By: aaron.ballman, shafik
Differential Revision: https://reviews.llvm.org/D105759
Missing a `withConst`, so when deducing from a string literal, a `const` is erroneously added to the deduced type.
Reviewed By: ychen
Differential Revision: https://reviews.llvm.org/D154301
Expressions like
```
struct A {};
...
new struct A {};
struct A* b = (1 == 1) ? new struct A : new struct A;
```
were parsed as redefinitions of `struct A` and failed, however as clarified by
`CWG2141` new-expression cannot define a type, so both these examples
should be considered as references to the previously declared `struct A`.
The patch adds a "new" kind context for parsing declaration specifiers in
addition to already existing declarator context in order to track that
the parser is inside of a new expression.
Fixes https://github.com/llvm/llvm-project/issues/34341
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D153857
This patch implemed the change proposed in [P2002R1] to 11.11.1 [class.compare.default] paragraph 1.
A defaulted compariosn operator function must be non-volatile and must either have no ref-qualifier or the ref-qualifier &.
Differential Revision: https://reviews.llvm.org/D148924
P0960R3 and P1975R0 were marked not implemented because
of #61145,
This issue has been fixed and backported to LLVM 16,
the status page should reflect that.
Reviewed By: #clang-language-wg, ayzhao, erichkeane
Differential Revision: https://reviews.llvm.org/D150122
Resolution of this CWG breaks potential dependency loop between complete-class context of non-static data member initializer (NSDMI), and defaulted default constructor, which is `noexcept` depending on NSDMIs among other things.
For whatever reason in C++11 mode we issue an additional note and a different line number for the primary error. But I find the message itself even worse than aforementioned issues. It describes what's going on, but doesn't say what's bad about it. I find the previous version of this message more clear: 8dbc6b2617 . Created an issue for that: #62823
Reviewed By: #clang-language-wg, shafik
Differential Revision: https://reviews.llvm.org/D151034
Now with support for MSVC-specific triples.
CWG977 focus on point of /completeness/ of enums. Wording provided in CWG1482.
CWG1482 and CWG2516 focus on locus (point) of /declaration/. Wording provided in CWG2516.
Reviewed By: clang-language-wg, shafik
Differential Revision: https://reviews.llvm.org/D151042
CWG977 focus on point of /completeness/ of enums. Wording provided in CWG1482.
CWG1482 and CWG2516 focus on locus (point) of /declaration/. Wording provided in CWG2516.
Reviewed By: #clang-language-wg, shafik
Differential Revision: https://reviews.llvm.org/D151042
[[https://wg21.link/p1787 | P1787]]: CWG2213 is resolved by allowing an elaborated-type-specifier to contain a simple-template-id without friend.
Wording: see changes to [dcl.type.elab]]/1.
The gist of the issue is that forward declaration of partial class template specialization was disallowed.
Reviewed By: #clang-language-wg, shafik
Differential Revision: https://reviews.llvm.org/D151032
This is an ongoing series of commits that are reformatting our
Python code.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: MatzeB
Differential Revision: https://reviews.llvm.org/D150761
[[https://wg21.link/p1787 | P1787]]: CWG399 is resolved by explicitly appealing to the lookup for the last component of any suitable nested-name-specifier.
Wording: Otherwise, its nested-name-specifier N shall nominate a type. If N has another nested-name-specifier S, Q is looked up as if its lookup context were that nominated by S. ([basic.lookup.qual]/6.2)
CWG399 revisits a resolution to older CWG244. Our test for CWG244 covers many examples from CWG399, and it was updated in 2020 presumably aware of P1787, so I reused CWG244 test. This approach to reusing was discussed in [[https://reviews.llvm.org/D139095 | a CWG405 patch review]].
Reviewed By: #clang-language-wg, aaron.ballman, shafik
Differential Revision: https://reviews.llvm.org/D147920
Set the charset to UTF-8, link to the actual liscense we used,
claim support for targets LLVM supports instead of listing them
manually, and stop listing individual language standards we support.
None of these files are referenced by anything else on the website, and
the content for these files is quite dated or experiments that did not
pan out. I used a few search engines to see if others were linking to
this content (esp the libstdc++ patches) and did not find significant
evidence that they were.
This commit implements [temp.deduct]p9.
Test updates include:
- New notes in `cxx1y-init-captures.cpp`, `lambda-expressions.cpp`
and 'warn-unused-lambda-capture.cpp'.
This seems to be caused by diagnosing errors earlier (during
deduction) that were previously surfaced later (during
instantiation).
- New error `lambda-unevaluated.cpp` is in line with [temp.deduct]p9.
Reviewed By: erichkeane, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D148802
Prior to P2448R2 we were more aggressive in diagnosing ill-formed
constexpr functions. Many of these restrictions were relaxed and now it
is not required for defaulted comparison operators to call constexpr
functions.
This behavior is extended to before C++23 and diagnostic for it's use
can be enabled w/ -pedantic or -Wc++2b-default-comp-relaxed-constexpr
This fixes: https://github.com/llvm/llvm-project/issues/61238
Differential Revision: https://reviews.llvm.org/D146090
During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.
This updates the reference to c++2b to c++23 and updates the __cplusplus
macro.
Drive-by fixes c++1z -> c++17 and c++2a -> c++20 when seen.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D149553
We filed some CD ballot comments which WG14 considered during the
ballot comment resolution meetings in Jan and Feb 2023, and this
updates our implementation based on the decisions reached. Those
decisions were (paraphrased for brevity):
US 9-034 (REJECTED)
allow (void *)nullptr to be a null pointer constant
US 10-035 (ACCEPTED)
accept the following code, as in C++:
void func(nullptr_t); func(0);
US 22-058 (REJECTED)
accept the following code, as in C++:
nullptr_t val; (void)(1 ? val : 0); (void)(1 ? nullptr : 0);
US 23-062 (REJECTED)
reject the following code, as in C++:
nullptr_t val; bool b1 = val; bool b2 = nullptr;
US 24-061 (ACCEPTED)
accept the following code, as in C++:
nullptr_t val; val = 0;
US 21-068 (ACCEPTED)
accept the following code, as in C++:
(nullptr_t)nullptr;
GB-071 (ACCEPTED)
accept the following code, as in C++:
nullptr_t val; (void)(val == nullptr);
This patch updates the implementation as appropriate, but is primarily
focused around US 10-035, US 24-061, and US 23-062 in terms of
functional changes.
Differential Revision: https://reviews.llvm.org/D148800
There seems to be a lot of documentation is missing
for different command line flags uses.
This create confusion with same looking options, better to
document clearly their uses.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D149405
This change expands testing of UTF-8, UTF-16, and UTF-32 character and string
literals as validation that WG14 N2728 (char16_t & char32_t string literals
shall be UTF-16 & UTF-32) has been implemented.
Reviewed By: cor3ntin, aaron.ballman
Differential Revision: https://reviews.llvm.org/D149098
[[https://wg21.link/p1787 | P1787]]: My clarification in [[ http://lists.isocpp.org/core/2019/06/6614.php | “Where can namespace-scope functions and variables be redeclared?” ]] is applied, resolving CWG1821.
Wording: (If the declaration is not a friend declaration:) If the id-expression in a declarator-id is a qualified-id Q, let S be its lookup context; the declaration shall inhabit a namespace scope. ([dcl.meaning]/1)
Reviewed By: shafik, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D149003
This project doesn't really relate to improving Clang itself and it
contained stale suggestions like working on code modification
functionality in clang-format.
This removes or modifies:
Undefined behavior checking -- we've got UBSan and it's well-known
enough that we don't need to call it out specifically as a need.
Improve target support -- this is largely already complete.
Use clang libraries to extend Ragel with a JIT -- this wasn't really
related to improving Clang.
C++1y feature work -- now talks about C++20, C++2b, and C2x instead.
Universal driver -- the bug report linked to by the UniversalDriver
web page has been closed since 2017.
XML representation of the AST -- we removed this functionality in 2013
and replaced it with a JSON representation a few years later. That is a
best-effort project.
[[https://wg21.link/p1787 | P1787]]: CWG2331 is resolved by defining lookup from complete-class contexts and out-of-line member definitions. The rest of CWG2009 is resolved by making it ill-formed NDR for forward lookup outside a complete-class context to change the results (before overload resolution, to avoid differences in instantiation).
Wording: The result of the search is the declaration set of S(N, T). If it is an invalid set, the program is ill-formed. If it differs from the result of a search in T for N from immediately after the class-specifier of T, the program is ill-formed, no diagnostic required. ([class.member.lookup]/7)
Reviewed By: #clang-language-wg, shafik
Differential Revision: https://reviews.llvm.org/D148263
[[https://wg21.link/p1787 | P1787]]: CWG2331 is resolved by defining lookup from complete-class contexts and out-of-line member definitions.
Wording: The declaration set is the result of a single search in the scope of C for N from immediately after the class-specifier of C if P is in a complete-class context of C or from P otherwise. ([class.member.lookup]/4)
Reviewed By: #clang-language-wg, shafik
Differential Revision: https://reviews.llvm.org/D148260
[[https://wg21.link/p1787 | P1787]]: CWG1894 and its duplicate CWG2199 are resolved per Richard’s proposal for [[ https://listarchives.isocpp.org/cgi-bin/wg21/message?wg=core&msg=28415 | “dr407 still leaves open questions about typedef / tag hiding” ]], using generic conflicting-declaration rules even for typedef, and discarding a redundant typedef-name when looking up an elaborated-type-specifier.
Wording: See changes to [dcl.typedef], [basic.lookup.elab], and [basic.lookup]/4.
Generic conflicting-declaration rules are specified in changes to [basic.scope.scope]. [[ https://cplusplus.github.io/CWG/issues/407.html | CWG407]], [[ https://cplusplus.github.io/CWG/issues/1894.html | CWG1894 ]], and [[ https://cplusplus.github.io/CWG/issues/2199.html | CWG2199 ]] discuss how elaborated type specifiers interact with typedefs, using directives, and using declarations. Since existing test for CWG407 covers examples provided in CWG1894 and CWG2199, and does it in accordance with P1787, I reused parts of it.
Reviewed By: #clang-language-wg, cor3ntin
Differential Revision: https://reviews.llvm.org/D148136
