| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
statements"
I was unable to definitively locate a document number for this, but it
is potentially WG14 N759 based on the description in the C99 rationale
document.
We do implement the C89 and C99 scope rules for iteration and selection
statements, so claiming conformance here.
|
|
This feature is listed in the C99 front matter as one of the changes to
C99, but there was no associated document with that title (or anything
close to it).
I eventually tracked this down to a new requirement in C99 that
implementations defining their own pedefined macros should not name
them with a __STDC_ prefix. Clang does not do this, but there's no
tests that would demonstrate we properly "implement" this feature. So
claiming full conformance without additional test coverage.
|
|
Both of these relate to handling of standard pragmas. N631 is about
various STDC pragmas being included in the standard at all, and N696
is about whether macros are expanded in standard pragmas (they're not).
|
|
No tests are added because existing tests cover this. The thrust of the
paper is that an implementation needs to support including a header
file whose name is eight character or less and contains only letters
and numbers; we definitely manage this.
|
|
|
|
The checker finds a type of undefined behavior, where if the type of a
pointer to an object-array is different from the objects' underlying
type, calling `delete[]` is undefined, as the size of the two objects
might be different.
The checker has been in alpha for a while now, it is a simple checker
that causes no crashes, and considering the severity of the issue, it
has a low result-count on open-source projects (in my last test-run on
my usual projects, it had 0 results).
This commit cleans up the documentation and adds docs for the limitation
related to tracking through references, in addition to moving it to
`cplusplus`.
---------
Co-authored-by: Balazs Benics <benicsbalazs@gmail.com>
Co-authored-by: whisperity <whisperity@gmail.com>
|
|
|
|
This paper is about constant expression handling in the presence of
FLT_EVAL_METHOD, which we handle via insertion of implicit cast nodes
in the AST.
|
|
|
|
Our existing diagnostics for catching unsequenced modifications handles
test coverage for N1282, which is correcting the standard based on the
resolution of DR087.
|
|
This is about the best I could do for testing that `signed char` does
not have any padding bits.
|
|
Setting GCC_INSTALL_PREFIX leads to a warning (#77537).
Link:
https://discourse.llvm.org/t/add-gcc-install-dir-deprecate-gcc-toolchain-and-remove-gcc-install-prefix/65091
Link:
https://discourse.llvm.org/t/correct-cmake-parameters-for-building-clang-and-lld-for-riscv/72833
|
|
This reverts commit 003e292f9895a9cf4e30688269efa668d1fcbb09 because
there were dependent changes in the codebase that now fail.
|
|
Revert "[Clang][C++23] Implement P2448R2: Relaxing some constexpr
restrictions (#77753)"
This reverts commit 99500e8c08a4d941acb8a7eb00523296fb2acf7a because it
causes a behavior change for std=c++20. See
https://github.com/llvm/llvm-project/pull/77753.
|
|
|
|
This implements the C++23 `[[assume]]` attribute.
Assumption information is lowered to a call to `@llvm.assume`, unless the expression has side-effects, in which case it is discarded and a warning is issued to tell the user that the assumption doesn’t do anything. A failed assumption at compile time is an error (unless we are in `MSVCCompat` mode, in which case we don’t check assumptions at compile time).
Due to performance regressions in LLVM, assumptions can be disabled with the `-fno-assumptions` flag. With it, assumptions will still be parsed and checked, but no calls to `@llvm.assume` will be emitted and assumptions will not be checked at compile time.
|
|
Fixes #54051
This patch implements the C++20 feature -- CTAD for alias templates (P1814R0, specified in https://eel.is/c++draft/over.match.class.deduct#3). It is an initial patch:
- it cover major pieces, thus it works for most cases;
- the big missing piece is to implement the associated constraints (over.match.class.deduct#3.3) for the synthesized deduction guides, see the FIXME in code and tests;
- Some enhancements on the TreeTransform&TemplateInstantiator to allow performing instantiation on `BuildingDeductionGuides` mode;
|
|
This patch implements
[CWG2586](https://cplusplus.github.io/CWG/issues/2583.html) "Common
initial sequence should consider over-alignment". Note that alignment of
union members doesn't have to match, as layout compatibility of unions
is not defined in terms of common initial sequence
(http://eel.is/c++draft/class.mem.general#25).
|
|
This patch covers
[CWG519](https://cplusplus.github.io/CWG/issues/519.html) "Null pointer
preservation in `void*` conversions",
[CWG571](https://cplusplus.github.io/CWG/issues/571.html) "References
declared const".
|
|
|
|
Per
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2448r2.html
function/constructor/destructor can be marked `constexpr` even though it
never produces a constant expression.
Non-literal types as return types and parameter types of functions
marked `constexpr` are also allowed.
Since this is not a DR, the diagnostic messages are still preserved for
C++ standards older than C++23.
|
|
There was a bug in Clang where it couldn't choose which overload
candidate was more specialized if it was comparing a member-function to
a non-member function. Previously, this was detected as an ambiguity,
now Clang chooses correctly.
This patch fixes the bug by fully implementing CWG2445 and moving the
template transformation described in `[temp.func.order]` paragraph 3
from `isAtLeastAsSpecializedAs()` to
`Sema::getMoreSpecializedTemplate()` so we have the transformed
parameter list during the whole comparison. Also, to be able to add the
correct type for the implicit object parameter
`Sema::getMoreSpecializedTemplate()` has new parameters for the object
type.
Fixes #74494, fixes #82509
|
|
|
|
|
|
The implementation mostly reuses C++ code paths where possible,
including narrowing check in order to provide diagnostic messages in
case initializer for constexpr variable is not exactly representable in
target type.
The following won't work due to lack of support for other features:
- Diagnosing of underspecified declarations involving constexpr
- Constexpr attached to compound literals
Also due to lack of support for char8_t some of examples with utf-8
strings don't work properly.
Fixes https://github.com/llvm/llvm-project/issues/64742
|
|
This patch covers the following defect reports:
[CWG438](https://cplusplus.github.io/CWG/issues/438.html) "Possible flaw
in wording for multiple accesses to object between sequence points",
[CWG439](https://cplusplus.github.io/CWG/issues/439.html) "Guarantees on
casting pointer back to cv-qualified version of original type",
[CWG441](https://cplusplus.github.io/CWG/issues/441.html) "Ordering of
static reference initialization",
[CWG462](https://cplusplus.github.io/CWG/issues/462.html) "Lifetime of
temporaries bound to comma expressions",
[CWG492](https://cplusplus.github.io/CWG/issues/492.html) "`typeid`
constness inconsistent with example".
[CWG475](https://cplusplus.github.io/CWG/issues/475.html) "When is
`std::uncaught_exception()` true? (take 2)" requires a libc++abi test.
As for [CWG454](https://cplusplus.github.io/CWG/issues/454.html) "When
is a definition of a static data member required?", I don't feel
confident in my understanding of it, so skipping over it.
|
|
sequence" (#82607)
This patch implements said defect report resolution by adding additional
check to common initial sequence evaluation. Consequently, this fixes
CWG2759.
|
|
revisited" (#82358)
This patch updates our internal notion of `layout-compatible` to ignore cv-qualification,
which in turn fixes `__is_layout_compatible` intrinsic.
|
|
(#78836)
This patch places additional requirement on tests for open issues to
specify what do they test, and reduce their advertising on
`cxx_dr_status.html`.
Tests for open issues have to either provide date of the proposed
resolution they test, or a paper number that attempts to resolve the
issue. Examples from this patch: `// dr1223: 17 drafting 2023-05-12`,
`// dr2049: 18 drafting P2308R1`, `// dr2335: no drafting 2018-06`.
Tests for open issues are no longer advertised in `cxx_dr_status.html`
as tests for resolved issues. Instead, they are specified as `Not
Resolved*` (note the asterisk). Such statuses have a tooltip with the
following kind of text:
`Clang 17 implements 2023-05-12 resolution`
`Clang does not implement 2018-06-04 resolution`
`Clang 18 implements P2308R1 resolution`
I admit that the wording is a bit crude, but I tried to minimize amount
of boilerplate in the `make_cxx_dr_status`. Hopefully, this whole setup
matches [C++ compiler
support](https://en.cppreference.com/w/cpp/compiler_support) page on
cppreference enough for people to catch up.
This patch also implement a quality-of-life feature for users of
`make_cxx_dr_status`: now script is able to report multiple bad `// dr`
comments in a single run.
This has also been discussed in a PR for CWG472 test:
https://github.com/llvm/llvm-project/pull/67948
|
|
This patch covers CWG issues
[201](https://cplusplus.github.io/CWG/issues/201.html),
[210](https://cplusplus.github.io/CWG/issues/210.html),
[292](https://cplusplus.github.io/CWG/issues/292.html).
[CWG208](https://cplusplus.github.io/CWG/issues/208.html) is not
covered, as it actually requires a libcxxabi test.
Resolution of CWG292 has been superseded by
[P0145R3](https://wg21.link/p0145r3) "Refining Expression Evaluation
Order for Idiomatic C++"
(see changes to paragraph 5.3.4/18).
|
|
Covers CWG issues
[124](https://cplusplus.github.io/CWG/issues/124.html)
[185](https://cplusplus.github.io/CWG/issues/185.html),
[193](https://cplusplus.github.io/CWG/issues/193.html),
[199](https://cplusplus.github.io/CWG/issues/199.html).
I also looked at [190](https://cplusplus.github.io/CWG/issues/190.html),
but concluded that we should try to test it via C++20
`std::is_layout_compatible` first.
I tried to group tests under `dr1xx-codegen.cpp`, but found out that
CodeGen can arbitrarily reorder function definitions in LLVM module. In
particular, interleaving between regular function definitions and
destructor definitions present in the source might not be preserved,
which messes up FileCheck directives. `CHECK-DAG` can help with that,
but its interaction with `CHECK-LABEL` (lack of thereof) would require
me to relax tests too much.
|
|
documentation (NFC). (#81138)
This checker does not exist (any more?) but appeared in the
documentation. No other references to CallAndMessageUnInitRefArg are
found in the full clang code.
|
|
Covers CWG issues
[1150](https://cplusplus.github.io/CWG/issues/1150.html),
[1487](https://cplusplus.github.io/CWG/issues/1487.html),
[1567](https://cplusplus.github.io/CWG/issues/1567.html),
[1738](https://cplusplus.github.io/CWG/issues/1738.html),
[2273](https://cplusplus.github.io/CWG/issues/2273.html),
[2277](https://cplusplus.github.io/CWG/issues/2277.html),
[2356](https://cplusplus.github.io/CWG/issues/2356.html),
[2504](https://cplusplus.github.io/CWG/issues/2504.html).
On top of the wording in proposed resolutions,
[P0136R1](https://wg21.link/p0136r1) "Rewording inheriting constructors
(core issue 1941 et al)" is a very relevant paper.
Note that status for 1738 `sup P0136R1` is not officially recognized by
CWG, but saying `yes` or `no` seems even more confusing to me. Official
resolution is to reject certain code, but Clang is the only
implementation that still rejects it to this day:
https://godbolt.org/z/b1W8jc1o5. GCC rejected it until 9, now it's
accepted: https://godbolt.org/z/of6oh4sdT
|
|
Implement P2718R0 "Lifetime extension in range-based for loops"
(https://wg21.link/P2718R0)
Differential Revision: https://reviews.llvm.org/D153701
---------
Signed-off-by: yronglin <yronglin777@gmail.com>
|
|
Implements https://isocpp.org/files/papers/P2662R3.pdf
The feature is exposed as an extension in older language modes.
Mangling is not yet supported and that is something we will have to do before release.
|
|
https://cplusplus.github.io/CWG/issues/472.html
It has drafting status, but I think CWG has reached consesus on the
behavior.
Related: #16602
|
|
same type) (#77768)"
This reverts commit 924701311aa79180e86ad8ce43d253f27d25ec7d. Causes compilation
errors on valid code, see
https://github.com/llvm/llvm-project/pull/77768#issuecomment-1908062472.
|
|
scalar type. (#78041)
Previously committed as 9e08e51a20d0d2b1c5724bb17e969d036fced4cd, and
reverted because a dependency commit was reverted, then committed again
as 4b574008aef5a7235c1f894ab065fe300d26e786 and reverted again because
"dependency commit" 5a391d38ac6c561ba908334d427f26124ed9132e was
reverted. But it doesn't seem that 5a391d38ac6c was a real dependency
for this.
This commit incorporates 4b574008aef5a7235c1f894ab065fe300d26e786 and
18e093faf726d15f210ab4917142beec51848258 by Richard Smith (@zygoloid),
with some minor fixes, most notably:
- `UncommonValue` renamed to `StructuralValue`
- `VK_PRValue` instead of `VK_RValue` as default kind in lvalue and
member pointer handling branch in
`BuildExpressionFromNonTypeTemplateArgumentValue`;
- handling of `StructuralValue` in `IsTypeDeclaredInsideVisitor`;
- filling in `SugaredConverted` along with `CanonicalConverted`
parameter in `Sema::CheckTemplateArgument`;
- minor cleanup in
`TemplateInstantiator::transformNonTypeTemplateParmRef`;
- `TemplateArgument` constructors refactored;
- `ODRHash` calculation for `UncommonValue`;
- USR generation for `UncommonValue`;
- more correct MS compatibility mangling algorithm (tested on MSVC ver.
19.35; toolset ver. 143);
- IR emitting fixed on using a subobject as a template argument when the
corresponding template parameter is used in an lvalue context;
- `noundef` attribute and opaque pointers in `template-arguments` test;
- analysis for C++17 mode is turned off for templates in
`warn-bool-conversion` test; in C++17 and C++20 mode, array reference
used as a template argument of pointer type produces template argument
of UncommonValue type, and
`BuildExpressionFromNonTypeTemplateArgumentValue` makes
`OpaqueValueExpr` for it, and `DiagnoseAlwaysNonNullPointer` cannot see
through it; despite of "These cases should not warn" comment, I'm not
sure about correct behavior; I'd expect a suggestion to replace `if` by
`if constexpr`;
- `temp.arg.nontype/p1.cpp` and `dr18xx.cpp` tests fixed.
|
|
This follows the same implementation logic as with C++ and is
compatible with the GCC behavior in C.
Trigraphs are enabled by default in -std=c* conformance modes before
C23, but are disabled in GNU and Microsoft modes as well as in C23 or
later.
|
|
C++14 introduced deduced return type for regular functions, but shortly after [CWG1878](https://wg21.link/cwg1878) was filed and resolved to disallow deduced return types in conversion function templates. So this patch diagnoses such usage of deduced return type in C++14 mode onwards.
Fixes #51776
|
|
type) (#77768)
Closes #77638, #24186
Rebased from <https://reviews.llvm.org/D156032>, see there for more
information.
Implements wording change in [CWG2137](https://wg21.link/CWG2137) in the
first commit.
This also implements an approach to [CWG2311](https://wg21.link/CWG2311)
in the second commit, because too much code that relies on `T{ T_prvalue}`
being an elision would break. Because that issue is still open and
the CWG issue doesn't provide wording to fix the issue, there may be
different behaviours on other compilers.
|
|
The test checks that objects in arrays are destructed in reverse order during stack unwinding.
This patch is trying to establish a precedent how codegen tests for C++ defect report test suite should be written. Refer to PR for exact reasoning.
|
|
A union is considered a literal type unless it has no non-literal
member.
This resolves CWG2096 (which makes unions with literal members literal)
and CWG2598 (empty unions are literal types).
Fixes #77924
|
|
[P1787](https://wg21.link/p1787): The intent for CWG2335 (contra those of the older CWG1890, CWG1626, CWG1255, and CWG287) is supported by retaining the unrestricted forward lookup in complete-class contexts (despite current implementation behavior for non-templates).
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. [Drafting note: The plan for CWG2335 is to describe forbidden dependency cycles among the complete-class contexts of a class. — end drafting note] ([class.member.lookup]/4)
Complete-class context is described in [class.mem.general] [p7](http://eel.is/c++draft/class#mem.general-7) and
[p8](http://eel.is/c++draft/class#mem.general-8). In this patch I add tests only for CWG issues that fall under current definition of complete-class context, because I'm not sure how CWG1255 and CWG287 are going to work. That's why I skip over them, but mark CWG1308 as superseded by CWG1330.
|
|
Test is based on [P0136R1](https://wg21.link/p0136r1) wording instead of proposed resolution in the issue itself.
This patch also expands related CWG1573 test with an additional test case. Existing `3.9` status of 1573 is still relevant even with this new test case.
|
|
|
|
Use a consistent, more pastel color for unknown status
in papers and issues tracking pages
|
|
Covers C++ core issues 1800, 1801, 1802, 1803, 1804.
|
|
This patch updates `cxx_dr_status.html` to bring it in sync with Core Issues List Revision 113.
|
|
analysis warnings.
The new attribute can be placed on statements in order to suppress
arbitrary warnings produced by static analysis tools at those statements.
Previously such suppressions were implemented as either informal comments
(eg. clang-tidy `// NOLINT:`) or with preprocessor macros (eg.
clang static analyzer's `#ifdef __clang_analyzer__`). The attribute
provides a universal, formal, flexible and neat-looking suppression mechanism.
Implement support for the new attribute in the clang static analyzer;
clang-tidy coming soon.
The attribute allows specifying which specific warnings to suppress,
in the form of free-form strings that are intended to be specific to
the tools, but currently none are actually supported; so this is also
going to be a future improvement.
Differential Revision: https://reviews.llvm.org/D93110
|
