Closes https://github.com/llvm/llvm-project/issues/59765.
Currently we will generate the global ctor/dtor for variables in
importing modules. It will cause multiple initialization/destructions.
It makes no sense. This patch tries to not generate global ctor/dtor for
variables which are available externally. Note that the variables in
header units and clang modules won't be available externally by default.
Reviewed By: iains
Differential Revision: https://reviews.llvm.org/D140867
[module.import/6] last sentence:
A header unit shall not contain a definition of a non-inline function or
variable whose name has external linkage.
Differential Revision: https://reviews.llvm.org/D140261
Implement https://cplusplus.github.io/CWG/issues/2631.html.
Immediate calls in default arguments and defaults members
are not evaluated.
Instead, we evaluate them when constructing a
`CXXDefaultArgExpr`/`BuildCXXDefaultInitExpr`.
The immediate calls are executed by doing a
transform on the initializing expression.
Note that lambdas are not considering subexpressions so
we do not need to transform them.
As a result of this patch, unused default member
initializers are not considered odr-used, and
errors about members binding to local variables
in an outer scope only surface at the point
where a constructor is defined.
Reviewed By: aaron.ballman, #clang-language-wg, rupprecht
Differential Revision: https://reviews.llvm.org/D136554
During template instantiation, the instantiator will enter constant
evaluated
context before instantiate a template argument originated from an
expression,
and this impedes the instantiator from creating lambdas with independent
types.
This patch solves the problem via widening the condition that the
instantiator
marks lambdas as never dependent, and fixes the issue #57960
Differential Revision: https://reviews.llvm.org/D140554
In C mode, if e1 has __attribute__((noreturn)) but e2 doesn't, `(c ? e1 : e2)`
is incorrectly noreturn and Clang codegen produces `unreachable`
which may lead to miscompiles (see [1] `gawk/support/dfa.c`).
This problem has been known since
8c6b56f39d (2010) or earlier.
Fix this by making the result type noreturn only if both e1 and e2 are
noreturn, matching GCC.
`_Noreturn` and `[[noreturn]]` do not have the aforementioned problem.
Fix https://github.com/llvm/llvm-project/issues/59792 [1]
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D140868
Previously, if a header file and a source file used different end of line
(EOL) forms, preprocessed output generated with the -frewrite-includes option
would, in some cases, generate line control directives with the wrong line
number due to an error in how source file lines were counted.
Fixes https://github.com/llvm/llvm-project/issues/59736
Reviewed By: cor3ntin
Differential Revision: https://reviews.llvm.org/D140984
This feature causes clang to crash when compiling Chrome - see
https://crbug.com/1405031 and
https://github.com/llvm/llvm-project/issues/59675
Revert "[clang] Fix a clang crash on invalid code in C++20 mode."
This reverts commit 32d7aae04f.
Revert "[clang] Remove overly restrictive aggregate paren init logic"
This reverts commit c77a91bb7b.
Revert "[clang][C++20] P0960R3 and P1975R0: Allow initializing aggregates from a parenthesized list of values"
This reverts commit 40c52159d3.
This reverts commit 85960043d5.
The powerpc64le self-built buildbot had an assertion during self-build,
that seems like it is possibly related here, reverting so the author can
take a look.
As noted in https://github.com/llvm/llvm-project/issues/59624, we sometimes mark implicitly
deleted special member functions as non-trivial. This is unnecessary work and leads to some
weird type traits errors.
This fixes the problem by making the implicitly deleted special member functions always
trivial.
Reviewed By: #clang-language-wg, erichkeane
Differential Revision: https://reviews.llvm.org/D140664
Originally, the code would take a lookup result as a member in the
current scope and build a member expression accordingly, if the lookup
result was not an operand of the address operator, or it was a field
declaration. However, a field declaration may come from another class,
and cause the issue #58674.
Thus, this patch fixes the issue via checking where does the field
declaration comes from, and if it comes from another class, then marks
it as not member in the current scope. The parent scopes of the current
scope are also checked, as the current scope may be associated to a
lambda or friend declaration.
Differential Revision: https://reviews.llvm.org/D137531
Closes https://github.com/llvm/llvm-project/issues/54457.
This removes a FIXME we found previously. But we didn't remove the FIXME
that time due to the lack of the corresponding test. And now we found
the corresponding test so we can remove it.
"__cmpccxadd_epi*" -> "_cmpccxadd_epi*"
This is to align with other intrinsics to follow single leading "_" style. Gcc
and intrinsic guide website will also apply this change.
Reviewed By: LuoYuanke, skan
Differential Revision: https://reviews.llvm.org/D140281
CSS uses colons, not the equals sign. The final semicolon is optional,
but preferred to be included. Really, the font property doesn't really
need to be there, but I suppose it was put there for a reason.
It's surprising how lenient browsers are when parsing
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D138441
For cases of defining friend functions, qualifier ordering can
allow multiple positions for the 'friend' token.
Closes#59450.
Differential Revision: https://reviews.llvm.org/D139801
AggExprEmitter::VisitInitListExpr sanity checks that an empty union is really
empty and not a semantic analysis failure. The assert is missing that we allow
anonymous structs as a GNU extension. I have updated the assert to take that into account.
This fixes: https://github.com/llvm/llvm-project/issues/58800
Differential Revision: https://reviews.llvm.org/D139261
This is a fairly large changeset, but it can be broken into a few
pieces:
- `llvm/Support/*TargetParser*` are all moved from the LLVM Support
component into a new LLVM Component called "TargetParser". This
potentially enables using tablegen to maintain this information, as
is shown in https://reviews.llvm.org/D137517. This cannot currently
be done, as llvm-tblgen relies on LLVM's Support component.
- This also moves two files from Support which use and depend on
information in the TargetParser:
- `llvm/Support/Host.{h,cpp}` which contains functions for inspecting
the current Host machine for info about it, primarily to support
getting the host triple, but also for `-mcpu=native` support in e.g.
Clang. This is fairly tightly intertwined with the information in
`X86TargetParser.h`, so keeping them in the same component makes
sense.
- `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains
the target triple parser and representation. This is very intertwined
with the Arm target parser, because the arm architecture version
appears in canonical triples on arm platforms.
- I moved the relevant unittests to their own directory.
And so, we end up with a single component that has all the information
about the following, which to me seems like a unified component:
- Triples that LLVM Knows about
- Architecture names and CPUs that LLVM knows about
- CPU detection logic for LLVM
Given this, I have also moved `RISCVISAInfo.h` into this component, as
it seems to me to be part of that same set of functionality.
If you get link errors in your components after this patch, you likely
need to add TargetParser into LLVM_LINK_COMPONENTS in CMake.
Differential Revision: https://reviews.llvm.org/D137838
Implement the proposed UAX Profile
"Mathematical notation profile for default identifiers".
This implements a not-yet approved Unicode for a vetted
UAX31 identifier profile
https://www.unicode.org/L2/L2022/22230-math-profile.pdf
This change mitigates the reported disruption caused
by the implementation of UAX31 in C++ and C2x,
as these mathematical symbols are commonly used in the
scientific community.
Fixes#54732
Reviewed By: tahonermann, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D137051
MSVC requires that C++23 be available (_HAS_CXX23) else the entire
content is elided. Conditionalise the inclusion properly so that C/C++
code using stdatomic.h for memory_order_* constants are able to do
so without changing the C++ standard. This repairs builds of Swift and
libdispatch after ba49d39b20.
Differential Revision: https://reviews.llvm.org/D139266
Reviewed By: aaron.ballman, Mordante, fsb4000
The main goal of this work is to allow developers to express the need to place instances
of a class or structure in the read-only part of the program memory. Such a placement is
desirable to prevent any further modifications to the instances of a given structure, by
leveraging the read-only run time protection.
To achieve this, we are introducing a new attribute that can be attached to any record
definition or a declaration. The compiler enforces that every instance of this type can
be placed in the read-only segment of the program memory, provided the target triplet
supports such a placement. If an instance of a given type bearing this attribute doesn’t
satisfy such a placement, the compiler attaches an appropriate warning at suitable program
locations. In other words, adding this attribute to a type requires every instance of this
type to be a global const, which are placed in the read-only segments for most target
triplets. However, this is *not a language feature* and it *need not* be true for
*all target triplets*.
The current patch emits a warning at global variable declaration sites of types bearing
the attribute without const qualification and corresponding note attached to the type
definition/declaration.
Differential Revision: https://reviews.llvm.org/D135851
This patch implements P0960R3, which allows initialization of aggregates
via parentheses.
As an example:
```
struct S { int i, j; };
S s1(1, 1);
int arr1[2](1, 2);
```
This patch also implements P1975R0, which fixes the wording of P0960R3
for single-argument parenthesized lists so that statements like the
following are allowed:
```
S s2(1);
S s3 = static_cast<S>(1);
S s4 = (S)1;
int (&&arr2)[] = static_cast<int[]>(1);
int (&&arr3)[2] = static_cast<int[2]>(1);
```
This patch was originally authored by @0x59616e and completed by
@ayzhao.
Fixes#54040, Fixes#54041
Co-authored-by: Sheng <ox59616e@gmail.com>
Full write up : https://discourse.llvm.org/t/c-20-rfc-suggestion-desired-regarding-the-implementation-of-p0960r3/63744
Reviewed By: ilya-biryukov
Differential Revision: https://reviews.llvm.org/D129531
This reverts commit f1f1b60c7b.
Temporary revert, possibly triggers a new assertion failure on
QualType::getCommonPtr.
We're working on a reproducer, to follow-up on
https://reviews.llvm.org/D136554.
Implement https://cplusplus.github.io/CWG/issues/2631.html.
Immediate calls in default arguments and defaults members
are not evaluated.
Instead, we evaluate them when constructing a
`CXXDefaultArgExpr`/`BuildCXXDefaultInitExpr`.
The immediate calls are executed by doing a
transform on the initializing expression.
Note that lambdas are not considering subexpressions so
we do not need to transform them.
As a result of this patch, unused default member
initializers are not considered odr-used, and
errors about members binding to local variables
in an outer scope only surface at the point
where a constructor is defined.
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D136554
to member naming a weak member to nullptr.
This fixes a miscompile where constant evaluation would incorrectly
determine that a weak member function pointer is never null.
In passing, also improve the diagnostics for constant evaluation of some
nearby cases.
The CFL Steens/Anders alias analysis passes are not enabled by
default, and to the best of my knowledge have no pathway towards
ever being enabled by default. The last significant interest in
these passes seems to date back to 2016. Given the little
maintenance these have seen in recent times, I also have very
little confidence in the correctness of these passes. I don't
think we should keep these in-tree.
Differential Revision: https://reviews.llvm.org/D139703
Implement https://cplusplus.github.io/CWG/issues/2631.html.
Immediate calls in default arguments and defaults members
are not evaluated.
Instead, we evaluate them when constructing a
`CXXDefaultArgExpr`/`BuildCXXDefaultInitExpr`.
The immediate calls are executed by doing a
transform on the initializing expression.
Note that lambdas are not considering subexpressions so
we do not need to transform them.
As a result of this patch, unused default member
initializers are not considered odr-used, and
errors about members binding to local variables
in an outer scope only surface at the point
where a constructor is defined.
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D136554
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
Implement https://cplusplus.github.io/CWG/issues/2631.html.
Immediate calls in default arguments and defaults members
are not evaluated.
Instead, we evaluate them when constructing a
`CXXDefaultArgExpr`/`BuildCXXDefaultInitExpr`.
The immediate calls are executed by doing a
transform on the initializing expression.
Note that lambdas are not considering subexpressions so
we do not need to transform them.
As a result of this patch, unused default member
initializers are not considered odr-used, and
errors about members binding to local variables
in an outer scope only surface at the point
where a constructor is defined.
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D136554
The [initial implementation][1] of __attribute__((format)) on non-variadic functions
accidentally only accepted one data argument. This worked:
```c
__attribute__((format(printf, 1, 2)))
void f(const char *, int);
```
but this didn't:
```c
__attribute__((format(printf, 1, 2)))
void f(const char *, int, int);
```
This is due to an oversight in changing the way diagnostics are emitted for
`attribute((format))`, and to a coincidence in the handling of the variadic case. Test
cases only covered the case that worked by coincidence.
Before the previous change, using `__attribute__((format))` on a non-variadic function at
all was an error and clang bailed out. After that change, it only generates a GCC
compatibility warning. However, as execution falls through, it hits a second diagnostic
when the first data argument is neither 0 nor the last parameter of the function.
This change updates that check to allow any parameter after the format string to be the
first data argument when the function is non-variadic. When the function is variadic, it
still needs to be the index of the `...` "parameter". Attribute documentation is updated
to reflect the change and new tests are added to verify that it works with _two_ data
parameters.
[1]: https://reviews.llvm.org/D112579
Radar-Id: rdar://102069446
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D137603
AIX and OpenBSD seem to use -p. For most targets (at least FreeBSD and Linux),
-p is legacy (GCC freebsd has a warning). We don't want the uses to grow, so
making -p an alias for -pg is not recommended. I think the uses are small.
Reviewed By: mgorny
Differential Revision: https://reviews.llvm.org/D138255
Explanations for options of floating point are updated to match
the `RenderFloatingPointOptions` function in
`clang/lib/Driver/ToolChains/Clang.cpp`.
Missing explanations are also added.
Differential Revision: https://reviews.llvm.org/D138117
