WG14 N2939 (Identifier Syntax Fixes) corrects a grammar issue in the C
standard but does not otherwise change intended behavior. This change
updates the C23 status to note this paper as implemented as of Clang 15;
the release in which support for N2836 (Identifier Syntax using Unicode
Standard Annex 31) was implemented.
In Clang 16, we implemented the ability to add a label at the end of a
compound statement. These changes complete the implementation by
allowing a label to be followed by a declaration in C.
Note, this seems to have fixed an issue with some OpenMP stand-alone
directives not being properly diagnosed as per:
https://www.openmp.org/spec-html/5.1/openmpsu19.html#x34-330002.1.3
(The same requirement exists in OpenMP 5.2 as well.)
Fixes https://github.com/llvm/llvm-project/issues/58637.
Adds `isAlignas()` method on `AttributeCommonInfo` which accounts for
C++ `alignas` as well as C11 `_Alignas`.
The method is used to improve diagnostic in C when `_Alignas` is used in
C at the wrong location. This corrects the previously suggested move
of `_Alignas` past the declaration specifier, now warns attribute
`_Alignas` is ignored.
Based on https://reviews.llvm.org/D141177.
These are an artifact of how types are structured but serve little
purpose, merely showing that the type is sugared in some way. For
example, ElaboratedType's existence means struct S gets printed as
'struct S':'struct S' in the AST, which is unnecessary visual clutter.
Note that skipping the second print when the types have the same string
matches what we do for diagnostics, where the aka will be skipped.
When declaring `auto int` at local or file scope, we emit a warning
intended for C++11 and later, which is incorrect and confusing in C23.
See [Godbolt example](https://godbolt.org/z/j1acGhecd).
Now this diagnostic does not show up in C23.
Re-landing 5d78b78c85 which was reverted.
This patches implements the auto keyword from the N3007 standard
specification.
This allows deducing the type of the variable like in C++:
```
auto nb = 1;
auto chr = 'A';
auto str = "String";
```
The list of statements which allows the usage of auto:
* Basic variables declarations (int, float, double, char, char*...)
* Macros declaring a variable with the auto type
The list of statements which will not work with the auto keyword:
* auto arrays
* sizeof(), alignas()
* auto parameters, auto return type
* auto as a struct/typedef member
* uninitialized auto variables
* auto in an union
* auto as a enum type specifier
* auto casts
* auto in an compound literals
Differential Revision: https://reviews.llvm.org/D133289
This patches implements the auto keyword from the N3007 standard
specification.
This allows deducing the type of the variable like in C++:
```
auto nb = 1;
auto chr = 'A';
auto str = "String";
```
The list of statements which allows the usage of auto:
* Basic variables declarations (int, float, double, char, char*...)
* Macros declaring a variable with the auto type
The list of statements which will not work with the auto keyword:
* auto arrays
* sizeof(), alignas()
* auto parameters, auto return type
* auto as a struct/typedef member
* uninitialized auto variables
* auto in an union
* auto as a enum type specifier
* auto casts
* auto in an compound literals
Differential Revision: https://reviews.llvm.org/D133289
We were calling `isFunctionProtoType()` on a `ParsedType` rather than
creating a valid semantic type first and calling the function on that.
The call to `isFunctionProtoType()` would eventually call
`getUnqualifiedDesugaredType()`, which loops indefinitely until we get
a desugared type and a `ParsedType` will never finish desugaring.
Fixes https://github.com/llvm/llvm-project/issues/64713
C2x was finalized at the June 2023 WG14 meeting. The DIS is out for
balloting and the comment period for that closes later this year/early
next year. While that does leave an opportunity for more changes to the
standard during the DIS ballot resolution process, only editorial
changes are anticipated and as a result, the C committee considers C2x
to be final. The committee took a straw poll on what we'd prefer the
informal name of the standard be, and we decided it should be called
C23 regardless of what year ISO publishes it.
However, because the final publication is not out, this patch does not
add the language standard alias for the -std=iso9899:<year> spelling of
the standard mode; that will be added once ISO finally publishes the
document and the year chosen will match the publication date.
This also changes the value of __STDC_VERSION__ from the placeholder
value 202000L to the final value 202311L.
Subsequent patches will start renaming things from c2x to c23, cleaning
up documentation, etc.
Differential Revision: https://reviews.llvm.org/D157606
This fix PR37919
The below code produces -Wconstant-logical-operand for the first statement,
but not the second.
void foo(int x) {
if (x && 5) {}
if (5 && x) {}
}
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D142609
This fixes running tests with a toolchain that defaults to a MinGW
target.
After the previous attempt with this patch, this is now changed to
use !defined(__MINGW32__) instead of defined(_MSC_VER) to distinguish
between MSVC and MinGW mode; Clang doesn't define _MSC_VER when invoked
with "clang -cc1" as some of those tests do.
Differential Revision: https://reviews.llvm.org/D149997
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
It isn't immediately obvious why that code should be accepted given the
wording of C2x 6.7.10p4, so this adds a comment explaining that there
is an existing extension to support zero-sized arrays in C, and that
empty initialization of an unbounded array in C++ deduces the array
extent as zero, so C is exposing the same extension as in C++.
This implements support for allowing {} to consistently zero initialize
objects. We already supported most of this work as a GNU extension, but
the C2x feature goes beyond what the GNU extension allowed.
The changes in this patch are:
* Removed the -Wgnu-empty-initializer warning group. The extension is
now a C2x extension warning instead. Note that use of
`-Wno-gnu-empty-initializer seems` to be quite low in the wild
(https://sourcegraph.com/search?q=context%3Aglobal+-file%3A.*test.*+%22-Wno-gnu-empty-initializer%22&patternType=standard&sm=1&groupBy=repo
which currently only gives 8 hits total), so this is not expected to
be an overly disruptive change. But I'm adding the clang vendors
review group just in case this expectation is wrong.
* Reworded the diagnostic wording to be about a C2x extension, added a
pre-C2x compat warning.
* Allow {} to zero initialize a VLA
This functionality is exposed as an extension in all older C modes
(same as the GNU extension was), but does *not* allow the extension for
VLA initialization in C++ due to concern about handling non-trivially
constructible types.
Differential Revision: https://reviews.llvm.org/D147349
This adds test coverage for N2607, which makes arrays and their
elements identically qualified. Clang already implements much of the
functionality from this paper, but is still missing some support.
It also adds some details to the C status page so users have this
information as well.
This paper clarifies that complete object types need to be smaller than
SIZE_MAX. We already conformed to that requirement, so this adds some
test coverage to prove it.
The paper was making minor corrections to the standard that Clang had
already implemented. This adds (most of) the test coverage for the
paper and claims support. In my testing, we supported this in Clang 15.
Add an optional error check to test case for it to pass on targets that do not support thread_local storage.
Reviewed By: aaron.ballman, abhina.sreeskantharajan
Differential Revision: https://reviews.llvm.org/D145158
This implements WG14 N2934
(https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2934.pdf), which
adds keywords for alignas, alignof, bool, static_assert, and
thread_local in C, as aliases for _Alignas, _Alignof, _Bool,
_Static_assert, and _Thread_local. We already supported the keywords in
C2x mode, but this completes support by adding pre-C2x compat warnings
and updates the stdalign.h header in freestanding mode.
This implements WG14 N2886 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2886.htm)
which removed the macro entirely. (NB the macro was deprecated in C17.)
As the paper is not particularly clear on what alternative was picked,
here are my notes from the May 2022 meeting:
Does WG14 wish to adopt variant 1, change 3.2, 3.3, and 3.4 from N2886
into C23?
14/2/2 (consensus)
Does WG14 want to exchange Variant 1 with Variant 2 in N2886 in C23?
9/3/6 (consensus)
(There was no sentiment in the room for either Variant 3 or Variant 4
so those were not voted on.)
Does WG14 want to integrate change 3.5 in N2886 into C23?
8/1/9 (consensus)
Does WG14 want to integrate change 3.6 in N2886 into C23?
2/5/9 (no consensus)
Any code that is broken by the removal can remove the use of
ATOMIC_VAR_INIT and use regular initialization instead.
Differential Revision: https://reviews.llvm.org/D144196
This exposes __builtin_unreachable as the expansion for the unreachable
macro in C2x. I added this definition under __need_STDDEF_H_misc on the
assumption there is no need for a separate need macro to control adding
this.
Differential Revision: https://reviews.llvm.org/D143430
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm made very
clear that it is an UB having type definitions with in offsetof.
Clang supports defining a type as the first argument as a conforming
extension due to how many projects use the construct in C99 and earlier
to calculate the alignment of a type. GCC also supports defining a type
as the first argument.
This adds extension warnings and documentation for the functionality
Clang explicitly supports.
Fixes#57065
Reverts the revert of 39da55e8f5
Co-authored-by: Yingchi Long <i@lyc.dev>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Differential Revision: https://reviews.llvm.org/D133574
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm made very
clear that it is an UB having type definitions with in offsetof.
Clang supports defining a type as the first argument as a conforming
extension due to how many projects use the construct in C99 and earlier
to calculate the alignment of a type. GCC also supports defining a type
as the first argument.
This adds extension warnings and documentation for the functionality
Clang explicitly supports.
Fixes#57065
Co-authored-by: Yingchi Long <i@lyc.dev>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
In general, the source tree is not assumed to be writeable, so modifying `%s` does not work for all CI systems. Instead of touching `%s`, copy it to a writeable dir using `%t`, and touch it there.
Actually, `dr0xx.c` isn't really needed at all, so just create a new `dep.c` file in the build tree.
This was recently added in cb088e8c3a, fixed in 1481fcf780, and fixed again in d16c590130.
If dr0xx.c's timestamp is newer than dr324.c the preprocessor will issue
an unexpected diagnostic in dr324.c. To prevent this diagnostic we can
have dr324.c run touch against itself to force its timestamp to be new.
The test uses
#pragma GCC dependency "oops\..\dr0xx.c"
to test preprocessor "tokenization obscurities". However, that
pragma also emits a warning if the refered file is newer than the
current file -- and d694e2490a edited dr0xx.c, causing this warning
to fire.
As workaround, touch this file, so that it's newer than dr0xx.c again.
This implements WG14 N2975 relaxing requirements for va_start
(https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2975.pdf), which
does two things:
1) Allows the declaration of a variadic function without any named
arguments. e.g., void f(...) is now valid, as in C++.
2) Modified the signature of the va_start macro to be a variadic macro
that accepts one or more arguments; the second (and later) arguments
are not expanded or evaluated.
I followed the GCC implementation in terms of not modifying the
behavior of `__builtin_va_start` (it still requires exactly two
arguments), but this approach has led to several QoI issues that I've
documented with FIXME comments in the test. Specifically, the
requirement that we do not evaluate *or expand* the second and later
arguments means it's no longer possible to issue diagnostics for
compatibility with older C versions and C++. I am reaching out to
folks in WG14 to see if we can get an NB comment to address these
concerns (the US comment period has already closed, so I cannot file
the comment myself), so the diagnostic behavior may change in the
future.
I took this opportunity to add some documentation for all the related
builtins in this area, since there was no documentation for them yet.
Differential Revision: https://reviews.llvm.org/D139436
The changes in this paper add a new recommended practice. I had
originally marked Clang as supporting this paper because we're not
obligated to follow a recommended practice. However, in retrospect, it
seems more useful to document whether we implement the recommendation
or not. This adds a test for those changes.
