Implement P2036R3.
Captured variables by copy (explicitely or not), are deduced
correctly at the point we know whether the lambda is mutable,
and ill-formed before that.
Up until now, the entire lambda declaration up to the start
of the body would be parsed in the parent scope, such that
captures would not be available to look up.
The scoping is changed to have an outer lambda scope,
followed by the lambda prototype and body.
The lambda scope is necessary because there may be a template scope
between the start of the lambda (to which we want to attach
the captured variable) and the prototype scope.
We also need to introduce a declaration context to attach the captured
variable to (and several parts of clang assume captures are handled from
the call operator context), before we know the type of the call operator.
The order of operations is as follow:
* Parse the init capture in the lambda's parent scope
* Introduce a lambda scope
* Create the lambda class and call operator
* Add the init captures to the call operator context and the lambda scope.
But the variables are not capured yet (because we don't know their type).
Instead, explicit captures are stored in a temporary map that
conserves the order of capture (for the purpose of having a stable order in the ast dumps).
* A flag is set on LambdaScopeInfo to indicate that we have not yet injected the captures.
* The parameters are parsed (in the parent context, as lambda mangling recurses in the parent context,
we couldn't mangle a lambda that is attached to the context of a lambda whose type is not yet known).
* The lambda qualifiers are parsed, at this point,
we can switch (for the second time) inside the lambda context,
unset the flag indicating that we have not parsed the lambda qualifiers,
record the lambda is mutable and capture the explicit variables.
* We can parse the rest of the lambda type, transform the lambda and call operator's types and also
transform the call operator to a template function decl where necessary.
At this point, both captures and parameters can be injected in the body's scope.
When trying to capture an implicit variable, if we are before the qualifiers of a lambda,
we need to remember that the variables are still in the parent's context (rather than in the call operator's).
This is a recommit of adff142dc2 after a fix in d8d793f29b
Reviewed By: aaron.ballman, #clang-language-wg, ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119136
Currently, when the framework is used with an analysis that does not override
`compareEquivalent`, it does not terminate for most loops. The root cause is the
interaction of (the default implementation of) environment comparison
(`compareEquivalent`) and the means by which locations and values are
allocated. Specifically, the creation of certain values (including: reference
and pointer values; merged values) results in allocations of fresh locations in
the environment. As a result, analysis of even trivial loop bodies produces
different (if isomorphic) environments, on identical inputs. At the same time,
the default analysis relies on strict equality (versus some relaxed notion of
equivalence). Together, when the analysis compares these isomorphic, yet
unequal, environments, to determine whether the successors of the given block
need to be (re)processed, the result is invariably "yes", thus preventing loop
analysis from reaching a fixed point.
There are many possible solutions to this problem, including equivalence that is
less than strict pointer equality (like structural equivalence) and/or the
introduction of an explicit widening operation. However, these solutions will
require care to be implemented correctly. While a high priority, it seems more
urgent that we fix the current default implentation to allow
termination. Therefore, this patch proposes, essentially, to change the default
comparison to trivally equate any two values. As a result, we can say precisely
that the analysis will process the loop exactly twice -- once to establish an
initial result state and the second to produce an updated result which will
(always) compare equal to the previous. While clearly unsound -- we are not
reaching a fix point of the transfer function, in practice, this level of
analysis will find many practical issues where a single iteration of the loop
impacts abstract program state.
Note, however, that the change to the default `merge` operation does not affect
soundness, because the framework already produces a fresh (sound) abstraction of
the value when the two values are distinct. The previous setting was overly
conservative.
Differential Revision: https://reviews.llvm.org/D123586
This reverts commit adff142dc2.
This broke clang bootstrap: it made existing C++ code in LLVM invalid:
llvm/include/llvm/CodeGen/LiveInterval.h:630:53: error: captured variable 'Idx' cannot appear here
[=](std::remove_reference_t<decltype(*Idx)> V,
^
We were generating wrong code for cxx20-consteval-crash.cpp: instead of
loading a value of a variable, we were using its address as the
initializer.
Found while adding code to verify the size of constant initializers.
Differential Revision: https://reviews.llvm.org/D123648
Implement P2036R3.
Captured variables by copy (explicitely or not), are deduced
correctly at the point we know whether the lambda is mutable,
and ill-formed before that.
Up until now, the entire lambda declaration up to the start of the body would be parsed in the parent scope, such that capture would not be available to look up.
The scoping is changed to have an outer lambda scope, followed by the lambda prototype and body.
The lambda scope is necessary because there may be a template scope between the start of the lambda (to which we want to attach the captured variable) and the prototype scope.
We also need to introduce a declaration context to attach the captured variable to (and several parts of clang assume captures are handled from the call operator context), before we know the type of the call operator.
The order of operations is as follow:
* Parse the init capture in the lambda's parent scope
* Introduce a lambda scope
* Create the lambda class and call operator
* Add the init captures to the call operator context and the lambda scope. But the variables are not capured yet (because we don't know their type).
Instead, explicit captures are stored in a temporary map that conserves the order of capture (for the purpose of having a stable order in the ast dumps).
* A flag is set on LambdaScopeInfo to indicate that we have not yet injected the captures.
* The parameters are parsed (in the parent context, as lambda mangling recurses in the parent context, we couldn't mangle a lambda that is attached to the context of a lambda whose type is not yet known).
* The lambda qualifiers are parsed, at this point We can switch (for the second time) inside the lambda context, unset the flag indicating that we have not parsed the lambda qualifiers,
record the lambda is mutable and capture the explicit variables.
* We can parse the rest of the lambda type, transform the lambda and call operator's types and also transform the call operator to a template function decl where necessary.
At this point, both captures and parameters can be injected in the body's scope. When trying to capture an implicit variable, if we are before the qualifiers of a lambda, we need to remember that the variables are still in the parent's context (rather than in the call operator's).
Reviewed By: aaron.ballman, #clang-language-wg, ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119136
Currently, clang crashes with i386 target on the following code:
```
void f() {
f + 0xdead000000000000UL;
}
```
This problem is similar to the problem fixed in D104424, but that fix can't handle function pointer case, because `getTypeSizeInCharsIfKnown()` says that size is known and equal to 0 for function type.
This patch prevents bounds checking for function pointer, thus fixes the crash.
Fixes https://github.com/llvm/llvm-project/issues/50463
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D122748
Currently we emit an error in just about every case of conditionals
with a 'non simple' branch if treated as an LValue. This patch adds
support for the special case where this is an 'ignored' lvalue, which
permits the side effects from happening.
It also splits up the emit for conditional LValue in a way that should
be usable to handle simple assignment expressions in similar situations.
Differential Revision: https://reviews.llvm.org/D123680
For -fgpu-rdc, a host function may call an external kernel
which is defined in an archive of bitcode. Since this external
kernel is only referenced in host function, the device
bitcode does not contain reference to this external
kernel, then the linker will not try to resolve this external
kernel in the archive.
To fix this issue, host-used external kernels and device
variables are tracked. A global array containing pointers
to these external kernels and variables is emitted which
serves as an artificial references to the external kernels
and variables used by host.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D123441
We did not implement C99 6.7.5.3p15 fully in that we missed the rule
for compatible function types where a prior declaration has a prototype
and a subsequent definition (not just declaration) has an empty
identifier list or an identifier list with a mismatch in parameter
arity. This addresses that situation by issuing an error on code like:
void f(int);
void f() {} // type conflicts with previous declaration
(Note: we already diagnose the other type conflict situations
appropriately, this was the only situation we hadn't covered that I
could find.)
This patch adds support for inline assembly address operands using the "p"
constraint on X86 and SystemZ.
This was in fact broken on X86 (see example at
https://reviews.llvm.org/D110267, Nov 23).
These operands should probably be treated the same as memory operands by
CodeGenPrepare, which have been commented with "TODO" there.
Review: Xiang Zhang and Ulrich Weigand
Differential Revision: https://reviews.llvm.org/D122220
Support for generating LLVM BC files is added in Flang's compiler and
frontend drivers. This requires the `BitcodeWriterPass` pass to be run
on the input LLVM IR module and is implemented as a dedicated frontend
aciton. The new functionality as seen by the user (compiler driver):
```
flang-new -c -emit-llvm file.90
```
or (frontend driver):
```
flang-new -fc1 -emit-llvm-bc file.f90
```
The new behaviour is consistent with `clang` and `clang -cc1`.
Differential Revision: https://reviews.llvm.org/D123211
This removes the -flegacy-pass-manager and
-fno-experimental-new-pass-manager options, and the corresponding
support code in BackendUtil. The -fno-legacy-pass-manager and
-fexperimental-new-pass-manager options are retained as no-ops.
Differential Revision: https://reviews.llvm.org/D123609
This bug can cause that more import errors are generated than necessary
and many objects fail to import. Chance of an invalid AST after these
imports increases.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D122525
The function is moved from clangFrontend to clangBasic, which allows tools
(e.g. clang pseudoparser) which don't depend on clangFrontend to use.
Differential Revision: https://reviews.llvm.org/D121375
LTO objects might compiled with different `mbranch-protection` flags which will cause an error in the linker.
Such a setup is allowed in the normal build with this change that is possible.
Reviewed By: pcc
Differential Revision: https://reviews.llvm.org/D123493
I found this when reading the codes. I think it makes sense to reduce
the space for TemplateParmPosition. It is hard to image the depth of
template parameter is larger than 2^20 and the index is larger than
2^12. So I think the patch might be reasonable.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D123298
This patch changes `EmitPPCBuiltinExpr` in `CGBuiltin.cpp` to remove
the loop at the beginning of the function that emits the arguments and
to delay emitting the arguments until inside the switch statement. These
changes will put `EmitPPCBuiltinExpr` in line with the strategy of the
target independent function `EmitBuiltinExpr`. Also, this patch
ensures that arguments are only emitted once.
Tests that included builtins affected by these changes have been
modified to match expected behaviour.
Reviewed By: #powerpc, nemanjai, amyk
Differential Revision: https://reviews.llvm.org/D121637
It (introduced by 556d713c70) appears to be
related to the removed dragonegg project. In addition, the feature was a bit
misnamed and may lur users to unnecessarily use it.
Fix path replacement in sed (properly this time) using lit
regex_replacement.
Differential Revision: https://reviews.llvm.org/D123526
Co-authored-by: Michele Scandale <michele.scandale@gmail.com>
Co-authored-by: Zixu Wang <9819235+zixu-w@users.noreply.github.com>
It breaks arm build, there is no free bit for the extra
UsingShadowDecl in TemplateName::StorageType.
Reverting it to build the buildbot back until we comeup with a fix.
This reverts commit 5a5be4044f.
This is the template version of https://reviews.llvm.org/D114251.
This patch introduces a new template name kind (UsingTemplateName). The
UsingTemplateName stores the found using-shadow decl (and underlying
template can be retrieved from the using-shadow decl). With the new
template name, we can be able to find the using decl that a template
typeloc (e.g. TemplateSpecializationTypeLoc) found its underlying template,
which is useful for tooling use cases (include cleaner etc).
This patch merely focuses on adding the node to the AST.
Next steps:
- support using-decl in qualified template name;
- update the clangd and other tools to use this new node;
- add ast matchers for matching different kinds of template names;
Differential Revision: https://reviews.llvm.org/D123127
According to CWG 1394 and C++20 [dcl.fct.def.general]p2,
Clang should not diagnose incomplete types if function body is "= delete;".
For example:
```
struct Incomplete;
Incomplete f(Incomplete) = delete; // well-formed
```
Also close https://github.com/llvm/llvm-project/issues/52802
Differential Revision: https://reviews.llvm.org/D122981
If the `ExternalFS` has already remapped to an external path then
`RedirectingFileSystem` should not change it to the originally provided
path. This fixes the original path always being used if multiple VFS
overlays were provided and the path wasn't found in the highest (ie.
first in the chain).
For now this is accomplished through the use of a new
`ExposesExternalVFSPath` field on `vfs::Status`. This flag is true when
the `Status` has an external path that's different from its virtual
path, ie. the contained path is the external path. See the plan in
`FileManager::getFileRef` for where this is going - eventually we won't
need `IsVFSMapped` any more and all returned paths should be virtual.
Resolves rdar://90578880 and llvm-project#53306.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D123398
Summary:
A previous patch added the option to use the default pipeline when
perfomring LTO rather than the regular LTO pipeline. This greatly
improved performance regressions we were observing with the LTO
pipeline. However, this should not be used if the user explicitly
disables optimizations as the default pipeline expects some
optimizatoins to be perfomed.
- Split GlobalRecord into two distinct types to be able to introduce
has_function_signature type trait.
- Add has_function_signature type trait.
- Serialize function signatures as part of serializeAPIRecord for
records that are known to have a function signature.
Differential Revision: https://reviews.llvm.org/D123304
InstantiateDefaultCtorDefaultArgs() is supposed to mark default
constructor args as odr-used, since those args will be used when
emitting the constructor closure.
However, constexpr vars were not getting odr-used since
DoMarkVarDeclReferenced() defers them in MaybeODRUseExprs, and the code
was calling CleanupVarDeclMarking() which discarded those uses instead
of processing them.
(This came up in Chromium, crbug.com/1312086)
Differential revision: https://reviews.llvm.org/D123405
This takes the AARCH64_ARCH_EXT_NAME in AArch64TargetParser.def and uses
it to generate all the "if bit is set add this feature name" code.
Which gives us a bunch that we were missing. I've updated testing
to include those and reordered them to match the order in the .def.
The final part of the test will catch any missing extensions if
we somehow manage to not generate an if block for them.
This has changed the order of cc1's "-target-feature" output so I've
updated some tests in clang to reflect that.
Reviewed By: tmatheson
Differential Revision: https://reviews.llvm.org/D123296
This removes support for the legacy pass manager in llvm-lto and
llvm-lto2. In this case I've dropped the use-new-pm option entirely,
as I don't think this is considered part of the public interface.
This also makes -debug-pass-manager work with llvm-lto, because
that was needed to migrate some tests to NewPM.
Differential Revision: https://reviews.llvm.org/D123376
This commit contains a refactoring that merges AVRRelaxMemOperations
into AVRExpandPseudoInsts, so that we have a single place in code that
expands the STDWPtrQRr opcode.
Seizing the day, I've also fixed a couple of potential bugs with our
previous implementation (e.g. when the destination register was killed,
the previous implementation would try to .addDef() that killed
register, crashing LLVM in the process - that's fixed now, as proved by
the test).
Reviewed By: benshi001
Differential Revision: https://reviews.llvm.org/D122533
The Randstruct feature is a compile-time hardening technique that
randomizes the field layout for designated structures of a code base.
Admittedly, this is mostly useful for closed-source releases of code,
since the randomization seed would need to be available for public and
open source applications.
Why implement it? This patch set enhances Clang’s feature parity with
that of GCC which already has the Randstruct feature. It's used by the
Linux kernel in certain structures to help thwart attacks that depend on
structure layouts in memory.
This patch set is a from-scratch reimplementation of the Randstruct
feature that was originally ported to GCC. The patches for the GCC
implementation can be found here:
https://www.openwall.com/lists/kernel-hardening/2017/04/06/14
Link: https://lists.llvm.org/pipermail/cfe-dev/2019-March/061607.html
Co-authored-by: Cole Nixon <nixontcole@gmail.com>
Co-authored-by: Connor Kuehl <cipkuehl@gmail.com>
Co-authored-by: James Foster <jafosterja@gmail.com>
Co-authored-by: Jeff Takahashi <jeffrey.takahashi@gmail.com>
Co-authored-by: Jordan Cantrell <jordan.cantrell@mail.com>
Co-authored-by: Nikk Forbus <nicholas.forbus@gmail.com>
Co-authored-by: Tim Pugh <nwtpugh@gmail.com>
Co-authored-by: Bill Wendling <isanbard@gmail.com>
Signed-off-by: Bill Wendling <isanbard@gmail.com>
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D121556
In theory, constructors can take arguments when called via .init_array
where at least glibc passes in (argc, argv, envp). This isn't used in
the generated code and if it was, the first argument should be an
integer, not a pointer. For destructors registered via atexit, the
function should never take an argument.
Differential Revision: https://reviews.llvm.org/D123370
(With C++ exceptions, `clang++ --target=mips64{,el}-linux-gnu -fpie -pie
-fuse-ld=lld` has link errors (lld does not implement some strange R_MIPS_64
.eh_frame handling in GNU ld). However, sanitizer-x86_64-linux-qemu used this to
build ScudoUnitTests. Pined ScudoUnitTests to -no-pie.)
Default the option introduced in D113372 to ON to match all(?) major Linux
distros. This matches GCC and improves consistency with Android and linux-musl
which always default to PIE.
Note: CLANG_DEFAULT_PIE_ON_LINUX may be removed in the future.
Differential Revision: https://reviews.llvm.org/D120305
This reverts commit 3f0587d0c6.
Not all tests pass after a few rounds of fixes.
I spot one failure that std::shuffle (potentially different results with
different STL implementations) was misused and replaced it with llvm::shuffle,
but there appears to be another failure in a Windows build.
The latest failure is reported on https://reviews.llvm.org/D121556#3440383
Make 16-byte atomic type aligned to 16-byte on PPC64, thus consistent with GCC. Also enable inlining 16-byte atomics on non-AIX targets on PPC64.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D122377
This is an attempt to fix a test failure on one of the buildbot Windows
machines. It also turns all of the "ASSERT_" macros into "EXPECT_" to
catch all other failures.
Link: https://lab.llvm.org/buildbot/#/builders/216/builds/2647
Functions without prototypes in C (also known as K&R C functions) were
introduced into C89 as a deprecated feature and C2x is now reclaiming
that syntax space with different semantics. However, Clang's
-Wstrict-prototypes diagnostic is off-by-default (even in pedantic
mode) and does not suffice to warn users about issues in their code.
This patch changes the behavior of -Wstrict-prototypes to only diagnose
declarations and definitions which are not going to change behavior in
C2x mode, and enables the diagnostic in -pedantic mode. The diagnostic
is now specifically about the fact that the feature is deprecated.
It also adds -Wdeprecated-non-prototype, which is grouped under
-Wstrict-prototypes and diagnoses declarations or definitions which
will change behavior in C2x mode. This diagnostic is enabled by default
because the risk is higher for the user to continue to use the
deprecated feature.
Differential Revision: https://reviews.llvm.org/D122895
The Randstruct feature is a compile-time hardening technique that
randomizes the field layout for designated structures of a code base.
Admittedly, this is mostly useful for closed-source releases of code,
since the randomization seed would need to be available for public and
open source applications.
Why implement it? This patch set enhances Clang’s feature parity with
that of GCC which already has the Randstruct feature. It's used by the
Linux kernel in certain structures to help thwart attacks that depend on
structure layouts in memory.
This patch set is a from-scratch reimplementation of the Randstruct
feature that was originally ported to GCC. The patches for the GCC
implementation can be found here:
https://www.openwall.com/lists/kernel-hardening/2017/04/06/14
Link: https://lists.llvm.org/pipermail/cfe-dev/2019-March/061607.html
Co-authored-by: Cole Nixon <nixontcole@gmail.com>
Co-authored-by: Connor Kuehl <cipkuehl@gmail.com>
Co-authored-by: James Foster <jafosterja@gmail.com>
Co-authored-by: Jeff Takahashi <jeffrey.takahashi@gmail.com>
Co-authored-by: Jordan Cantrell <jordan.cantrell@mail.com>
Co-authored-by: Nikk Forbus <nicholas.forbus@gmail.com>
Co-authored-by: Tim Pugh <nwtpugh@gmail.com>
Co-authored-by: Bill Wendling <isanbard@gmail.com>
Signed-off-by: Bill Wendling <isanbard@gmail.com>
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D121556
Currently, enablement of heap MTE on Android is specified by an ELF note, which
signals to the linker to enable heap MTE. This change allows
-fsanitize=memtag-heap to synthesize these notes, rather than adding them
through the build system. We need to extend this feature to also signal the
linker to do special work for MTE globals (in future) and MTE stack (currently
implemented in the toolchain, but not implemented in the loader).
Current Android uses a non-backwards-compatible ELF note, called
".note.android.memtag". Stack MTE is an ABI break anyway, so we don't mind that
we won't be able to run executables with stack MTE on Android 11/12 devices.
The current expectation is to support the verbiage used by Android, in
that "SYNC" means MTE Synchronous mode, and "ASYNC" effectively means
"fast", using the Kernel auto-upgrade feature that allows
hardware-specific and core-specific configuration as to whether "ASYNC"
would end up being Asynchronous, Asymmetric, or Synchronous on that
particular core, whichever has a reasonable performance delta. Of
course, this is platform and loader-specific.
Differential Revision: https://reviews.llvm.org/D118948
The LANGOPT macro allows you to specify a default value for the
langauge option. However, it's expected that these values be constant
rather than depending on other language options (because the
constructor setting the default values does not know the language mode
at the time it's being constructed).
Some of our language options were abusing this and passing in other
language mode options which were then set correctly by other parts of
frontend initialization. This removes the default values for the
language options, and then ensures they're consistently set from the
same place when setting language standard defaults.
Summary:
The `-fopenmp-target-new-runtime` flag has not been used for awhile. It
was present in a previous release so we shouldn't remove it for
backwards compatibility, but we shouldn't have documentation or a help
message for it.
This was skipping specific lifetime + bitcast patterns, but with
opaque pointers the bitcast will not be present, and we did not
perform this fold.
Instead skip over lifetime.end and bitcasts generally, without
trying to correlate them.
I recently evaluated ~150 of bug reports on open source projects relating to my
GSoC'19 project, which was about tracking control dependencies that were
relevant to a bug report.
Here is what I found: when the condition is a function call, the extra notes
were almost always unimportant, and often times intrusive:
void f(int *x) {
x = nullptr;
if (alwaysTrue()) // We don't need a whole lot of explanation
// here, the function name is good enough.
*x = 5;
}
It almost always boiled down to a few "Returning null pointer, which participates
in a condition later", or similar notes. I struggled to find a single case
where the notes revealed anything interesting or some previously hidden
correlation, which is kind of the point of condition tracking.
This patch checks whether the condition is a function call, and if so, bails
out.
The argument against the patch is the popular feedback we hear from some of our
users, namely that they can never have too much information. I was specifically
fishing for examples that display best that my contribution did more good than
harm, so admittedly I set the bar high, and one can argue that there can be
non-trivial trickery inside functions, and function names may not be that
descriptive.
My argument for the patch is all those reports that got longer without any
notable improvement in the report intelligibility. I think the few exceptional
cases where this patch would remove notable information are an acceptable
sacrifice in favor of more reports being leaner.
Differential Revision: https://reviews.llvm.org/D116597
This adjusts the handling for:
export module M;
export namespace {};
export namespace N {};
export using namespace N;
In the first case, we were allowing empty anonymous namespaces
as part of an extension allowing empty top-level entities, but that seems
inappropriate in this case, since the linkage would be internal for the
anonymous namespace. We now report an error for this.
The second case was producing a warning diagnostic that this was
accepted as an extension - however the C++20 standard does allow this
as well-formed.
In the third case we keep the current practice that this is accepted with a
warning (as an extension). The C++20 standard says it's an error.
We also ensure that using decls are only applied to items with external linkage.
This adjusts error messages for exports involving redeclarations in modules to
be more specific about the reason that the decl has been rejected.
Differential Revision: https://reviews.llvm.org/D122119
When an inline builtin declaration is shadowed by an actual declaration, we must
reference the actual declaration, even if it's not the last, following GCC
behavior.
This fixes#54715
Differential Revision: https://reviews.llvm.org/D123308
The dependency scanner can reuse single FileManager instance across multiple translation units. This may lead to non-deterministic output depending on which TU gets processed first.
One of the problems is that Clang uses DirectoryEntry::getName in the header search algorithm. This function returns the path that was first used to construct the (shared) entry in FileManager. Using DirectoryEntryRef::getName instead preserves the case as it was spelled out for the current "get directory entry" request.
rdar://90647508
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D123229
Reland Note: We've resolve the circular dependency issue on llvm/lib/Support and
llvm/TableGen.
Differential Revision: https://reviews.llvm.org/D121984
Since the NTTP may need to be cast to the type when rebuilding the name,
check that the type can be rebuilt when determining whether a template
name can be simplified.
This patch changes `EmitPPCBuiltinExpr` in `CGBuiltin.cpp` to remove
the loop at the beginning of the function that emits the arguments and
to delay emitting the arguments until inside the switch statement. These
changes will put `EmitPPCBuiltinExpr` in line with the strategy of the
target independent function `EmitBuiltinExpr`. Also, this patch
ensures that arguments are only emitted once.
Tests that included builtins affected by these changes have been
modified to match expected behaviour.
Reviewed By: #powerpc, nemanjai, amyk
Differential Revision: https://reviews.llvm.org/D121637
We aim at improving the readability and maintainability of Options.td,
and in particular its handling of 'Flags', by
- limiting the extent of 'let Flags = [...] in {'s, and
- adding closing comments to matching '}'s.
- being more consistent about empty lines around 'let Flags' and '}'.
More concretely,
- we do not let a 'let Flags' span across several headline comments.
When all 'def's in two consecutive headlines share the same flags,
we stil close and start a new 'let Flags' at the intermediate
headline.
- when a 'let Flags' span just one or two 'def's, set 'Flags' within
the 'def's instead.
- we remove nested 'let Flags'.
Note that nested 'let Flags' can be quite confusing, especially when
the outer was started long before the inner. Moving a 'def' out of the
inner 'let Flags' and setting 'Flags' within the 'def' will not have the
intended effect, as those flags will be overridden by the outer
'let Flags'.
Reviewed By: awarzynski, jansvoboda11, hans
Differential Revision: https://reviews.llvm.org/D123070
The code to check if the regular LTO summary should be emitted and to
add the corresponding module flags was duplicated in the
'EmitAssemblyHelper::EmitAssemblyWithLegacyPassManager' and
'EmitAssemblyHelper::RunOptimizationPipeline' methods.
In order to eliminate these code duplications, the
'EmitAssemblyHelper::shouldEmitRegularLTOSummary' method has been
extracted. The method returns a bool value, the value is 'true' if the
module summary should be emitted. The patch keeps the setting of the
module flags inline.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D123026
We should only process APIs declared in the command line inputs to avoid
drowning the ExtractAPI output with symbols the user doesn't care about.
This is achieved by keeping track of the provided input files and
checking that the associated Decl or Macro is declared in one of those files.
Differential Revision: https://reviews.llvm.org/D123148
There is a bug in `DeclarationFragments::appendSpace` where the space
character is added to a local copy of the last fragment.
Differential Revision: https://reviews.llvm.org/D123259
- isValid: FileManager only ever returns valid FileEntries (see next point)
- construction from outside FileManager (both FileEntry and DirectoryEntry).
It's not possible to create a useful FileEntry this way, there are no setters.
This was only used in FileEntryTest, added a friend to enable this.
A real constructor is cleaner but requires larger changes to FileManager.
Differential Revision: https://reviews.llvm.org/D123197
Internal symbol mangling is implementation-defined. We do not mangle
any module attachment, and this adds a test to verify that.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D123220
clang may throw the following warning:
include/clang/AST/DeclarationName.h:210:52: error: arithmetic between
different enumeration types ('clang::DeclarationName::StoredNameKind'
and 'clang::detail::DeclarationNameExtra::ExtraKind') is deprecated
when flags -Werror,-Wdeprecated-enum-enum-conversion are on.
This adds the `addEnumValues()` helper function to STLExtras.h to hide
the details of adding enumeration values together from two different
enumerations.
This was accidentally caught in an automated replacement. This
test is testing the -opaque-pointers flag itself, so we shouldn't
add -no-opaque-pointers here (though it doesn't hurt either).
Also drop the line testing the default, as the default is now
determined by a cmake option.
clang to emit DWARF information for global alias variable as
DW_TAG_imported_declaration. This change also handles nested
(recursive) imported declarations.
Reviewed by: dblaikie, aprantl
Differential Revision: https://reviews.llvm.org/D120989
This adds -no-opaque-pointers to clang tests whose output will
change when opaque pointers are enabled by default. This is
intended to be part of the migration approach described in
https://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322/9.
The patch has been produced by replacing %clang_cc1 with
%clang_cc1 -no-opaque-pointers for tests that fail with opaque
pointers enabled. Worth noting that this doesn't cover all tests,
there's a remaining ~40 tests not using %clang_cc1 that will need
a followup change.
Differential Revision: https://reviews.llvm.org/D123115
The error can be returned from the function, the problem written in comment before
does not exist. The same is done already in ASTImporter at various import failures.
After a declaration is created in an `ASTNodeImporter` import function
with `GetImportedOrCreateDecl`, that function registers it with
`MapImported`. At many places import errors can happen after this
and the error is returned. The same can be done in the place where
the in-class initializer is imported.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D122528
This option controls whether -opaque-pointers or -no-opaque-pointers
is the default. Once opaque pointers are enabled by default, this
will provide a simple way to temporarily opt-out of the change.
Differential Revision: https://reviews.llvm.org/D123122
(The upgrade of the ppc64le bot and D121257 have fixed compiler-rt failures. Tested by nemanjai.)
Default the option introduced in D113372 to ON to match all(?) major Linux
distros. This matches GCC and improves consistency with Android and linux-musl
which always default to PIE.
Note: CLANG_DEFAULT_PIE_ON_LINUX may be removed in the future.
Differential Revision: https://reviews.llvm.org/D120305
Add (partial) support for Objective-C category records in ExtractAPI.
The current ExtractAPI collects everything for an Objective-C category,
but not fully serialized in the SymbolGraphSerializer. Categories
extending external interfaces are disgarded during serialization, and
categories extending known interfaces are merged (all members surfaced)
into the interfaces.
Differential Revision: https://reviews.llvm.org/D122774
Typedef records consist of the symbol associated with the underlying
TypedefDecl and a SymbolReference to the underlying type. Additionally
typedefs for anonymous TagTypes use the typedef'd name as the symbol
name in their respective records and USRs. As a result the declaration
fragments for the anonymous TagType are those for the associated
typedef. This means that when the user is defining a typedef to a
typedef to a anonymous type, we use a reference the anonymous TagType
itself and do not emit the typedef to the anonymous type in the
generated symbol graph, including in the type destination of further
typedef symbol records.
Differential Revision: https://reviews.llvm.org/D123019
Note that the mangling has changed and the demangler's learnt a new
trick. Obviously dependent upon the mangler and demangler patches.
Reviewed By: bruno
Differential Revision: https://reviews.llvm.org/D123141
This includes:
- replacing "relationhips" with "relationships"
- emitting the "pathComponents" property on symbols
- emitting the "accessLevel" property on symbols
Differential Revision: https://reviews.llvm.org/D123045
Add specific dates and versions to note about source_location handling.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D123119
This simplifies completeness comparisons against OpenCLBuiltins.td and
also makes the header no longer "claim" the argument name identifiers.
Continues the direction set out in D119560.
Or rather, error out if it is set to something other than ON. This
removes the ability to enable the legacy pass manager by default,
but does not remove the ability to explicitly enable it through
various flags like -flegacy-pass-manager or -enable-new-pm=0.
I checked, and our test suite definitely doesn't pass with
LLVM_ENABLE_NEW_PASS_MANAGER=OFF anymore.
Differential Revision: https://reviews.llvm.org/D123126
Returning `std::array<uint8_t, N>` is better ergonomics for the hashing functions usage, instead of a `StringRef`:
* When returning `StringRef`, client code is "jumping through hoops" to do string manipulations instead of dealing with fixed array of bytes directly, which is more natural
* Returning `std::array<uint8_t, N>` avoids the need for the hasher classes to keep a field just for the purpose of wrapping it and returning it as a `StringRef`
As part of this patch also:
* Introduce `TruncatedBLAKE3` which is useful for using BLAKE3 as the hasher type for `HashBuilder` with non-default hash sizes.
* Make `MD5Result` inherit from `std::array<uint8_t, 16>` which improves & simplifies its API.
Differential Revision: https://reviews.llvm.org/D123100
Add CSKY target toolchains to support csky in linux and elf environment.
It can leverage the basic universal Linux toolchain for linux environment, and only add some compile or link parameters.
For elf environment, add a CSKYToolChain to support compile and link.
Also add some parameters into basic codebase of clang driver.
Differential Revision: https://reviews.llvm.org/D121445
Add support for builtin_[max|min] which has below prototype:
A builtin_max (A1, A2, A3, ...)
All arguments must have the same type; they must all be float, double, or long double.
Internally use SelectCC to get the result.
Reviewed By: qiucf
Differential Revision: https://reviews.llvm.org/D122478
As statement expression makes no sense in the default argument,
this patch tries to disable it in the all cases.
Please note that the statement expression is a GNU extension, which
means that Clang should be consistent with GCC. However, there's no
response from GCC devs since we have raised the issue for several weeks.
In this case, I think we can disallow statement expressions as a default
parameter in general for now, and relax the restriction if GCC folks
decide to retain the feature for functions but not lambdas in the
future.
Related discussion: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104765
Fixes https://github.com/llvm/llvm-project/issues/53488
Differential Revision: https://reviews.llvm.org/D119609
This change merges code for emit of target and target_clones multiversion
resolver functions and, in doing so, corrects handling of target_clones
functions that are declared but not defined. Previously, a use of such
a target_clones function would result in an attempted emit of an ifunc
that referenced an undefined resolver function. Ifunc references to
undefined resolver functions are not allowed and, when the LLVM verifier
is not disabled (via '-disable-llvm-verifier'), resulted in the verifier
issuing a "IFunc resolver must be a definition" error and aborting the
compilation. With this change, ifuncs and resolver function definitions
are always emitted for used target_clones functions regardless of whether
the target_clones function is defined (if the function is defined, then
the ifunc and resolver are emitted regardless of whether the function is
used).
This change has the side effect of causing target_clones variants and
resolver functions to be emitted in a different order than they were
previously. This is harmless and is reflected in the updated tests.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D122958
This change modifies CodeGenModule::emitMultiVersionFunctions() in preparation
for a change that will merge support for emitting target_clones resolvers into
this function. This change mostly serves to isolate indentation changes from
later behavior modifying changes.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D122957
Previously, GetOrCreateMultiVersionResolver() required the caller to provide
a GlobalDecl along with an llvm::type and FunctionDecl. The latter two can be
cheaply obtained from the first, and the llvm::type parameter is not always
used, so requiring the caller to provide them was unnecessary and created the
possibility that callers would pass an inconsistent set. This change simplifies
the interface to only require the GlobalDecl value.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D122956
This reverts commit 3fda0edc51, which
breaks crash reproducers in very specific circumstances. Specifically,
since crash reproducers have `UseExternalNames` set to false, the
`File->getFileEntry().getDir()->getName()` call in `DoFrameworkLookup`
would use the *cached* directory name instead of the directory of the
looked-up file.
The plan is to re-commit this patch but to *add*
`ExposesExternalVFSPath` rather than replace `IsVFSMapped`.
Differential Revision: https://reviews.llvm.org/D123103
A missing "break" in the initial implementation had us adding a
spurious "/usr/include" to the header search list. Later someone
introduced LLVM_FALLTHROUGH to prevent a warning. Replace this with
the correct "break" and make sure the extra directory isn't added to
the PS4 header search list.
Extend D120185 to also log the node being matched on in case of a crash.
This can help if a matcher is causing a crash or there are not enough interesting nodes bound.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D122529
This reverts commit 61d67c8eec.
This relands commit 6e33e45b94.
Fixing the build issue on 32bit machines due to not enough free bits in the PointerUnion.
The diagnostic is unreliable, and triggers even for dead uses of
hostcall that may exist when linking the device-libs at lower
optimization levels.
Eliminate the diagnostic, and directly document the limitation for
OpenCL before code object V5.
Make some NFC changes to clarify the related code in the
MetadataStreamer.
Add a clang test to tie OCL sources containing printf to the backend IR
tests for this situation.
Reviewed By: sameerds, arsenm, yaxunl
Differential Revision: https://reviews.llvm.org/D121951
Since enumerators may not be available in every translation unit they
can't be reliably used to name entities. (this also makes simplified
template name roundtripping infeasible - since the expected name could
only be rebuilt if the enumeration definition could be found (or only if
it couldn't be found, depending on the context of the original name))
Currently, clang-offload-bundler has -inputs and -outputs options that accept
values with comma as the delimiter. This causes issues with file paths
containing commas, which are valid file paths on Linux.
This add two new options -input and -output, which accept one single file,
and allow multiple instances. This allows arbitrary file paths. The old
-inputs and -outputs options will be kept for backward compatibility, but
are not allowed to be used with -input and -output options for simplicity.
In the future, -inputs and -outputs options will be phasing out.
RFC: https://discourse.llvm.org/t/rfc-adding-input-and-output-options-to-clang-offload-bundler/60049
Patch by: Siu Chi Chan
Reviewed by: Yaxun Liu
Differential Revision: https://reviews.llvm.org/D120662
Comparison operators on SVE types return a signed integer vector
of the same width as the incoming SVE type. This matches the existing
behaviour for NEON types.
Differential Revision: https://reviews.llvm.org/D122404
compiler is allowed to use optimizations that allow reassociation and
transformations that don’t guaranty accuracy.
For example (x+y)+z is transformed into x+(y+z) . Although
mathematically equivalent, these two expressions may not lead to the
same final result due to errors of summation.
Or x/x is transformed into 1.0 but x could be 0.0, INF or NaN. And so
this transformation also may not lead to the same final result.
Setting the eval method 'ffp-eval-method' or via '#pragma clang fp
eval_method' in this mode, doesn’t have any effect.
This patch adds code to warn the user of this.
Differential Revision: https://reviews.llvm.org/D122155
There doesn't seem to be any particular reason why these tests use
the driver interface rather than the cc1 interface, which is
typically used in CodeGen tests.
This fixes the situation where a undefining a not previously defined
macro resulted in a crash. Before trying to remove a definition from
PendingMacros we first check to see if the macro did indeed have a
previous definition.
Differential Revision: https://reviews.llvm.org/D123056
This allows both explicitly enabling and explicitly disabling
opaque pointers, in anticipation of the default switching at some
point.
This also slightly changes the rules by allowing calls if either
the opaque pointer mode has not yet been set (explicitly or
implicitly) or if the value remains unchanged.
This adds cc1 options for enabling and disabling opaque pointers
on the clang side. This is not super useful now (because
-mllvm -opaque-pointers and -Xclang -opaque-pointers have the same
visible effect) but will be important once opaque pointers are
enabled by default in clang. In that case, it will only be
possible to disable them using the cc1 -no-opaque-pointers option.
Differential Revision: https://reviews.llvm.org/D123034
Without the fix ivars with anonymous types can trigger errors like
> error: 'TestClass::structIvar' from module 'Target' is not present in definition of 'TestClass' provided earlier
> [...]
> note: declaration of 'structIvar' does not match
It happens because types of ivars from different modules are considered
to be different. And it is caused by not merging anonymous `TagDecl`
from different modules.
To fix that I've changed `serialization::needsAnonymousDeclarationNumber`
to handle anonymous `TagDecl` inside `ObjCInterfaceDecl`. But that's not
sufficient as C code inside `ObjCInterfaceDecl` doesn't use interface
decl as a decl context but switches to its parent (TranslationUnit in
most cases). I'm changing that to make `ObjCContainerDecl` the lexical
decl context but keeping the semantic decl context intact.
Test "check-dup-decls-inside-objc.m" doesn't reflect a change in
functionality but captures the existing behavior to prevent regressions.
rdar://85563013
Differential Revision: https://reviews.llvm.org/D118525
The tests are doing -verify and testing a diagnostic behavior, but that
behavior is changing. This ensures the tests continue to run and check
the diagnostic.
The behavior of the tests is expected to remain identical as before.
@thakis believes the problem was the lack of -n on my llvm-cxxfilt call,
so hopefully this is the only problem. Committing to see if this makes
all the buildbots happy.
AND the followups that fixed builds.
I attempted to get 'cute' and use llvm-cxxfilt to make the test look
nicer, but apparently some of the bots have a version of llvm-cxxfilt
that is not the in-tree one, so it fails to properly demangle the stuff.
I've disabled this "RUN" line.
This reverts commit 50186b63d1.
This patch adds basic modeling of `__builtin_expect`, just to propagate the
(first) argument, making the call transparent.
Driveby: adds tests for proper handling of other builtins.
Differential Revision: https://reviews.llvm.org/D122908
Few times in different methods of the EmitAssemblyHelper class the following
code snippet is used to get the TargetTriple and then use it's single method
to check some conditions:
TargetTriple(TheModule->getTargetTriple())
The parsing of a target triple string is not a trivial operation and it takes
time to repeat the parsing many times in different methods of the class and
even numerous times in one method just to call a getter
(llvm::Triple(TheModule->getTargetTriple()).getVendor()), for example.
The patch extracts the TargetTriple member of the EmitAssemblyHelper class to
parse the triple only once in the class' constructor.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D122587
As reported, using "-DTDIR=%t" with a path name of 'C:\Users\...' causes
a warning to be emitted about the use of \U without following hex digits.
Since the value is only required for the FileCheck cases resolve this by
omitting the -D from the compile lines.
As discussed in https://reviews.llvm.org/D120111, this patch proposes an
alternative implementation to avoid scanning feature list for
architecture version over and over again. The insertion position for
default extensions is also captured during this single scan of the
feature list.
Differential Revision: https://reviews.llvm.org/D120864
This implements minimum support in clang for default HBC/MOPS features
on v8.8-a/v9.3-a or later architectures.
Differential Revision: https://reviews.llvm.org/D120111
We have some discission in D99152 and llvm-dev and finially come up with
a solution to add amx specific cast intrinsics. We've support the
intrinsics in llvm IR. This patch is to replace bitcast with amx cast
intrinsics in code emitting in FE.
Differential Revision: https://reviews.llvm.org/D122567
We expect that `extern "C"` static functions to be usable in things like
inline assembly, as well as ifuncs:
See the bug report here: https://github.com/llvm/llvm-project/issues/54549
However, we were diagnosing this as 'not defined', because the
ifunc's attempt to look up its resolver would generate a declared IR
function.
Additionally, as background, the way we allow these static extern "C"
functions to work in inline assembly is by making an alias with the C
mangling in MOST situations to the version we emit with
internal-linkage/mangling.
The problem here was multi-fold: First- We generated the alias after the
ifunc was checked, so the function by that name didn't exist yet.
Second, the ifunc's generation caused a symbol to exist under the name
of the alias already (the declared function above), which suppressed the
alias generation.
This patch fixes all of this by moving the checking of ifuncs/CFE aliases
until AFTER we have generated the extern-C alias. Then, it does a
'fixup' around the GlobalIFunc to make sure we correct the reference.
Differential Revision: https://reviews.llvm.org/D122608
As reported in https://github.com/llvm/llvm-project/issues/54588
and discussed in https://github.com/itanium-cxx-abi/cxx-abi/issues/139
We are supposed to do a DFS, pre-order, decl-order search for a name for
the union in this case. Prevoiusly we crashed because the IdentiferInfo
pointer was nullptr, so this makes sure we have a name in the cases
described by the ABI.
I added an llvm-unreachable to cover an unexpected case at the end of
the new function with information/reference to the ABI in case we come
up with some way to get back to here.
Differential Revision: https://reviews.llvm.org/D122820
This patch extends the join logic for environments to explicitly handle
boolean values. It creates the disjunction of both source values, guarded by the
respective flow conditions from each input environment. This change allows the
framework to reason about boolean correlations across multiple branches (and
subsequent joins).
Differential Revision: https://reviews.llvm.org/D122838
Currently, the framework does not track derived class access to base
fields. This patch adds that support and a corresponding test.
Differential Revision: https://reviews.llvm.org/D122273
Summary:
Currently there is no option to configure the number of thin-backend
threads to use when performing thin-lto on the device, but we should
default to use all the threads rather than just one. In the future we
should use the same arguments that gold / lld use and parse it here.
Do import the definition of objects from a foreign translation unit if that's type is const and trivial.
Differential Revision: https://reviews.llvm.org/D122805
At present, we are generating wrong code for C++20 modules entities which
should have internal linkage. This is because we are assigning
'ModuleInternalLinkage' unconditionally to such entities. However this mode
is only applicable to the modules-ts.
This change makes the special linkage mode conditional on fmodules-ts and
adds a unit test to verify that we generate the correct linkage.
Currently, static variables and functions in module purview are emitted into
object files as external. On some platforms, lambdas are emitted as global
weak defintions (on Windows this causes a mangler crash).
Differential Revision: https://reviews.llvm.org/D122413
lexically contains a mention of the pack.
Systematically distinguish between syntactic and semantic references to
packs, especially when propagating dependence from a type into an
expression. We should consult the type-as-written when computing
syntactic dependence and should consult the semantic type when computing
semantic dependence.
Fixes#54402.
A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a prototype for the situations where the test is not specific to K&R C
declarations. e.g.,
void func();
becomes
void func(void);
Reimplements MisExpect diagnostics from D66324 to reconstruct its
original checking methodology only using MD_prof branch_weights
metadata.
New checks rely on 2 invariants:
1) For frontend instrumentation, MD_prof branch_weights will always be
populated before llvm.expect intrinsics are lowered.
2) for IR and sample profiling, llvm.expect intrinsics will always be
lowered before branch_weights are populated from the IR profiles.
These invariants allow the checking to assume how the existing branch
weights are populated depending on the profiling method used, and emit
the correct diagnostics. If these invariants are ever invalidated, the
MisExpect related checks would need to be updated, potentially by
re-introducing MD_misexpect metadata, and ensuring it always will be
transformed the same way as branch_weights in other optimization passes.
Frontend based profiling is now enabled without using LLVM Args, by
introducing a new CodeGen option, and checking if the -Wmisexpect flag
has been passed on the command line.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D115907
This adds diagnostics for conflicting attributes on the same
declarataion, conflicting attributes on a forward and final
declaration, and defines a more narrowly scoped HLSLEntry attribute
target.
Big shout out to @aaron.ballman for the great feedback and review on
this!
The memory_scope enum is not available before OpenCL 2.0, so ensure
the sub_group_barrier overload with a memory_scope argument is
restricted to OpenCL 2.0 and above. This is already the case in
opencl-c.h.
Fixes the issue revealed by https://reviews.llvm.org/D120254
Reported-by: Harald van Dijk (hvdijk)
This change fixes an assert that occurs in the SMT layer when refuting a
finding that uses pointers of two different sizes. This was found in a
downstream build that supports two different pointer sizes, The CString
Checker was attempting to compute an overlap for the 'to' and 'from'
pointers, where the pointers were of different sizes.
In the downstream case where this was found, a specialized memcpy
routine patterned after memcpy_special is used. The analyzer core hits
on this builtin because it matches the 'memcpy' portion of that builtin.
This cannot be duplicated in the upstream test since there are no
specialized builtins that match that pattern, but the case does
reproduce in the accompanying LIT test case. The amdgcn target was used
for this reproducer. See the documentation for AMDGPU address spaces here
https://llvm.org/docs/AMDGPUUsage.html#address-spaces.
The assert seen is:
`*Solver->getSort(LHS) == *Solver->getSort(RHS) && "AST's must have the same sort!"'
Ack to steakhal for reviewing the fix, and creating the test case.
Reviewed By: steakhal
Differential Revision: https://reviews.llvm.org/D118050
Previously, if a `#pragma clang assume_nonnull begin` was at the
end of a premable with a `#pragma clang assume_nonnull end` at the
end of the main file, clang would diagnose an unterminated begin in
the preamble and an unbalanced end in the main file.
With this change, those errors no longer occur and the case above is
now properly handled. I've added a corresponding test to clangd,
which makes use of preambles, in order to verify this works as
expected.
Differential Revision: https://reviews.llvm.org/D122179
This patch adds limited modeling of the `value_or` method. Specifically, when
used in a particular idiom in a comparison to implicitly check whether the
optional holds a value.
Differential Revision: https://reviews.llvm.org/D122231
--overlay-platform-toolchain inserts a whole new toolchain path with
higher priority than system default, which could be achieved by
composing smaller options. We need to figure out alternative solution
and what is missing among these basic options.
in filesystems
It is simpler to search for module unit by -fprebuilt-module-path
option. However, the separator ':' of partitions is not friendly.
According to the discussion in https://reviews.llvm.org/D118586, I think
we get consensus to use '-' as the separator instead. The '-' is the
choice of GCC too.
Previously I thought it would be better to add an option. But I feel it
is over-engineering now. Another reason here is that there are too many
options for modules (for clang module mainly) now. Given it is not bad
to use '-' when searching, I think it is acceptable to not add an
option.
Reviewed By: iains
Differential Revision: https://reviews.llvm.org/D120874
Beautify dump format, add indent for nested struct and struct members, also fix test cases in dump-struct-builtin.c
for example:
struct:
```
struct A {
int a;
struct B {
int b;
struct C {
struct D {
int d;
union E {
int x;
int y;
} e;
} d;
int c;
} c;
} b;
};
```
Before:
```
struct A {
int a = 0
struct B {
int b = 0
struct C {
struct D {
int d = 0
union E {
int x = 0
int y = 0
}
}
int c = 0
}
}
}
```
After:
```
struct A {
int a = 0
struct B {
int b = 0
struct C {
struct D {
int d = 0
union E {
int x = 0
int y = 0
}
}
int c = 0
}
}
}
```
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D122704
[clang-format] Indent import statements in JavaScript.
Take for example this piece of code found at
<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import>.
```
for (const link of document.querySelectorAll("nav > a")) {
link.addEventListener("click", e => {
e.preventDefault();
import('/modules/my-module.js')
.then(module => {
module.loadPageInto(main);
})
.catch(err => {
main.textContent = err.message;
});
});
}
```
Previously the import line would be unindented, looking like this.
```
for (const link of document.querySelectorAll("nav > a")) {
link.addEventListener("click", e => {
e.preventDefault();
import('/modules/my-module.js')
.then(module => {
module.loadPageInto(main);
})
.catch(err => {
main.textContent = err.message;
});
});
}
```
Actually we were going to fix this along with fixing Verilog import
statements. But the patch got too big.
Reviewed By: MyDeveloperDay, curdeius
Differential Revision: https://reviews.llvm.org/D121906
Updating the diagnostics as per the feedback on
https://reviews.llvm.org/D122627.
This change correctly handles missing argument lists, and changes the
subject for the `numthreads` attribute to be global functions.
I did not handle applying the attribute to template functions because
that currently fails parsing in a way that is consisetent with the
current DXC codebase (Microsoft attributes are not supported on
templates).
A future improvement to the diagnostic maybe warranted.
If the `ExternalFS` has already remapped a path then the
`RedirectingFileSystem` should not change it to the originally provided
path. This fixes the original path always being used if multiple VFS
overlays were provided and the path wasn't found in the highest (ie.
first in the chain).
This also renames `IsVFSMapped` to `ExposesExternalVFSPath` and only
sets it if `UseExternalName` is true. This flag then represents that the
`Status` has an external path that's different from its virtual path.
Right now the contained path is still the external path, but further PRs
will change this to *always* be the virtual path. Clients that need the
external can then request it specifically.
Note that even though `ExposesExternalVFSPath` isn't set for all
VFS-mapped paths, `IsVFSMapped` was only being used by a hack in
`FileManager` that was specific to module searching. In that case
`UseExternalNames` is always `true` and so that hack still applies.
Resolves rdar://90578880 and llvm-project#53306.
Differential Revision: https://reviews.llvm.org/D122549
To achieve this we hook into the preprocessor during the
ExtractAPIAction and record definitions for macros that don't get
undefined during preprocessing.
Make the API records a property of the action instead of the ASTVisitor
so that it can be accessed outside the AST visitation and push back
serialization to the end of the frontend action.
This will allow accessing and modifying the API records outside of the
ASTVisitor, which is a prerequisite for supporting macros.
Extend D120185 to also log the node being matched on in case of a crash.
This can help if a matcher is causing a crash or there are not enough interesting nodes bound.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D122529
Implement a demangleable strong ownership symbol mangling.
* The original module symbol mangling scheme turned out to be
undemangleable.
* The hoped-for C++17 compatibility of weak ownership turns out to be
fragile
* C++20 now has better ways of controlling C++17 compatibility
The issue is captured on the ABI list at:
https://github.com/itanium-cxx-abi/cxx-abi/issues/134
GCC implements this new mangling.
The old mangling is unceremoniously dropped. No backwards
compatibility, no deprectated old-mangling flag. It was always
labelled experimental. (Old and new manglings cannot be confused.)
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D122256
Index of vset/vget must be a constant integer and be
located in right range.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D122629
We started diagnosing this situation with a more clear diagnostic
message, but it was pointed out that unevaluated contexts don't really
have the undefined behavior property as there is no runtime access
involved.
This augments the changes in https://reviews.llvm.org/D122656 to not
diagnose in an unevaluated context.
This is an alternative to D122376. Rather than working around the
problem, this patch requires that struct return types in intrinsics
are anonymous/literal and adds auto-upgrade code to convert
existing uses of intrinsics with named struct types.
This ensures that the mapping between intrinsic name and
intrinsic function type is actually bijective, as it is supposed
to be.
This also fixes https://github.com/llvm/llvm-project/issues/37891.
Differential Revision: https://reviews.llvm.org/D122471
This reverts commit 10fd2822b7.
I have a better implementation for those operations without the
additional policy operand.
masked compare and vmsbf/vmsif/vmsof are always tail agnostic so we could
assume undef maskedoff is mask agnostic.
Differential Revision: https://reviews.llvm.org/D122455
Also, check that NRVO currently isn't performed in test25. The checks
were accidentally removed when https://reviews.llvm.org/D122425 disabled
inlining.
HLSL uses Microsoft-style attributes `[attr]`, which clang mostly
ignores. For HLSL we need to handle known Microsoft attributes, and to
maintain C/C++ as-is we ignore unknown attributes.
To utilize this new code path, this change adds the HLSL `numthreads`
attribute.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D122627
clang: <root>/clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:727:
void assertEqualBitWidths(clang::ento::ProgramStateRef,
clang::ento::Loc, clang::ento::Loc): Assertion `RhsBitwidth ==
LhsBitwidth && "RhsLoc and LhsLoc bitwidth must be same!"'
This change adjusts the bitwidth of the smaller operand for an evalBinOp
as a result of a comparison operation. This can occur in the specific
case represented by the test cases for a target with different pointer
sizes.
Reviewed By: NoQ
Differential Revision: https://reviews.llvm.org/D122513
Corentin Jabot