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.
By far the most important part of this patch is updating
GettingInvolved.rst to include the invite link, but I've grepped for any
other discord.com links.
I'm no Discord expert, but from my experience (confirmed via @preames
kindly testing as well) the direct channel links provide a confusing
experience if you haven't already found and used an invite link to the
LLVM Discord server. If you're logged into Discord but not a member of
LLVM's sever, the web app opens and then...nothing. No channel opens, no
prompt to join the server or even a hint that you need to find an invite
link (and if you're not used to Discord, you likely don't even know
that's necessary).
This patch addresses the issue by providing the invite link where
Discord is mentioned.
Before this commit, there were two alpha checkers that used different
algorithms/logic for detecting out of bounds memory access: the old
`alpha.security.ArrayBound` and the experimental, more complex
`alpha.security.ArrayBoundV2`.
After lots of quality improvement commits ArrayBoundV2 is now stable
enough to be moved out of the alpha stage. As indexing (and dereference)
are common operations, it still produces a significant amount of false
positives, but not much more than e.g. `core.NullDereference` or
`core.UndefinedBinaryOperatorResult`, so it should be acceptable as a
non-`core` checker.
At this point `alpha.security.ArrayBound` became obsolete (there is a
better tool for the same task), so I'm removing it from the codebase.
With this I can eliminate the ugly "V2" version mark almost everywhere
and rename `alpha.security.ArrayBoundV2` to `security.ArrayBound`.
(The version mark is preserved in the filename "ArrayBoundCheckerV2", to
ensure a clear git history. I'll rename it to "ArrayBoundChecker.cpp" in
a separate commit.)
This commit adapts the unit tests of `alpha.security.ArrayBound` to
testing the new `security.ArrayBound` (= old ArrayBoundV2). Currently
the names of the test files are very haphazard, I'll probably create a
separate followup commit that consolidates this.
This flag has been deprecated since Clang 19, having been the default
since then.
It has remained because its negation was still useful to work around
backwards compatibility breaking changes from P0522.
However, in Clang 20 we have landed various changes which implemented
P3310R2 and beyond, which solve almost all of the expected issues, the
known remaining few being a bit obscure.
So this change removes the flag completely and all of its implementation
and support code.
Hopefully any remaining users can just stop using the flag. If there are
still important issues remaining, this removal will also shake the tree
and help us know.
P2280R4 allows the use of references in pointers of unknown origins in a
constant expression context but only in specific cases that could be
constant expressions.
We track whether a variable is a constexpr unknown in a constant
expression by setting a flag in either APValue or LValue and using this
flag to prevent using unknown values in places where it is not allowed.
Fixes: https://github.com/llvm/llvm-project/issues/63139https://github.com/llvm/llvm-project/issues/63117
This patch adds test for
[CWG170](https://cplusplus.github.io/CWG/issues/170.html). The
resolution adds explicit undefined behavior, so I think the best we can
do is to put the test into constexpr evaluator. Change to
[expr.static.cast] is not tested, because it was a drive-by fix that
removed an impossible case (I confirmed it using minutes). Minutes
mention several times a comprehensive paper in this design space which
no one seem to remember. I believe it's
[P0149R0](https://wg21.link/p0149r0) "Generalised member pointers".
When commit 61a76f58ebf1 converted the static analyzer FAQ from HTML to
RST, it accidentally left out three images (`example_*.png`) that were
previously present in that document. This commit re-adds those three
images to the FAQ (and moves them to the directory for the image assets
of the RST documentation).
Moreover commit 093aaca2b0ad _copied_ the file `scan_build_cmd.png` to
the RST documentation directory instead of just moving it; so this
commit removes its "old" copy which is no longer used (because the old
HTML-based documentation file was replaced by a stub that redirects to
the RST docs).
This commit migrates the contents of 'annotations.html' in the old
HTML-based documentation of the Clang static analyzer to the new
RST-based documentation.
During this conversion I reordered the sections of this documentation
file by placing the section "Custom Assertion Handlers" as a subsection
of "Annotations to Enhance Generic Checks". (The primary motivation was
that Sphinx complained about inconsistent section levels; with this
change I preserved that sections describing individual annotations are
all on the same level.)
Apart from this change and the format conversion, I didn't review,
validate or edit the contents of this documentation file because I think
it would be better to place any additional changes in separate commits.
