This PR implement [P3034R1 Module Declarations Shouldn’t be
Macros](https://wg21.link/P3034R1), and refactor the convoluted state
machines in module name lexical analysis.
---------
Signed-off-by: yronglin <yronglin777@gmail.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
This paper is about whether a copy of a va_list object which was not
produced by calling va_copy is valid to use or not. While this may work
on some targets, we explicitly document it as undefined behavior for all
targets so there's not confusion as to when it's valid or not. It's not
a burden for a user to use va_copy explicitly.
WG14 N3274 removed _Imaginary from Annex G. Clang has never fully
supported Annex G or _Imaginary, so removal is pretty trivial for us.
Note, we are keeping _Imaginary as a keyword so that we get better
diagnostic behavior. This is still conforming because _I makes it a
reserved identifier, so it's not available for users to use as an
identifier anyway.
The test coverage for this has to lean on LLVM's test coverage for the
actual TBAA behavior, but this demonstrates that Clang emits reasonable
LLVM IR to support this construct. It would be surprising should LLVM
break this pattern given how ubiquitous the pattern is in the wild.
The paper can be found at:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3254.pdf
This patch implements (not yet published)
[P3144R2](https://wiki.edg.com/pub/Wg21stlouis2024/StrawPolls/p3144r2.pdf)
"Deleting a Pointer to an Incomplete Type Should be Ill-formed". Wording
changes (not yet merged into the working draft) read:
> 7.6.2.9 [expr.delete] Delete
> If the object being deleted has incomplete class type at the point of
deletion <del>and the complete class has a
non-trivial destructor or a deallocation function, the behavior is
undefined</del>, <ins>the program is ill-formed</ins>.
We preserve status quo of emitting a warning when deleting a pointer to
incomplete type up to, and including, C++23, but make it ill-formed
since C++26. Same goes for deleting pointers to `void`, which has been
allowed as an extension.
User documentation currently found at https://clang-analyzer.llvm.org is migrated to RST format.
This commit migrates all the relevant content, including suspicious or even clearly outdated parts. These issues will be cleaned up in separate follow-up commits (where the diff is not obscured by the format change). However, a few typos are fixed, and some parts (availability of binary releases, integration with XCode) are marked (with [Legacy] tags) to highlight that they are outdated.
The primary motivation for this change is to update the facts in the docs and make them discoverable from the RST-generated doc-tree as well (many subpages are not accessible at all, as the menu generation for the HTML-based page is not working at all).
This commit migrates all the relevant content, including parts that are
suspicious or even clearly outdated. These issues will be cleaned up in
separate follow-up commits (where the diff is not obscured by the format
change). However, a few typos are fixed and some parts (availability of
binary releases, integration with XCode) are marked (with [Legacy] tags)
to highlight that they are outdated.
The primary motivation for this change is to update the facts in the
docs and make them discoverable from the RST-generated doc-tree as well
(many subpages are not accessible **at all**, as the menu generation for
the HTML based page is not working at all).
Documentation for the checkers is kept up to date in RST files.
This patch removes duplication by replacing the HTML docs with links to
docs generated from the RST.
This is in support of WG14 N2848 which only define the macros if
an infinity or nan are supported. However, because we support builtins
that can produce an infinity or a NAN, and because we have pragmas
that control infinity or NAN behavior, we always define the macros even
if the user passed -ffinite-math-only on the command line.
This adds a language standard mode for the latest C standard. While
WG14 is hoping for a three-year cycle, it is not clear that the next
revision of C will be in 2026 and so a flag was not created for c26
specifically.
This paper was a rewording of WG14 N1485, correcting terminology and
bringing the C11 feature slightly closer in line with the C++11
feature. There is nothing additional to be done or test to conform to
what was specified by WG14 N1537, so we'll remove the entry and lean on
N1485 to track status for atomics.
N2843 was subsumed by N2882; we could probably consider removing
subsumed entries, but I've been leaving them to help folks looking at
the editor's report from various working drafts and wondering about the
changes.
This paper was adopted at the Oct 2019 meeting in Ithaca, but the
changes from the paper were later removed (editorially) by the C
Floating Point study group due to being incorrect and unnecessary.
This paper clarified the lifetime of compound literal objects in odd
scopes, such as use at function prototype scope.
We do not currently implement this paper, as the new test demonstrates.
Only the first proposed changes in the paper were adopted, and that
wording was changing "operations" into "operators", which is purely an
editorial change.
We now believe we know the status of all the proposals that went into
C99. There are three entries marked Partial:
N448 restricted pointers
------------------------
Clang fully conforms to the standard requirements, but LLVM support
could be improved to support more than just restricted pointers used
as function parameters.
N693 complex and imaginary support in <complex.h>
-------------------------------------------------
Clang supports _Complex but not _Imaginary. Clang does not attempt to
implement Annex G, so a lack of _Imaginary is not necessary for
conformance to C99. It's also worth noting that C2y is anticipated to
remove support for _Imaginary (see WG14 N3274 which was adopted at the
June 2024 meeting).
However, support for _Complex requires runtime support and compiler-rt
is not supported on all targets (notably, Windows).
(Doc # unknown) IEC 60559 support
---------------------------------
Clang largely conforms to the requirements in Annex F, but there are
edge cases that are incorrect. However, Clang does not predefine the
__STDC_IEC_559__ macro and so we don't claim to conform to Annex F yet.
Because all three of these partial entries are technically conforming,
it seems reasonable to claim full conformance for C99.
We intend to support Annex F but there are edge cases we don't handle
properly, such as raising an "invalid" exception when converting some
floating-point values to integers.
This does not add any test coverage as full conformance would require
sufficiently extensive testing that we should consider getting a
third-party test suite such as the one from http://tybor.com/
We don't have a document number to check our behavior against, but the
document title makes it clear that this is related to optimization
behavior, which doesn't require Clang to change.
This patch covers
[CWG2811](https://cplusplus.github.io/CWG/issues/2811.html) "Clarify
"use" of main", basically adding a test for `-Wmain`, focusing on usages
of `main` in unevaluated contexts.
To my understanding, the diagnostic message is based on the wording, so
I updated it based on the new wording. I also replaces "ISO C++
requires" with a phrasing that explicitly says "extension".
This PR covers the following Core issues:
[CWG204](https://cplusplus.github.io/CWG/issues/204.html) "Exported
class templates"
[CWG323](https://cplusplus.github.io/CWG/issues/323.html) "Where must
`export` appear?"
[CWG335](https://cplusplus.github.io/CWG/issues/335.html) "Allowing
`export` on template members of nontemplate classes"
[CWG820](https://cplusplus.github.io/CWG/issues/820.html) "Deprecation
of `export`"
I believe the list above is entirety of Core issues that are dedicated
solely to `export template`.
I believe we have two main points of view here, which command what this
PR should do:
1. (easy) Removal of `export template` was done as a defect report in
CWG820, and the rest are effectively superseded by it, because we apply
defect reports retroactively.
2. (harder) Those Core issues are testable individually, so we should
test them for the behavior Core wanted at the time.
This PR implements the first option, making our C++ DR status page
greener.
I think I can be persuaded to go with the second option, if reviewers
have strong preference for it.
This is the paper that added the 'restrict' keyword. Clang is
conforming to the letter of the standard's requirements, so it would be
defensible for us to claim full support instead. However, LLVM does not
currently support the optimization semantics with restricted local
variables or data members, only with restricted pointers declared in
function parameters. So we're only claiming partial support because we
don't yet take full advantage of what the feature allows.
This was a roll-up of defect reports that we already test elsewhere, so
no additional test coverage is needed.
DR345: tested by clang/test/C/drs/dr3xx.c
DR344: tested by clang/test/C/drs/dr3xx.c
DR343: tested by clang/test/C/drs/dr3xx.c
DR341: tested by clang/test/C/drs/dr3xx.c
DR340: tested by clang/test/C/drs/dr3xx.c
DR338: tested by clang/test/C/drs/dr338.c
DR336: N/A for the compiler
DR330: N/A for the compiler
DR329: N/A for the compiler
DR328: tested by clang/test/C/drs/dr3xx.c
DR327: editorial
DR326: N/A for the compiler
DR315: tested by clang/test/C/drs/dr3xx.c
This commit implements the entirety of the now-accepted [N3017
-Preprocessor
Embed](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3017.htm) and
its sister C++ paper [p1967](https://wg21.link/p1967). It implements
everything in the specification, and includes an implementation that
drastically improves the time it takes to embed data in specific
scenarios (the initialization of character type arrays). The mechanisms
used to do this are used under the "as-if" rule, and in general when the
system cannot detect it is initializing an array object in a variable
declaration, will generate EmbedExpr AST node which will be expanded by
AST consumers (CodeGen or constant expression evaluators) or expand
embed directive as a comma expression.
This reverts commit
682d461d5a.
---------
Co-authored-by: The Phantom Derpstorm <phdofthehouse@gmail.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
Co-authored-by: H. Vetinari <h.vetinari@gmx.com>
Used to implement CWG2191 where `typeid` for a polymorphic glvalue only
becomes potentially-throwing if the `typeid` operand was already
potentially throwing or a `nullptr` check was inserted:
https://cplusplus.github.io/CWG/issues/2191.html
Also change `Expr::hasSideEffects` for `CXXTypeidExpr` to check the
operand for side-effects instead of always reporting that there are
side-effects
Remove `IsDeref` parameter of `CGCXXABI::shouldTypeidBeNullChecked`
because it should never return `true` if `!IsDeref` (we shouldn't add a
null check that wasn't there in the first place)
I believe it has been implemented since D139837 "Implements CTAD for
aggregates P1816R0 and P2082R1", so this just claims we have already
supported it.
Plus an update on the dr status page.
The checker `alpha.core.SizeofPtr` was a very simple checker that did
not rely on path sensitive analysis and was very similar to the (more
complex and refined) clang-tidy check `bugprone-sizeof-expression`.
As there is no reason to maintain two separate implementations for the
same goal (and clang-tidy is more lightweight and accessible than the
Analyzer) I decided to move this functionality from the Static Analyzer
to clang-tidy.
Recently my commit 546c816a529835a4cf89deecff957ea336a94fa2
reimplemented the advantageous parts of `alpha.core.SizeofPtr` within
clang-tidy; now this commit finishes the transfer by deleting
`alpha.core.SizeofPtr`.
