Now that #149310 has restricted lifetime intrinsics to only work on
allocas, we can also drop the explicit size argument. Instead, the size
is implied by the alloca.
This removes the ability to only mark a prefix of an alloca alive/dead.
We never used that capability, so we should remove the need to handle
that possibility everywhere (though many key places, including stack
coloring, did not actually respect this).
An enumeration is compatible with its underlying type, which means that
code like the following should be accepted:
struct A { int h; };
void func() {
extern struct A x;
enum E : int { e };
struct A { enum E h; };
extern struct A x;
}
because the structures are declared in different scopes, the two
declarations of 'x' are both compatible.
Note, the structural equivalence checker does not take scope into
account, but that is something the C standard requires. This means we
are accepting code we should be rejecting per the standard, like:
void func() {
struct A { int h; };
extern struct A x;
enum E : int { e };
struct A { enum E h; };
extern struct A x;
}
Because the structures are declared in the same scope, the type
compatibility rule require the structures to use the same types, not
merely compatible ones.
Fixes#149965
Fixes#149669; the old check compared with the end of the literal, but
we can just check that after parsing digits, we're pointing to one
character past the token start.
The underlying type of an enumeration is the non-atomic, unqualified
version of the specified type. Clang was rejecting such enumerations,
with a hard error, but now has the ability to downgrade the error into a
warning. Additionally, we diagnose (as a warning) dropping other
qualifiers. _Atomic is special given that an atomic type need not have
the same size as its non-atomic counterpart, and that the C++ version
of <stdatomic.h> defines _Atomic to std::atomic for easing cross-
language atomic use and std::atomic is an invalid enum base in C++.
(Note: we expose _Atomic in C++ even without including
<stdatomic,h>.)
Fixes#147736
Fixs: https://github.com/llvm/llvm-project/issues/145250.
This PR makes clang accept single variadic parameter function declarator
in type name.
Eg.
```c
int va_fn(...); // ok
// As typeof() argument
typeof(int(...))*fn_ptr = &va_fn; // ok
// As _Generic association type
int i = _Generic(typeof(va_fn), int(...):1); // ok
```
Signed-off-by: yronglin <yronglin777@gmail.com>
Fixes https://github.com/llvm/llvm-project/issues/141230.
Currently, prefixed octal literals used with floating-point suffixes are
not
rejected, causing Clang to crash.
This adds proper handling to reject invalid literals such as `0o0.1` or
`0.0e1`.
No release note because this is fixing an issue with a new change.
At the top-level, both types need to have a tag in order for them to be
compatible within the same TU in C23. An unnamed structure has no tag,
so it cannot be compatible with another type within the TU.
Fixes#141724
WG14 N3469 changed _Lengthof to _Countof but it also introduced the
<stdcountof.h> header to expose a macro with a non-ugly identifier. GCC
vends this header as part of the compiler implementation, so Clang
should do the same.
Suggested-by: Alejandro Colomar <alx@kernel.org>
It turns out that getVLASize() does not get you the size of a single
dimension of the VLA, it gets you the full count of all elements. This
caused _Countof to return invalid values on VLA ranks. Now switched to
using getVLAElements1D() instead, which only gets a single dimension.
Fixes#141409
Thanks to changes to type compatibility rules via WG14 N3007, these
functions can now be called with a compatible type even within the same
TU, which makes the -Wvisibility diagnostic too chatty to have on by
default.
So in C23 mode, -Wvisibility will only diagnose an incomplete tag type
declared in a function prototype. If the tag is defined in the
prototype, the diagnostic is silenced.
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.
We do not diagnose 0 as a deprecated octal literal outside of the
preprocessor. This fixes a bug where we were accidentally diagnosing 0
from a preprocessor conditional, however.
No release note because this is fixing an issue with a new change.
Unlike C++, C allows the definition of an uninitialized `const` object.
If the object has static or thread storage duration, it is still
zero-initialized, otherwise, the object is left uninitialized. In either
case, the code is not compatible with C++.
This adds a new diagnostic group, `-Wdefault-const-init-unsafe`, which
is on by default and diagnoses any definition of a `const` object which
remains uninitialized.
It also adds another new diagnostic group, `-Wdefault-const-init` (which
also enabled the `unsafe` variant) that diagnoses any definition of a
`const` object (including ones which are zero-initialized). This
diagnostic is off by default.
Finally, it adds `-Wdefault-const-init` to `-Wc++-compat`. GCC diagnoses
these situations under this flag.
Fixes#19297
Post-commit review feedback during the language WG meeting requested
that I try to generalize the testing for this rather than only test on
a single target as we previously did.
The tests which are hard to generalize are the VLA tests, so those
still have specific triples in the RUN line, but have more coverage and
a comment explaining that the test should generalize to all targets.
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
A file scope declaration without an initializer which is neither extern
nor thread_local is a tentative definition. If the declaration of an
identifier for an object is a tentative definition and has internal
linkage, the declared type shall not be an incomplete type.
Clang was previously failing to diagnose this in -pedantic mode.
Fixes#50661
---------
Co-authored-by: Mariya Podchishchaeva <mariya.podchishchaeva@intel.com>
C99 introduced macros of the form `INTn_C(v)` which expand to a signed
or unsigned integer constant with the specified value `v` and the type
`int_leastN_t`. Clang's initial implementation of these macros used
token pasting to form the integer constants, but this means that users
cannot define a macro named `L`, `U`, `UL`, etc before including
`<stdint.h>` (in freestanding mode, where Clang's header is being used)
because that could form invalid token pasting results. The new
definitions now use the predefined `__INTn_C` macros instead of using
token pasting. This matches the behavior of GCC.
Fixes#85995
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
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.
WG14 added N3411 to the list of papers which apply to older versions of
C in C2y, and WG21 adopted CWG787 as a Defect Report in C++11. So we no
longer should be issuing a pedantic diagnostic about a file which does
not end with a newline character.
We do, however, continue to support -Wnewline-eof as an opt-in
diagnostic.
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 builtin is supported by GCC and is a way to improve diagnostic
behavior for va_start in C23 mode. C23 no longer requires a second
argument to the va_start macro in support of variadic functions with no
leading parameters. However, we still want to diagnose passing more than
two arguments, or diagnose when passing something other than the last
parameter in the variadic function.
This also updates the freestanding <stdarg.h> header to use the new
builtin, same as how GCC works.
Fixes#124031
Rename and update the wording of
`warn_second_arg_of_va_start_not_last_named_param` to best indicate that
it's actually the last non-variadic parameter instead.
Fixes#131171
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.
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.
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 paper removes UB around use of void expressions. Previously, code
like this had undefined behavior:
```
void foo(void) {
(void)(void)1;
extern void x;
x;
}
```
and this is now well-defined in C2y. Functionally, this now means that
it is valid to use `void` as a `_Generic` association.
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 (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.
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.
The standard mandates that this returns the width of the type, which is
the number of bits in the value. For bool, that's required to be `1`
explicitly.
Fixes#117348
