Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2 |
|
#
1156bbc5 |
| 02-Feb-2024 |
Krystian Stasiowski <sdkrystian@gmail.com> |
[Clang][Sema] Diagnose use of template keyword after declarative nested-name-specifiers (#78595)
According to [temp.names] p5:
> The keyword template shall not appear immediately after a declarativ
[Clang][Sema] Diagnose use of template keyword after declarative nested-name-specifiers (#78595)
According to [temp.names] p5:
> The keyword template shall not appear immediately after a declarative nested-name-specifier.
[expr.prim.id.qual] p2 defines a declarative nested-name-specifier as follows:
> A nested-name-specifier is declarative if it is part of
> - a class-head-name,
> - an enum-head-name,
> - a qualified-id that is the id-expression of a declarator-id, or
> - a declarative nested-name-specifier.
Note: I believe this definition is defective as it doesn't include _nested-name-specifiers_ appearing in _elaborated-type-specifiers_ that declare partial/explicit specializations and explicit instantiations. See my post to the core reflector. Minus a few bugs that are addressed by this PR, this is how we implement it.
This means that declarations like:
```
template<typename>
struct A
{
template<typename>
struct B
{
void f();
};
};
template<typename T>
template<typename U>
void A<T>::template B<U>::f() { } // error: 'template' cannot be used after a declarative nested name specifier
```
are ill-formed. This PR add diagnostics for such declarations. The name of the diagnostic group is `template-in-declaration-name`.
Regarding the aforementioned "few bugs that are addressed by this PR" in order to correctly implement this:
- `CheckClassTemplate` did not call `diagnoseQualifiedDeclaration` when the semantic context was dependent. This allowed for constructs like:
```
struct A
{
template<typename T>
struct B
{
template<typename U>
struct C;
};
};
template<typename T>
template<typename U>
struct decltype(A())::B<T>::C { };
```
- `ActOnClassTemplateSpecialization` did not call `diagnoseQualifiedDeclaration` at all, allowing for qualified partial/explicit specializations at class scope and other related nonsense
- `TreeTransform::TransformNestedNameSpecifierLoc` would rebuild a `NestedNameSpecifier::TypeSpecWithTemplate` as a `NestedNameSpecifier::TypeSpec`
- `TemplateSpecializationTypeLoc::initializeLocal` would set the `template` keyword `SourceLocation` to the provided `Loc` parameter, which would result in a `TemplateSpecializationTypeLoc` obtained via `ASTContext::getTrivialTypeSourceInfo` being displayed as always having a `template` prefix (since the presence of the keyword is not stored anywhere else).
show more ...
|
Revision tags: llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6 |
|
#
0e86d3ea |
| 27-Nov-2023 |
Timm Baeder <tbaeder@redhat.com> |
[clang] Print static_assert values of arithmetic binary operators (#71671)
These are actually quite useful to print.
|
Revision tags: llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3 |
|
#
2176c5e5 |
| 04-Oct-2023 |
Takuya Shimizu <shimizu2486@gmail.com> |
[Clang][Sema] Fix display of characters on static assertion failure
This patch fixes the display of characters appearing in LHS or RHS of == expression in notes to static assertion failure. This app
[Clang][Sema] Fix display of characters on static assertion failure
This patch fixes the display of characters appearing in LHS or RHS of == expression in notes to static assertion failure. This applies C-style escape if the printed character is a special character. This also adds a numerical value displayed next to the character representation. This also tries to print multi-byte characters if the user-provided expression is multi-byte char type.
Reviewed By: cor3ntin Differential Revision: https://reviews.llvm.org/D155610
show more ...
|
Revision tags: llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2 |
|
#
49e0495f |
| 29-Jul-2023 |
Corentin Jabot <corentinjabot@gmail.com> |
[Clang] Produce a warning instead of an error in unevaluated strings before C++26
Emiting an error on unexpected encoding prefix - which was allowed before C++26 - caused build errors for a few user
[Clang] Produce a warning instead of an error in unevaluated strings before C++26
Emiting an error on unexpected encoding prefix - which was allowed before C++26 - caused build errors for a few users. This downgrade the error to a warning on older language modes and C.
Reviewed By: aaron.ballman, hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D156596
show more ...
|
#
ab4e4a69 |
| 10-Aug-2023 |
Corentin Jabot <corentinjabot@gmail.com> |
Revert "[Clang] Produce a warning instead of an error in unevaluated strings before C++26"
Causes build failure on bots after rebase.
This reverts commit 20e01167b15aa17dac09e4742909a7138eca7afc.
|
#
20e01167 |
| 29-Jul-2023 |
Corentin Jabot <corentinjabot@gmail.com> |
[Clang] Produce a warning instead of an error in unevaluated strings before C++26
Reviewed By: aaron.ballman, hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D156596
|
Revision tags: llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init |
|
#
95f50964 |
| 10-Jul-2021 |
Corentin Jabot <corentinjabot@gmail.com> |
Implement P2361 Unevaluated string literals
This patch proposes to handle in an uniform fashion the parsing of strings that are never evaluated, in asm statement, static assert, attrributes, extern,
Implement P2361 Unevaluated string literals
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
show more ...
|
#
66202d83 |
| 13-Apr-2023 |
Jorge Pinto Sousa <jorge.pinto.sousa@proton.me> |
Make 'static assertion failed' diagnostics point to the static assertion expression
"static assertion failed" pointed to the static_assert token and then underlined the static assertion expression:
Make 'static assertion failed' diagnostics point to the static assertion expression
"static assertion failed" pointed to the static_assert token and then underlined the static assertion expression:
<source>:3:1: error: static assertion failed static_assert(false); ^ ~~~~~ 1 error generated. See Godbolt: https://godbolt.org/z/r38booz59
Now it points to and highlights the assertion expression.
Fixes https://github.com/llvm/llvm-project/issues/61951 Differential Revision: https://reviews.llvm.org/D147745
show more ...
|
#
06c6fac6 |
| 07-Apr-2023 |
Krishna Narayanan <krishnanarayanan132002@gmail.com> |
Update static_assert message for redundant cases
There are some simple messages where an expansion isn't particularly helpful or needed. We aim to eliminate expansions that don't add much value for
Update static_assert message for redundant cases
There are some simple messages where an expansion isn't particularly helpful or needed. We aim to eliminate expansions that don't add much value for user (this will give us slightly more room or prioritise to have longer diagnostics elsewhere).
The test case for which it has been tested: ``` constexpr auto is_gitlab = false; constexpr auto is_weekend = false; static_assert(is_gitlab or is_weekend); ```
Previous warning/error message: ``` <source>:4:1: error: static assertion failed due to requirement 'is_gitlab || is_weekend' static_assert(is_gitlab or is_weekend); ^ ~~~~~~~~~~~~~~~~~~~~~~~ <source>:4:25: note: expression evaluates to 'false || false' static_assert(is_gitlab or is_weekend); ~~~~~~~~~~^~~~~~~~~~~~~ ``` Currrent warning/error message: ``` <source>:4:1: error: static assertion failed due to requirement 'is_gitlab' static_assert(is_gitlab or is_weekend); ^ ~~~~~~~~~ ``` This patch aims to remove some redundant cases of static assert messages where the expansions are particularly unhelpful. In this particular patch, we have ignored the printing of diagnostic warnings for binary operators with logical OR operations.
This is done to prioritise and prefer to emit longer diagnostic warnings for more important concerns elsewhere.
Differential Revision: https://reviews.llvm.org/D146376
show more ...
|
#
00e2098b |
| 17-Feb-2023 |
Corentin Jabot <corentinjabot@gmail.com> |
[Clang] Implement CWG2518 - static_assert(false)
This allows `static_assert(false)` to not be ill-formed in template definitions.
This change is applied as a DR in all C++ modes.
Of notes, a coupl
[Clang] Implement CWG2518 - static_assert(false)
This allows `static_assert(false)` to not be ill-formed in template definitions.
This change is applied as a DR in all C++ modes.
Of notes, a couple of tests were relying of the eager nature of static_assert
* test/SemaTemplate/instantiation-dependence.cpp * test/SemaTemplate/instantiate-var-template.cpp
I don't know if the changes to `static_assert` still allow that sort of tests to be expressed.
Reviewed By: #clang-language-wg, erichkeane, aaron.ballman
Differential Revision: https://reviews.llvm.org/D144285
show more ...
|
#
09117b21 |
| 01-Aug-2022 |
Timm Bäder <tbaeder@redhat.com> |
[clang][sema] Print more information about failed static assertions
For failed static assertions, try to take the expression apart and print useful information about why it failed. In particular, lo
[clang][sema] Print more information about failed static assertions
For failed static assertions, try to take the expression apart and print useful information about why it failed. In particular, look at binary operators and print the compile-time evaluated value of the LHS/RHS.
Differential Revision: https://reviews.llvm.org/D130894
show more ...
|
#
76476efd |
| 25-Jul-2022 |
Muhammad Usman Shahid <codesbyusman@gmail.com> |
Rewording "static_assert" diagnostics
This patch rewords the static assert diagnostic output. Failing a _Static_assert in C should not report that static_assert failed. This changes the wording to b
Rewording "static_assert" diagnostics
This patch rewords the static assert diagnostic output. Failing a _Static_assert in C should not report that static_assert failed. This changes the wording to be more like GCC and uses "static assertion" when possible instead of hard coding the name. This also changes some instances of 'static_assert' to instead be based on the token in the source code.
Differential Revision: https://reviews.llvm.org/D129048
show more ...
|
#
1da31190 |
| 21-Jul-2022 |
Erich Keane <erich.keane@intel.com> |
Revert "Rewording the "static_assert" to static assertion"
Looks like we again are going to have problems with libcxx tests that are overly specific in their dependency on clang's diagnostics.
This
Revert "Rewording the "static_assert" to static assertion"
Looks like we again are going to have problems with libcxx tests that are overly specific in their dependency on clang's diagnostics.
This reverts commit 6542cb55a3eb115b1c3592514590a19987ffc498.
show more ...
|
#
6542cb55 |
| 21-Jul-2022 |
Muhammad Usman Shahid <codesbyusman@gmail.com> |
Rewording the "static_assert" to static assertion
This patch is basically the rewording of the static assert statement's output(error) on screen after failing. Failing a _Static_assert in C should n
Rewording the "static_assert" to static assertion
This patch is basically the rewording of the static assert statement's output(error) on screen after failing. Failing a _Static_assert in C should not report that static_assert failed. It’d probably be better to reword the diagnostic to be more like GCC and say “static assertion” failed in both C and C++.
consider a c file having code
_Static_assert(0, "oh no!");
In clang the output is like:
<source>:1:1: error: static_assert failed: oh no! _Static_assert(0, "oh no!"); ^ ~ 1 error generated. Compiler returned: 1
Thus here the "static_assert" is not much good, it will be better to reword it to the "static assertion failed" to more generic. as the gcc prints as:
<source>:1:1: error: static assertion failed: "oh no!" 1 | _Static_assert(0, "oh no!"); | ^~~~~~~~~~~~~~ Compiler returned: 1
The above can also be seen here. This patch is about rewording the static_assert to static assertion.
Differential Revision: https://reviews.llvm.org/D129048
show more ...
|
#
041d4012 |
| 14-Jul-2022 |
Mitch Phillips <31459023+hctim@users.noreply.github.com> |
Revert "Rewording "static_assert" diagnostics"
This reverts commit b7e77ff25fb2412f6ab6d6cc756666b0e2f97bd3.
Reason: Broke sanitizer builds bots + libcxx. 'static assertion expression is not an int
Revert "Rewording "static_assert" diagnostics"
This reverts commit b7e77ff25fb2412f6ab6d6cc756666b0e2f97bd3.
Reason: Broke sanitizer builds bots + libcxx. 'static assertion expression is not an integral constant expression'. More details available in the Phabricator review: https://reviews.llvm.org/D129048
show more ...
|
#
b7e77ff2 |
| 14-Jul-2022 |
Muhammad Usman Shahid <codesbyusman@gmail.com> |
Rewording "static_assert" diagnostics
This patch rewords the static assert diagnostic output. Failing a _Static_assert in C should not report that static_assert failed. This changes the wording to b
Rewording "static_assert" diagnostics
This patch rewords the static assert diagnostic output. Failing a _Static_assert in C should not report that static_assert failed. This changes the wording to be more like GCC and uses "static assertion" when possible instead of hard coding the name. This also changes some instances of 'static_assert' to instead be based on the token in the source code.
Differential Revision: https://reviews.llvm.org/D129048
show more ...
|
#
d4892a16 |
| 17-Jun-2022 |
Corentin Jabot <corentinjabot@gmail.com> |
[Clang] Add a warning on invalid UTF-8 in comments.
Introduce an off-by default `-Winvalid-utf8` warning that detects invalid UTF-8 code units sequences in comments.
Invalid UTF-8 in other places i
[Clang] Add a warning on invalid UTF-8 in comments.
Introduce an off-by default `-Winvalid-utf8` warning that detects invalid UTF-8 code units sequences in comments.
Invalid UTF-8 in other places is already diagnosed, as that cannot appear in identifiers and other grammar constructs.
The warning is off by default as its likely to be somewhat disruptive otherwise.
This warning allows clang to conform to the yet-to be approved WG21 "P2295R5 Support for UTF-8 as a portable source file encoding" paper.
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D128059
show more ...
|
#
a262f4db |
| 12-Jul-2022 |
Jonas Devlieghere <jonas@devlieghere.com> |
Revert "[Clang] Add a warning on invalid UTF-8 in comments."
This reverts commit cc309721d20c8e544ae7a10a66735ccf4981a11c because it breaks the following tests on GreenDragon:
TestDataFormatterOb
Revert "[Clang] Add a warning on invalid UTF-8 in comments."
This reverts commit cc309721d20c8e544ae7a10a66735ccf4981a11c because it breaks the following tests on GreenDragon:
TestDataFormatterObjCCF.py TestDataFormatterObjCExpr.py TestDataFormatterObjCKVO.py TestDataFormatterObjCNSBundle.py TestDataFormatterObjCNSData.py TestDataFormatterObjCNSError.py TestDataFormatterObjCNSNumber.py TestDataFormatterObjCNSURL.py TestDataFormatterObjCPlain.py TestDataFormatterObjNSException.py
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/45288/
show more ...
|
#
cc309721 |
| 17-Jun-2022 |
Corentin Jabot <corentinjabot@gmail.com> |
[Clang] Add a warning on invalid UTF-8 in comments.
Introduce an off-by default `-Winvalid-utf8` warning that detects invalid UTF-8 code units sequences in comments.
Invalid UTF-8 in other places i
[Clang] Add a warning on invalid UTF-8 in comments.
Introduce an off-by default `-Winvalid-utf8` warning that detects invalid UTF-8 code units sequences in comments.
Invalid UTF-8 in other places is already diagnosed, as that cannot appear in identifiers and other grammar constructs.
The warning is off by default as its likely to be somewhat disruptive otherwise.
This warning allows clang to conform to the yet-to be approved WG21 "P2295R5 Support for UTF-8 as a portable source file encoding" paper.
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D128059
show more ...
|
#
50416e54 |
| 09-Jul-2022 |
Corentin Jabot <corentinjabot@gmail.com> |
Revert "[Clang] Add a warning on invalid UTF-8 in comments."
It is probable thart this change crashes on the powerpc bots.
This reverts commit 355532a1499aa9b13a89fb5b5caaba2344d57cd7.
|
#
355532a1 |
| 17-Jun-2022 |
Corentin Jabot <corentinjabot@gmail.com> |
[Clang] Add a warning on invalid UTF-8 in comments.
Introduce an off-by default `-Winvalid-utf8` warning that detects invalid UTF-8 code units sequences in comments.
Invalid UTF-8 in other places i
[Clang] Add a warning on invalid UTF-8 in comments.
Introduce an off-by default `-Winvalid-utf8` warning that detects invalid UTF-8 code units sequences in comments.
Invalid UTF-8 in other places is already diagnosed, as that cannot appear in identifiers and other grammar constructs.
The warning is off by default as its likely to be somewhat disruptive otherwise.
This warning allows clang to conform to the yet-to be approved WG21 "P2295R5 Support for UTF-8 as a portable source file encoding" paper.
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D128059
show more ...
|
#
e9fe20da |
| 06-Jul-2022 |
Nico Weber <thakis@chromium.org> |
Revert "[Clang] Add a warning on invalid UTF-8 in comments."
This reverts commit 4174f0ca618b467571b43cff12cbe4c4239670f8.
Also revert follow-up "[Clang] Fix invalid utf-8 detection" This reverts c
Revert "[Clang] Add a warning on invalid UTF-8 in comments."
This reverts commit 4174f0ca618b467571b43cff12cbe4c4239670f8.
Also revert follow-up "[Clang] Fix invalid utf-8 detection" This reverts commit bf45e27a676d87944f1f13d5f0d0f39935fc4010.
The second commit broke tests, see comments on https://reviews.llvm.org/D129223, and it sounds like the first commit isn't valid without the second one. So reverting both for now.
show more ...
|
#
4174f0ca |
| 17-Jun-2022 |
Corentin Jabot <corentinjabot@gmail.com> |
[Clang] Add a warning on invalid UTF-8 in comments.
Introduce an off-by default `-Winvalid-utf8` warning that detects invalid UTF-8 code units sequences in comments.
Invalid UTF-8 in other places i
[Clang] Add a warning on invalid UTF-8 in comments.
Introduce an off-by default `-Winvalid-utf8` warning that detects invalid UTF-8 code units sequences in comments.
Invalid UTF-8 in other places is already diagnosed, as that cannot appear in identifiers and other grammar constructs.
The warning is off by default as its likely to be somewhat disruptive otherwise.
This warning allows clang to conform to the yet-to be approved WG21 "P2295R5 Support for UTF-8 as a portable source file encoding" paper.
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D128059
show more ...
|
#
da1609ad |
| 29-Jun-2022 |
Corentin Jabot <corentinjabot@gmail.com> |
Improve the formatting of static_assert messages
Display 'static_assert failed: message' instead of 'static_assert failed "message"' to be consistent with other implementations and be slightly more
Improve the formatting of static_assert messages
Display 'static_assert failed: message' instead of 'static_assert failed "message"' to be consistent with other implementations and be slightly more readable.
Reviewed By: #libc, aaron.ballman, philnik, Mordante
Differential Revision: https://reviews.llvm.org/D128844
show more ...
|
#
64ab2b1d |
| 20-Aug-2021 |
Corentin Jabot <corentinjabot@gmail.com> |
Improve handling of static assert messages.
Instead of dumping the string literal (which quotes it and escape every non-ascii symbol), we can use the content of the string when it is a 8 byte string
Improve handling of static assert messages.
Instead of dumping the string literal (which quotes it and escape every non-ascii symbol), we can use the content of the string when it is a 8 byte string.
Wide, UTF-8/UTF-16/32 strings are still completely escaped, until we clarify how these entities should behave (cf https://wg21.link/p2361).
`FormatDiagnostic` is modified to escape non printable characters and invalid UTF-8.
This ensures that unicode characters, spaces and new lines are properly rendered in static messages. This make clang more consistent with other implementation and fixes this tweet https://twitter.com/jfbastien/status/1298307325443231744 :)
Of note, `PaddingChecker` did print out new lines that were later removed by the diagnostic printing code. To be consistent with its tests, the new lines are removed from the diagnostic.
Unicode tables updated to both use the Unicode definitions and the Unicode 14.0 data.
U+00AD SOFT HYPHEN is still considered a print character to match existing practices in terminals, in addition of being considered a formatting character as per Unicode.
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D108469
show more ...
|