Adds `--product-name=` flag to the clang driver. This gets forwarded to
cc1 only when we are performing a ExtractAPI Action. This is used to
populate the `name` field of the module object in the generated SymbolGraph.
Differential Revision: https://reviews.llvm.org/D122141
-fsplit-machine-functions is an optimization in codegen phase. when -flto is use, clang generate IR bitcode in .o files, and linker will call into these codegen optimization passes. Current clang driver doesn't pass this option to linker when both -fsplit-machine-functions and -flto are used, so the optimization is silently ignored. My fix generates linker option -plugin-opt=-split-machine-functions for this case. It allows the linker to pass "split-machine-functions" to code generator to turn on that optimization. It works for both gold and lld.
Reviewed By: hoy, wenlei
Differential Revision: https://reviews.llvm.org/D121969
In D92191, a bunch of test cases were added to check `clang-scan-deps` works in `clang-cl` mode as well.
We don't need to duplicate all test cases, though. Testing the few special cases we have in `clang-scan-deps` for `clang-cl` should be good enough:
1. Deducing output path (and therefore target name in our make output).
2. Ignoring `-Xclang` arguments in step 1.
3. Deducing resource directory by invoking the compiler executuable.
This test de-duplicates the extra clang-cl test cases.
Reviewed By: dexonsmith, saudi
Differential Revision: https://reviews.llvm.org/D121812
This patch gets rid of the ridiculous relative path we use to invoke the `module-deps-to-rsp.py` script and creates proper lit substitution, cleaning up the tests.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D121525
* Check for warnings instead of using -Werror, to avoid masking the
type of diagnostic emitted
* use different -verify labels instead of using conditional
compilation of diagnostic checks
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D122265
This patch extends the support for C/C++ operators for SVE
types to allow one of the arguments to be a scalar, in which
case a vector splat is performed.
Differential Revision: https://reviews.llvm.org/D121829
`HeaderSearch` currently assumes `LookupFileCache` is eventually populated in `LookupFile`. However, that's not always the case with `-fms-compatibility` and its early returns.
This patch adds a defensive check that the iterator pulled out of the cache is actually valid before using it.
(This bug was introduced in D119721. Before that, the cache was initialized to `0` - essentially the `search_dir_begin()` iterator.)
Reviewed By: dexonsmith, erichkeane
Differential Revision: https://reviews.llvm.org/D122237
This change fixes a crash in RangedConstraintManager.cpp:assumeSym due to an
unhandled BO_Div case.
clang: <root>clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp:51:
virtual clang::ento::ProgramStateRef
clang::ento::RangedConstraintManager::assumeSym(clang::ento::ProgramStateRef,
clang::ento::SymbolRef, bool):
Assertion `BinaryOperator::isComparisonOp(Op)' failed.
Reviewed By: NoQ
Differential Revision: https://reviews.llvm.org/D122277
This reverts commit 56d46b36fc.
The LIT test SemaCXX/attr-trivial-abi.cpp is failing with 32bit build on
Windows. All the lines with the ifdef WIN32 are asserting but they are
not expected to. It looks like the LIT test was not tested on a 32bit
build of the compiler.
The -mbranch-protection definition in Options.td was not given a Group,
so this was causing clang to emit a -Wunused-command-line-argument
warning when this flag was passed to the linker driver. This was a
problem, because some build systems, like cmake, automatically pass the
C flags to the linker. Therefore, any program that was compiled with
-Werror and -mbranch-protection would fail to link with the error:
argument unused during compilation: '-mbranch-protection=standard' [-Werror,-Wunused-command-line-argument]
Reviewed By: vhscampos
Differential Revision: https://reviews.llvm.org/D121983
GCC supports power-of-2 size structures for the arguments. Clang supports fewer than GCC. But Clang always crashes for the unsupported cases.
This patch adds sema checks to do the diagnosts to solve these crashes.
Reviewed By: jyu2
Differential Revision: https://reviews.llvm.org/D107141
- The name SymbolGraph is inappropriate and confusing for the new library
for clang-extract-api. Refactor and rename things to make it clear that
ExtractAPI is the core functionality and SymbolGraph is one serializer
for the API information.
- Add documentation comments to ExtractAPI classes and methods to improve
readability and clearness of the ExtractAPI work.
Differential Revision: https://reviews.llvm.org/D122160
Allow goto, labelled statements as well as `static`, `thread_local`, and
non-literal variables in `constexpr` functions.
As specified. for all of the above (except labelled statements) constant
evaluation of the construct still fails.
For `constexpr` bodies, the proposal is implemented with diagnostics as
a language extension in older language modes. For determination of
whether a lambda body satisfies the requirements for a constexpr
function, the proposal is implemented only in C++2b mode to retain the
semantics of older modes for programs conforming to them.
Reviewed By: aaron.ballman, hubert.reinterpretcast, erichkeane
Differential Revision: https://reviews.llvm.org/D111400
These diagnostics were added to a diagnostic group, but that diagnostic
group was not under -Wgnu. I've now split them into their own
diagnostic group that is added both to the original group (so user's
currently opting in or out of these should not see a change) and under
the -Wgnu group so that -Wno-gnu can be used to disable all GNU
extension diagnostics. This fixes Issue 54444.
intrinsics.
Those operations are updated under a tail agnostic policy, but they
could have mask agnostic or undisturbed.
Reviewed By: rogfer01
Differential Revision: https://reviews.llvm.org/D120228
@mgehre-amd pointed out the following post-commit review feedback on
the changes in 8cba72177dcd8de5d37177dbaf2347e5c1f0f1e8:
As an example, the paper says 3wb /* Yields an _BitInt(3); two value
bits, one sign bit */.
So I would expect that 0xFwb gives _BitInt(5); four value bits, one
sign bit, but with this implementation I get _BitInt(2).
This is because ResultVal as 4 bits, and getMinSignedBits() inteprets
it as negative and thus says that 1 bit is enough to represent -1.
This corrects the behavior for calculating the bit-width and adds some
test coverage.
Usages of makeNull need to be deprecated in favor of makeNullWithWidth
for architectures where the pointer size should not be assumed. This can
occur when pointer sizes can be of different sizes, depending on address
space for example. See https://reviews.llvm.org/D118050 as an example.
This was uncovered initially in a downstream compiler project, and
tested through those systems tests.
steakhal performed systems testing across a large set of open source
projects.
Co-authored-by: steakhal
Resolves: https://github.com/llvm/llvm-project/issues/53664
Reviewed By: NoQ, steakhal
Differential Revision: https://reviews.llvm.org/D119601
This error was found when analyzing MySQL with CTU enabled.
When there are space characters in the lookup name, the current
delimiter searching strategy will make the file path wrongly parsed.
And when two lookup names have the same prefix before their first space
characters, a 'multiple definitions' error will be wrongly reported.
e.g. The lookup names for the two lambda exprs in the test case are
`c:@S@G@F@G#@Sa@F@operator int (*)(char)#1` and
`c:@S@G@F@G#@Sa@F@operator bool (*)(char)#1` respectively. And their
prefixes are both `c:@S@G@F@G#@Sa@F@operator` when using the first space
character as the delimiter.
Solving the problem by adding a length for the lookup name, making the
index items in the format of `<USR-Length>:<USR File> <Path>`.
---
In the test case of this patch, we found that it will trigger a "triple
mismatch" warning when using `clang -cc1` to analyze the source file
with CTU using the on-demand-parsing strategy in Darwin systems. And
this problem is also encountered in D75665, which is the patch
introducing the on-demand parsing strategy.
We temporarily bypass this problem by using the loading-ast-file
strategy.
Refer to the [discourse topic](https://discourse.llvm.org/t/60762) for
more details.
Differential Revision: https://reviews.llvm.org/D102669
This test assumes that the driver will set -object_path_lto linker
flag and it requests the platform linker with -fuse-ld=. When lld is
used as the host linker, the host linker version is unset and so
Clang won't set -object_path_lto since that flag is set conditionally
only when linker version is at least 116. We set the linker version
explicitly to make sure that -object_path_lto is set. That approach
is already used elsewhere in the test.
Differential Revision: https://reviews.llvm.org/D122110
For the following code,
void test() {
volatile int j = 0;
for (int i = 0; i < 1000; i++)
j += 1;
return;
}
If compiled with
clang -g -Wall -Werror -S -emit-llvm test.c
we will see the following error:
test.c:2:6: error: variable 'j' set but not used [-Werror,-Wunused-but-set-variable]
volatile int j = 0;
^
This is not quite right since 'j' is indeed used due to '+=' operator.
gcc doesn't emit error either in this case.
Also if we change 'j += 1' to 'j++', the warning will disappear
with latest clang.
Note that clang will issue the warning if the volatile declaration
involves only simple assignment (var = ...).
To fix the issue, in function MaybeDecrementCount(), if the
operator is a compound assignment (i.e., +=, -=, etc.) and the
variable is volatile, the count for RefsMinusAssignments will be
decremented, similar to 'j++' case.
Differential Revision: https://reviews.llvm.org/D121715
clang -extract-api should accept multiple headers and forward them to a
single CC1 instance. This change introduces a new ExtractAPIJobAction.
Currently API Extraction is done during the Precompile phase as this is
the current phase that matches the requirements the most. Adding a new
phase would need to change some logic in how phases are scheduled. If
the headers scheduled for API extraction are of different types the
driver emits a diagnostic.
Differential Revision: https://reviews.llvm.org/D121936
Full-expressions are Sema-generated implicit nodes that cover
constant-expressions and expressions-with-cleanup for temporaries.
Ignore those as part of implicit-ignore, and also remove too-aggressive
IgnoreImplicit (which includes nested ImplicitCastExprs, for example)
on unpacked sub-expressions.
Add some unittests to demonstrate that RecursiveASTVisitor sees through
ConstantExpr nodes correctly.
Adjust cxx2a-consteval test to cover diagnostics for nested consteval
expressions that were previously missed.
Fixes bug #53044.
Tests must not include headers from the host system.
It looks like the include wasn't needed for anything, so just remove it.
This makes check-clang work in a `git bash` launched from a cmd.exe
that isn't an MSVC shell (that is, %INCLUDE% isn't set).
Previously, OpenMP variant declarations for a function declaration that included
the 'cpu_dispatch', 'cpu_specific', or 'target' attributes was diagnosed, but
one with the 'target_clones' attribute was not. Now fixed.
Reviewed By: erichkeane, jdoerfert
Differential Revision: https://reviews.llvm.org/D121963
This change extends the existing diagnostic tests for OpenMP variant
declarations to cover diagnostics for declarations that include
multiversion function attributes. The new tests demonstrate a missing
check for the 'target_clones' attribute.
Reviewed By: erichkeane, jdoerfert
Differential Revision: https://reviews.llvm.org/D121962
Previously, an attempt to declare an overload of a multiversion function
in C was not properly diagnosed. In some cases, diagnostics were simply
missing. In other cases the following assertion failure occured...
```
Assertion `(Previous.empty() || llvm::any_of(Previous, [](const NamedDecl *ND) { return ND->hasAttr(); })) && "Non-redecls shouldn't happen without overloadable present"' failed.
```
... or the following diagnostic was spuriously issued.
```
error: at most one overload for a given name may lack the 'overloadable' attribute
```
The diagnostics issued in some cases could be improved. When the function
type of a redeclaration does not match the prior declaration, it would be
preferable to diagnose the type mismatch before diagnosing mismatched
attributes. Diagnostics are also missing for some cases.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D121959
This change adds test cases to validate diagnostics for overloaded sets
that contain declarations of multiversion functions. Many of the added test
cases exercise declarations that are intended to be valid. Others are
intended to be valid if and when restrictions on multiversion functions
being declared with the overloadable attribute are lifted.
Several of the new test cases currently trigger the following assertion
failure in SemaDecl.cpp; the relevant test is therefore marked as an
expected failure pending a fix.
```
Assertion `(Previous.empty() || llvm::any_of(Previous, [](const NamedDecl *ND) { return ND->hasAttr(); })) && "Non-redecls shouldn't happen without overloadable present"' failed.
```
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D121954
The EmitLoadOfPointer() call already specified the right pointer
type, but it did not match the Address we're loading from, so we
need to insert a bitcast first.
%S refers to the directory of %s, not to the cwd. This is mostly
handled correctly, but update_cc_test_checks.py used the wrong
path for non-FileCheck RUN lines.
Reapplying this with a fix for an update_cc_test_checks test that
was based on cwd semantics.
Partially fixes PR24883.
The patch sets Reference bit while instantiating a typedef if it
previously was found referenced.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D114382
Rather than using a dummy void pointer type, we should specify the
correct private type and perform the bitcast beforehand rather than
afterwards. This way, the Address will have correct alignment
information.
This is a follow up to 565603cc94,
which made macOS the default target OS for `-arch arm64` when
running on an Apple Silicon Mac. Now it'll be the default when
running on an Intel Mac too.
clang/test/Driver/apple-arm64-arch.c was a bit odd before: it was added
for the above commit, but tested the inverse behaviour and XFAIL'ed on
Apple Silicon. This inverts it to the (new) behaviour (that's now
correct regardless) and removes the XFAIL.
Radar-Id: rdar://90500294
https://reviews.llvm.org/D23944 implemented the #pragma intrinsic from
MSVC. This causes the statement #pragma intrinsic(cpuid) to fail [0]
on Clang because cpuid is currently implemented in intrin.h instead
of a Clang builtin. Reimplementing cpuid (as well as it's releated
function, cpuidex) should resolve this.
[0]: https://crbug.com/1279344
Differential revision: https://reviews.llvm.org/D121653
The ppc64be bot emits the dtor metadata first for some reason. We should
investigate this or make the _cc_ update script able to use variables
instead of fixed numbers (e.g., !1). The IR update script does that
already.
__builtin_memcpy_inline doesn't use the usual builtin argument validation code,
so it crashed when receiving wrong number of argument. Add the missing validation
check.
Open issue: https://github.com/llvm/llvm-project/issues/52949
Reviewed By: gchatelet
Differential Revision: https://reviews.llvm.org/D121965
Committed by gchatelet on behalf of "Roy Jacobson <roi.jacobson1@gmail.com>"
Rather than specifying a dummy type in EmitLoadOfPointer() and
then casting it to the correct one, we should instead specify the
correct type and cast beforehand. Otherwise the computed alignment
will be incorrect.
This adds support for multiple attributes in `#pragma clang attribute push`, for example:
```
```
or
```
```
Related attributes can now be applied with a single pragma, which makes it harder for developers to make an accidental error later when editing the code.
rdar://78269653
Differential Revision: https://reviews.llvm.org/D121283
PowerPC is lacking tests checking `_Atomic` alignment in cfe. Adding these tests since we're going to make change to align with gcc on Linux.
Reviewed By: hubert.reinterpretcast, jsji
Differential Revision: https://reviews.llvm.org/D121441
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.
Differential Revision: https://reviews.llvm.org/D115907
Summary:
Specifically, for trap handling, for targets that do not support getDoorbellID,
we load the queue_ptr from the implicit kernarg, and move queue_ptr to s[0:1].
To get aperture bases when targets do not have aperture registers, we load
private_base or shared_base directly from the implicit kernarg. In clang, we use
implicitarg_ptr + offsets to implement __builtin_amdgcn_workgroup_size_{xyz}.
Reviewers: arsenm, sameerds, yaxunl
Differential Revision: https://reviews.llvm.org/D120265
FLT_EVAL_METHOD tells the user the precision at which, temporary results
are evaluated but when fast-math is enabled, the numeric values are not
guaranteed to match the source semantics, so the eval-method is
meaningless.
For example, the expression `x + y + z` has as source semantics `(x + y)
+ z`. FLT_EVAL_METHOD is telling the user at which precision `(x + y)`
is evaluated. With fast-math enable the compiler can choose to
evaluate the expression as `(y + z) + x`.
The correct behavior is to set the FLT_EVAL_METHOD to `-1` to tell the
user that the precision of the intermediate values is unknow. This
patch is doing that.
Differential Revision: https://reviews.llvm.org/D121122
Currently we allow half types in vectors if the scalar Zfh extension
is enabled. This behavior is not inline with the vector spec. For f32
and f64 types, the Zve32f, Zve64f, Zve64d, and V explicitly control
the availablity of floating point types in vectors.
In order to make our compiler compliant, we either need to remove all support
for half in vectors or we need an extension to control it.
Draft spec here https://github.com/riscv/riscv-v-spec/pull/780
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D121345
If we are equality comparing an FP literal with a value cast from a type
where the literal can't be represented, that's known true or false and
probably a programmer error.
Fixes issue #54222.
https://github.com/llvm/llvm-project/issues/54222
Note - I added the optimizer change with:
9397bdc67e
...and as discussed in the post-commit comments, that transform might be
too dangerous without this warning in place, so it was reverted to allow
this change first.
Differential Revision: https://reviews.llvm.org/D121306
Poison trivial class members one-by-one in the reverse order of their
construction, instead of all-at-once at the very end.
For example, in the following code access to `x` from `~B` will
produce an undefined value.
struct A {
struct B b;
int x;
};
Reviewed By: kda
Differential Revision: https://reviews.llvm.org/D119600
-fsanitize-memory-use-after-dtor detects memory access after a
subobject is destroyed but its memory is not yet deallocated.
This is done by poisoning each object memory near the end of its destructor.
Subobjects (members and base classes) do this in their respective
destructors, and the parent class does the same for its members with
trivial destructors.
Inexplicably, base classes with trivial destructors are not handled at
all. This change fixes this oversight by adding the base class poisoning logic
to the parent class destructor.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D119300
This is a preliminary patch ahead of D119792 (I'll rebase that one on top of this).
This shows what Clang's _current_ behaviour is for calculating NRVO in various
common cases. Then, in D119792 (and future patches), I'll be able to demostrate
exactly how LLVM IR for each of these cases changes.
Reviewed By: Quuxplusone
Differential Revision: https://reviews.llvm.org/D119927
The clang/SymbolGraph/global_record.c test case explicitly diffs the
clang version in use, which causes failures. Fix the issue by normalize
the `generator` field before checking the output.
Add facilities for extract-api:
- Structs/classes to hold collected API information: `APIRecord`, `API`
- Structs/classes for API information:
- `AvailabilityInfo`: aggregated availbility information
- `DeclarationFragments`: declaration fragments
- `DeclarationFragmentsBuilder`: helper class to build declaration
fragments for various types/declarations
- `FunctionSignature`: function signature
- Serialization: `Serializer`
- Add output file for `ExtractAPIAction`
- Refactor `clang::RawComment::getFormattedText` to provide an
additional `getFormattedLines` for a more detailed view of comment lines
used for the SymbolGraph format
Add support for global records (global variables and functions)
- Add `GlobalRecord` based on `APIRecord` to store global records'
information
- Implement `VisitVarDecl` and `VisitFunctionDecl` in `ExtractAPIVisitor` to
collect information
- Implement serialization for global records
- Add test case for global records
Differential Revision: https://reviews.llvm.org/D119479
In AMD GPU device code the globals are in AS(1). Before, we crashed if
the global was a structure. Now we simply cast away the AS before we
generate the code to initialize the global.
Differential Revision: https://reviews.llvm.org/D121837
Includes verifier changes checking the elementtype, clang codegen
changes to emit the elementtype, and ISel changes using the elementtype.
Basically the same as D120527.
Reviewed By: #opaque-pointers, nikic
Differential Revision: https://reviews.llvm.org/D121847
Fix the instruction names to match the WebAssembly spec:
- `i32x4.trunc_sat_zero_f64x2_{s,u}` => `i32x4.trunc_sat_f64x2_{s,u}_zero`
- `f32x4.demote_zero_f64x2` => `f32x4.demote_f64x2_zero`
Also rename related things like intrinsics, builtins, and test functions to
match.
Reviewed By: aheejin
Differential Revision: https://reviews.llvm.org/D121661
Current ASTContext.getAttributedType() takes attribute kind,
ModifiedType and EquivType as the hash to decide whether an AST node
has been generated or note. But this is not enough for btf_type_tag
as the attribute might have the same ModifiedType and EquivType, but
still have different string associated with attribute.
For example, for a data structure like below,
struct map_value {
int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *a;
int __attribute__((btf_type_tag("tag2"))) __attribute__((btf_type_tag("tag4"))) *b;
};
The current ASTContext.getAttributedType() will produce
an AST similar to below:
struct map_value {
int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *a;
int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *b;
};
and this is incorrect.
It is very difficult to use the current AttributedType as it is hard to
get the tag information. To fix the problem, this patch introduced
BTFTagAttributedType which is similar to AttributedType
in many ways but with an additional BTFTypeTagAttr. The tag itself can
be retrieved with BTFTypeTagAttr.
With the new BTFTagAttributed type, the debuginfo code can be greatly
simplified compared to previous TypeLoc based approach.
Differential Revision: https://reviews.llvm.org/D120296
Add the rest of intrinsics to clang except intrinsics using vector mask
registers.
Reviewed By: simoll
Differential Revision: https://reviews.llvm.org/D121586
CT_Dependent
When compile following code without -std=c++17, clang will abort by
llvm_unreachable:
class A {
public:
static const char X;
};
const char A::X = 0;
template<typename U> void func() noexcept(U::X);
template<class... B, char x>
void foo(void(B...) noexcept(x)) {}
void bar()
{
foo(func<A>);
}
So, my solution is to let EST_Uninstantiated in
FunctionProtoType::canThrow return CT_Dependent
Differential Revision: https://reviews.llvm.org/D121498
The code for traversing precompiled dependencies is somewhat complicated and contains a dangling iterator bug.
This patch simplifies the code and fixes the bug.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D121533
When pruning header search paths (to reduce the number of modules we need to build explicitly), we can't prune the search paths used in (transitive) dependencies of a module. Otherwise, we could end up with either of the following dependency graphs:
```
X:<hash1> -> Y:<hash2>
X:<hash1> -> Y:<hash3>
```
depending on the search paths of the translation unit we discovered `X` and `Y` from.
This patch fixes that.
Depends on D121295.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D121303
To reduce the number of modules we build in explicit builds (which use strict context hash), we prune unused header search paths. This essentially merges parts of the dependency graph.
Determining whether a search path was used to discover a module (through implicit module maps) proved to be somewhat complicated. Initial support landed in D102923, while D113676 attempts to fix some bugs.
However, now that we don't use implicit module maps in explicit builds (since D120465), we don't need to consider such search paths as used anymore. Modules are no longer discovered through the header search mechanism, so we can drop such search paths (provided they are not needed for other reasons).
This patch removes whatever support for detecting such usage we had, since it's buggy and not required anymore.
Depends on D120465.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D121295
This is the `ext_vector_type` alternative to D81083.
This patch extends Clang to allow 'bool' as a valid vector element type
(attribute ext_vector_type) in C/C++.
This is intended as the canonical type for SIMD masks and facilitates
clean vector intrinsic declarations. Vectors of i1 are supported on IR
level and below down to many SIMD ISAs, such as AVX512, ARM SVE (fixed
vector length) and the VE target (NEC SX-Aurora TSUBASA).
The RFC on cfe-dev: https://lists.llvm.org/pipermail/cfe-dev/2020-May/065434.html
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D88905
This reverts commit 049f4e4eab.
The problem was a stray dependency in CLANG_TEST_DEPS which caused cmake
to fail if clang-pseudo wasn't built. This is now removed.
This should make clearer that:
- it's not part of clang proper
- there's no expectation to update it along with clang (beyond green tests)
- clang should not depend on it
This is intended to be expose a library, so unlike other tools has a split
between include/ and lib/.
The main renames are:
clang/lib/Tooling/Syntax/Pseudo/* => clang-tools-extra/pseudo/lib/*
clang/include/clang/Tooling/Syntax/Pseudo/* => clang-tools-extra/pseudo/include/clang-pseudo/*
clang/tools/clang/pseudo/* => clang-tools-extra/pseudo/tool/*
clang/test/Syntax/* => clang-tools-extra/pseudo/test/*
clang/unittests/Tooling/Syntax/Pseudo/* => clang-tools-extra/pseudo/unittests/*
#include "clang/Tooling/Syntax/Pseudo/*" => #include "clang-pseudo/*"
namespace clang::syntax::pseudo => namespace clang::pseudo
check-clang => check-clang-pseudo
clangToolingSyntaxPseudo => clangPseudo
The clang-pseudo and ClangPseudoTests binaries are not renamed.
See discussion around:
https://discourse.llvm.org/t/rfc-a-c-pseudo-parser-for-tooling/59217/50
Differential Revision: https://reviews.llvm.org/D121233
This fixes a bug that happens when using -fdebug-prefix-map to remap an
absolute path to a relative path. Since the path was absolute before
remapping, it is safe to assume that concatenating the remapped working
directory would be wrong.
This was originally submitted as https://reviews.llvm.org/D113718, but
reverted because when testing with dwarf 5 enabled, the tests were too
strict.
Differential Revision: https://reviews.llvm.org/D121663
function candidates
See: https://github.com/llvm/llvm-project/issues/54379
I tried to see if I can reuse ResolveAddressOfOverloadedFunction for
explicit function instantiation and so I managed to hit this ICE.
Bug was the diagnostic required an argument (%0) and specific code path
didn't pass an argument.
Differential Revision: https://reviews.llvm.org/D121646
GCC supports:
- `namespace <gnu attributes> identifier`
- `namespace identifier <gnu attributes>`
But clang supports only `namespace identifier <gnu attributes>` and diagnostics for `namespace <gnu attributes> identifier` case looks unclear:
Code:
```
namespace __attribute__((visibility("hidden"))) A
{
}
```
Diags:
```
test.cpp:1:49: error: expected identifier or '{'
namespace __attribute__((visibility("hidden"))) A
^
test.cpp:1:49: error: C++ requires a type specifier for all declarations
test.cpp:3:2: error: expected ';' after top level declarator
}
```
This patch adds support for `namespace <gnu attributes> identifier` and also forbids gnu attributes for nested namespaces (this already done for C++ attributes).
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D121245
Nick Desaulniers