usage information in JSON to a file
Each line in the file is a JSON object that has the name of the main
source file followed by the list of system header files included
directly or indirectly from that file.
For example:
{"source":"/tmp/foo.c",
"includes":["/usr/include/stdio.h", "/usr/include/stdlib.h"]}
To reduce the amount of data written to the file, only the system
headers that are directly included from a non-system header file are
recorded.
In order to emit the header information in JSON, it is necessary to set
the following environment variables:
CC_PRINT_HEADERS_FORMAT=json CC_PRINT_HEADERS_FILTERING=only-direct-system
The following combination is equivalent to setting CC_PRINT_HEADERS=1:
CC_PRINT_HEADERS_FORMAT=textual CC_PRINT_HEADERS_FILTERING=none
Differential Revision: https://reviews.llvm.org/D137996
The global constant arguments could be in a different address space
than the first argument, so we have to add another overloaded argument.
This patch was originally made for CHERI LLVM (where globals can be in
address space 200), but it also appears to be useful for in-tree targets
as can be seen from the test diffs.
Differential Revision: https://reviews.llvm.org/D138722
This patch adds interpretation of the overloaded equality and inequality
operators available for the optional types.
Fixes issue #57253.
Differential Revision: https://reviews.llvm.org/D139360
They were previously not handled, causing the llvm_unreachable with
"getIntegerRank(): not a built-in integer" message to be hit.
The test case is derived from how we hit it in Chromium
(crbug.com/1396142). I tried to come up with something more direct, but
this is the best I could find.
Differential revision: https://reviews.llvm.org/D139428
Ensure that the correct information whether an init-capture of a lambda
is passed by reference or by copy. This information is already computed
and has to be passed to the place where `NewInitCaptureType` is
created.
Before this fix it has been checked whether the VarDecl is a reference
type. This doesn't work for packed expansions, as the information
whether it is passed by reference or by copy is stored at the pattern of
a `PackExpansionType` and not at the type itself.
However, as the information has been already computed, we just have to
pass it.
Add tests that lambda captures with var decls which are reference types
are created in the AST and a disgnotics test for pack expansions.
Fixes#49266
Differential Revision: https://reviews.llvm.org/D139125
Almost all of the other SVE LLVM IR intrinsics take i32 values
for lane indices or other immediates. We should bring the bfloat
intrinsics in line with that. It will also make it easier to
add support for the SVE2.1 float intrinsics in future, since
they reuse the same underlying instruction classes.
I've maintained backwards compatibility with the old i64 variants
and used the autoupgrade mechanism.
Differential Revision: https://reviews.llvm.org/D138788
We've exploited test data class instructions introduced in ISA 3.0.
This change unifies the scalar intrinsics into ppc_test_data_class
and add support for 128-bit precision float values using xststdcqp.
Vector versions of the intrinsic can't be unified because they return
vector int instead of int.
Reviewed By: shchenz
Differential Revision: https://reviews.llvm.org/D138105
LValuePathSerializationHelper's type properly
Close https://github.com/llvm/llvm-project/issues/58716.
Tested with libcxx's modules build.
When we read the type of
LValuePathSerializationHelper, we didn't read the correct type. We read
the element type as its name suggests. But the problem here is that it
looks like that both the usage and serialization use its type as the
top level type. So here is the mismatch.
Actually, the type of LValuePathSerializationHelper is never used after
Deserialization without the assertion. So it doesn't matter for the
release users. And this patch shouldn't change the behavior too.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D139406
Some buildbots are failing in Clang and LLDB tests. (I guess the LLDB
failure is due to the explicit C language tests in DwarfUnit.cpp that
need to be updated - not sure what the Clang failures are about, they
seem to be still emitting C99 when we're expecting C11 and I checked
those tests pass... maybe systems with a different C language version
default?)
This reverts commit 3c312e48f325c1b1ee11404ee6cfa08ee00037b0.
This assertion failure was introduced in 9ed2e68c9ae5 and is
manifested when both RemoveBracesLLVM and MacroBlockBegin are set.
Fixes#59335.
Differential Revision: https://reviews.llvm.org/D139281
This may be a breaking change for consumers if they're trying to detect
if code is C or C++, since it'll start using new codes that they may not
be ready to recognize, in which case they may fall back to non-C
handling.
Differential Revision: https://reviews.llvm.org/D138597
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
On SystemZ, the vector ABI changes depending on the presence of hardware
vector support. Therefore, each binary compiled with a visible vector ABI
(e.g. one that calls an external function with a vector argument) should be
marked with a .gnu_attribute describing this.
Reviewed By: uweigand
Differential Revision: https://reviews.llvm.org/D105067
And make use of this from clangd's CodeComplete and IncludeFixer, although currently they are both restricted only to #include symbols.
Differential Revision: https://reviews.llvm.org/D128677
The IncludeDirective contains both Include (the current behavior) and Import,
which we can use in the future to provide #import suggestions for
Objective-C files/symbols.
Differential Revision: https://reviews.llvm.org/D128457
This reverts commit 6b992bcce0c5a86f57c83dd8d0ac9e63bcfc5521.
Test fails on macOS where ar doesn't want to create empty archives,
see https://reviews.llvm.org/D137275#3974489
This only contains the SelectionDAG implementation. GlobalISel to
follow.
The broad approach is:
- Introduce new builtins for 128-bit wide instructions.
- Lower these to @llvm.read_register.i128/@llvm.write_register.i128
- Introduce target-specific ISD nodes which have legal operands (two
i64s rather than an i128). These are named AArch64::{MRRS, MSRR} to
match the instructions they are for. These are a little complex as
they need to match the "shape" of what they're replacing or the
legaliser complains.
- Select these using the existing tryReadRegister/tryWriteRegister to
share the MDString parsing code, and introduce additional code to
ensure these are selected into the right MRRS/MSRR instructions. What
makes this hard is ensuring that the two i64s end up in an XSeqPair
register pair, because SelectionDAG doesn't care that much about
register classes if it can avoid doing so.
The main change to existing code is the reorganisation of
tryReadRegister and tryWriteRegister to try to keep the string parsing
code separate from the instruction creating code.
This also includes the changes to clang to define and use the ACLE
feature macro named `__ARM_FEATURE_SYSREG128`.
Contributors:
Sam Elliott
Lucas Prates
Differential Revision: https://reviews.llvm.org/D139086
P1787: //CWG600 is resolved by explaining that accessibility affects naming a member in the sense of the ODR.//
Wording: see changes to [class.access] p1 and p4.
Additional references: [[ http://eel.is/c++draft/basic.def.odr#8.sentence-2 | basic.def.odr/8 ]]: //A function is odr-used if it is named by a potentially-evaluated expression or conversion.//
Reviewed By: #clang-language-wg, aaron.ballman
Differential Revision: https://reviews.llvm.org/D139173
P1787: //CWG554 is resolved by using the word “scope” instead of “declarative region”, consistent with its very common use in phrases like “namespace scope”.//
Reviewed By: #clang-language-wg, cor3ntin, aaron.ballman, shafik
Differential Revision: https://reviews.llvm.org/D139172
P1787: //CWG405 is resolved by stating that argument-dependent lookup (sometimes) occurs after an ordinary unqualified lookup (making statements like “finding a variable prevents argument-dependent lookup” formally correct).//
Wording: see changes to [basic.lookup.argdep] p1 and p3
This issue seems a duplicate of CWG218, even though it is not officially recognized. A part of a test for CWG218 is reused here, adding cross-references.
Reviewed By: #clang-language-wg, aaron.ballman
Differential Revision: https://reviews.llvm.org/D139095
P1787: // [[ https://wg21.link/cwg952 | CWG952 ]] is resolved by refining the definition of “naming class” per Richard’s suggestion in [[ https://lists.isocpp.org/core/2020/09/9963.php | “CWG1621 and [class.static/2”]].//
Wording:
- [class.static]/2 removed;
- [class.access.base]/5 rephrased.
Currently behavior is the following: unqualified names undergo //unqualified name lookup// [1], which perform //unqualified search// in immediate scope [2]. This scope is the scope the definition of //naming class// [3] refers to. `A::I` is not //accessible// when named in classes `C` and `D` per [3]. In particular, the last item regarding base class ([class.access.base]/5.4) is not applicable, because class `A` is not //accessible// in both classes `C` and `D` per [4].
References:
1. [[ https://eel.is/c++draft/basic.lookup#unqual-4.sentence-2 | basic.lookup.unqual/4 ]]
2. [[ https://eel.is/c++draft/basic.lookup#unqual-3 | basic.lookup.unqual/3 ]]
3. [[ https://eel.is/c++draft/class.access#base-5.sentence-4 | class.access.base/5 ]]
4. [[ https://eel.is/c++draft/class.access#base-4 | class.access.base/4 ]]
Reviewed By: #clang-language-wg, erichkeane, aaron.ballman
Differential Revision: https://reviews.llvm.org/D139326
The BracketAlignmentStyle BAS_BlockIndent was forcing breaks before a
closing right parenthesis yielding strange-looking results in case of
code structures that have a left parens immediately following a right
parens ")(" such as is seen with indirect function calls via function
pointers and with type casting.
Fixes 57250.
Fixes 58496.
Differential Revision: https://reviews.llvm.org/D137762
Msan needs noundef consistency between interface and implementation. If
we call C++ from C we can have noundef on C++ side, and no noundef on
caller C side, noundef implementation will not set TLS for return value,
no noundef caller will expect it. Then we have false reports in msan.
The workaround could be set TLS to zero even for noundef return values.
However if we do that always it will increase binary size by about 10%.
If we do that selectively we need to handle "address is taken"
functions, any non local functions, and probably all function which have
musttail callers. Which is still a lot.
The existing implementation of HasStrictReturn refers to C standard as
the reason not enforcing noundef. I believe it applies only to the case
when return statement is omitted. Testing on Google codebase I never see
such cases, however I've see tens of cases where C code returns actual
uninitialized variables, but we ignore that it because of "omitted
return" case.
So this patch will:
1. fix false-positives with TLS missmatch.
2. detect bugs returning uninitialized variables for C as well.
3. report "omitted return" cases stricter than C, which is already a
warning and very likely a bug in a code anyway.
Reviewed By: kda
Differential Revision: https://reviews.llvm.org/D139296
