https://cplusplus.github.io/CWG/issues/2496.html
We failed to diagnose the following in C++23 mode
```
struct S {
virtual void f(); // expected-note {{previous declaration is here}}
};
struct T : S {
virtual void f() &;
};
```
Remove `[expr.prim.req.nested]` check which restrict that local
parameters in constraint-expressions can only appear as unevaluated
operands. This change makes the treatment of examples like `requires`
expressions and other constant expression contexts uniform, consistent
with the adoption of P2280.
References: https://cplusplus.github.io/CWG/issues/2517.html
Fixes #132825
---------
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
The previous approach broke code generation for the MS ABI due to an
unintended code path during constraint substitution. This time we
address the issue by inspecting the evaluation contexts and thereby
avoiding that code path.
This reapplies 96eced624 (#102857).
It's the end of an era. The IRC channel was previously where the
community gathered to discuss technical topics but is now a ghost town
where the primary activity is moderators (me) kickbanning the same
individual dozens of times a day for CoC violations and the secondary
activity is telling the occasional person to come to Discord for help.
The number of people engaging on IRC for the community's intended
purposes seems to be roughly one person a month.
So this removes all remaining mentions of IRC from our documentation so
that it no longer appears to be an "official" channel for communicating
with the community. It also removes IRC handles from the various
maintainers lists, since those would stand out as confusing
anachronisms.
The IRC channel topic already recommends people come to the Discord
server. There is no way to "shut down" an IRC channel such that it no
longer exists, so the channel will continue to exist on OFTC, but will
be unmoderated.
(This was previously discussed in https://discourse.llvm.org/c/llvm/5
but some mentions persisted.)
This adds
- The parsing of `trivially_relocatable_if_eligible`,
`replaceable_if_eligible` keywords
- `__builtin_trivially_relocate`, implemented in terms of memmove. In
the future this should
- Add the appropriate start/end lifetime markers that llvm does not have
(`start_lifetime_as`)
- Add support for ptrauth when that's upstreamed
- the `__builtin_is_cpp_trivially_relocatable` and
`__builtin_is_replaceable` traits
Fixes#127609
We already attempted to implement this (it was the intent of the paper),
in that parameters were never considered name-independent. However, we
failed to check that any previously found parameter declaration was also
name-independent.
Note that, as worded, the current resolution is insufficient (I wrote to
CWG with better wording), but there is some consensus on the design
outcome.
Fixes#136373
This changes the type compatibility rules so that it is permitted to
redefine tag types within the same TU so long as they are equivalent
definitions.
It is intentionally not being exposed as an extension in older C
language modes. GCC does not do so and the feature doesn't seem
compelling enough to warrant it.
This feature largely models the same behavior as in C++11. It is
technically a breaking change between C99 and C11, so the paper is not
being backported to older language modes.
One difference between C++ and C is that things which are rvalues in C
are often lvalues in C++ (such as the result of a ternary operator or a
comma operator).
Fixes#96486
C2y adds the `_Countof` operator which returns the number of elements in
an array. As with `sizeof`, `_Countof` either accepts a parenthesized
type name or an expression. Its operand must be (of) an array type. When
passed a constant-size array operand, the operator is a constant
expression which is valid for use as an integer constant expression.
This is being exposed as an extension in earlier C language modes, but
not in C++. C++ already has `std::extent` and `std::size` to cover these
needs, so the operator doesn't seem to get the user enough benefit to
warrant carrying this as an extension.
Fixes#102836
This adds some initial documentation about freestanding requirements for
Clang. The most critical part of the documentation is spelling out that
a conforming freestanding C Standard Library is required; Clang will not
be providing the headers for <string.h> in C23 which expose a number of
symbols in freestanding mode.
The docs also make it clear that in addition to a conforming
freestanding C standard library, the library must provide some
additional symbols which LLVM requires.
These docs are not comprehensive, this is just getting the bare bones in
place so that they can be expanded later.
This also updates the C status page to make it clear that we don't have
anything to do for WG14 N2524 which adds string interfaces to
freestanding mode.
WG14 N2819 clarified that a compound literal within a function prototype
has a lifetime similar to that of a local variable within the function,
not a file scope variable.
Aaron reported that `make_cxx_dr_status` replaces all newlines in
`cxx_dr_status.html`, which makes for a huge diff. On Windows, we can't
be compatible with all `autocrlf` modes at once, so this patch adds
autodetection of newline style using the existing file, if one is
present (which should be the case for all reasonable use cases).
CWG472 is one of the CWG issues that were assigned to Mike Miller with
`drafting` status, but recently got back to `open`, because Mike is no
longer active in CWG. Nothing to be done here, except for changing the
status.
CWG1432 was recently reopened after a CWG reflector discussion. I
changed the status to claim that we test for the previous resolution.
WG14 N3353 added support for 0o and 0O as octal literal prefixes. It
also deprecates use of octal literals without a prefix, except for the
literal 0.
This feature is being exposed as an extension in older C language modes
as well as in all C++ language modes.
This paper makes it a constraint violation (instead of UB) to call
va_start from a function with a fixed (non-variadic) parameter list.
This is something Clang has always diagnosed as an error.
This paper clarifies two things:
* a call to va_start must be within the body of a variadic function,
* the va_list arguments must be lvalues
Clang has correctly diagnosed the first point since Clang 5.0. Clang
generally diagnoses the second point, except for va_copy. However, the
second point is not a constraint violation, so a diagnostic is not
strictly required. That said, it would be good for us to properly
diagnose va_copy.
We have a list of criteria for proposing an extension in Clang, but we
do not have any documentation about how to propose an extension. This
adds some basic documentation about how we run RFCs in Clang, as well as
adds a list of Clang Area Team members in support of the process.
It could be argued that this should be documented for the entire LLVM
Project, however, other parts of the project have different rules for
proposing extensions. (Extending libc++ is a different proposition than
extending LLVM, than extending MLIR, than extending Clang, etc.) We may
want to introduce high-level documentation for the LLVM Project, but
that is a bigger project and we already have the documentation in Clang
about criteria for extensions. So it seems reasonable to add some
lightweight documentation specific to Clang until we determine what to
do at the whole project level.
This paper clarified that conditional inclusion in the preprocessor
requires the integer constant expression to be comprised only of
integer and character literals, punctuators, or implementation-defined
tokens.
This is something Clang has always required.
Only changes 1 and 2 were adopted in Graz and those are both editorial
changes which don't impact the behavior of compilers, so there's no
need to track this paper.
This implements the R2 semantics of P0963.
The R1 semantics, as outlined in the paper, were introduced in Clang 6.
In addition to that, the paper proposes swapping the evaluation order of
condition expressions and the initialization of binding declarations
(i.e. std::tuple-like decompositions).
The docs say that Visual Studio 2019 16.7 or later is required to build
clang but reference VS 2017.
* Remove references to VS 2017
* Update instructions to use VS 2022, since that's the current version
available for download from MS' website
* The path to VS 2022 executables is `Program Files` instead of `Program
Files (x86)`, as VS 2022 is 64-bit
This paper made it a constraint violation for the same identifier
within a TU to have both internal and external linkage. It was
previously UB.
Clang does not correctly diagnose the constraint in some cases,
documented in the added test case.
This was a clarification for C23's N2412, primarily about the
BOOL_WIDTH macro. It should expand to the number of bits in the value
representation, not the object representation. Clang 20 implements the
correct value.
This paper made it a constraint violation to have an incomplete type
during lvalue conversion. Previously, this was undefined behavior.
Clang has always diagnosed this for non-void incomplete types. However,
Clang does allow derefencing a void pointer (with a diagnostic, so we
still meet the conformance requirements), but not for a value
computation.
This paper makes it a constraint violation to form a UCN via token
concatenation. Clang does not conform to it and the paper goes in the
opposite direction of where C++ went with P2621R3 which was adopted for
C++26.
This paper (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3411.pdf)
allows a source file to end without a newline. Clang has supported this
as a conforming extension for a long time, so this suppresses the
diagnotic in C2y mode but continues to diagnose as an extension in
earlier language modes. It also continues to diagnose if the user passes
-Wnewline-eof explicitly.
This paper made it a constraint violation for a TU to end with an
unterminated multiline comment. This is something Clang has always
diagnosed as an error.
The resolution of [CWG2285](https://wg21.link/cwg2285) adds the point of
declaration of a structured binding, and was implemented in
bdb84f374c
.
Drive-by changes: modify comment and diagnostic messages mentioned in
CWG2285.
This paper made it a constraint violation to have a tentative
definition with internal linkage which is not completed by the end of
the translation unit.
This has been diagnosed as an error since at least Clang 3.0, so no
changes are needed.
