| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
/llvm-project/clang/examples/LLVMPrintFunctionNames/LLVMPrintFunctionNames.cpp:36:20:
error: cannot use incomplete type 'llvm::Module' as a range
for (auto &F : M)
^
|
|
This patch removes LLDB from a list of projects that are excluded from
building and testing on pre-merge CI on Linux.
Windows environment needs to be prepared in order to test LLDB
(https://github.com/llvm/llvm-project/pull/94208#issuecomment-2146256857),
but we don't have enough maintenance resources to do that at the moment.
Because LLDB has been in the list of projects that need to be tested on
Clang changes, this PR make this happen on Linux. This seems to be the
consensus in the discussion of this PR.
|
|
(NFC)
/llvm-project/clang/examples/LLVMPrintFunctionNames/LLVMPrintFunctionNames.cpp:33:28: error: unused variable 'key' [-Werror,-Wunused-variable]
static llvm::AnalysisKey key;
^
1 error generated.
|
|
|
|
This amends 0ce056a814f8dbfd8d9b7720ce1df489c6ba5ddb and fixes an
example that was not built locally for me.
|
|
This patch adds the Parse and Sema support for RegularKeyword attributes,
following on from a previous patch that added Attr.td support.
The patch is quite large. However, nothing outside the tests is
specific to the first RegularKeyword attribute (__arm_streaming).
The patch should therefore be a one-off, up-front cost. Other
attributes just need an entry in Attr.td and the usual Sema support.
The approach taken in the patch is that the keywords can be used with
any language version. If standard attributes were added in language
version Y, the keyword rules for version X<Y are the same as they were
for version Y (to the extent possible). Any extensions beyond Y are
handled in the same way for both keywords and attributes. This ensures
that existing C++11 successors like C++17 are not treated differently
from versions that have yet to be defined.
Some notes on the implementation:
* The patch emits errors rather than warnings for diagnostics that
relate to keywords.
* Where possible, the patch drops “attribute” from diagnostics
relating to keywords.
* One exception to the previous point is that warnings about C++
extensions do still mention attributes. The use there seemed OK
since the diagnostics are noting a change in the production rules.
* If a diagnostic string needs to be different for keywords and
attributes, the patch standardizes on passing the attribute/
name/token followed by 0 for attributes and 1 for keywords.
* Although the patch updates warn_attribute_wrong_decl_type_str,
warn_attribute_wrong_decl_type, and warn_attribute_wrong_decl_type,
only the error forms of these strings are used for keywords.
* I couldn't trigger the warnings in checkUnusedDeclAttributes,
even for existing attributes. An assert on the warnings caused
no failures in the testsuite. I think in practice all standard
attributes would be diagnosed before this.
* The patch drops a call to standardAttributesAllowed in
ParseFunctionDeclarator. This is because MaybeParseCXX11Attributes
checks the same thing itself, where appropriate.
* The new tests are based on c2x-attributes.c and
cxx0x-attributes.cpp. The C++ test also incorporates a version of
cxx11-base-spec-attributes.cpp. The FIXMEs are carried across from
the originals.
Differential Revision: https://reviews.llvm.org/D148702
|
|
When using attributes by plugins (both in clang and clang-tidy) the
preprocessor functions `__has_attribute`, `__has_c_attribute`,
`__has_cpp_attribute` still returned 0.
That problem is fixed by having the "hasAttribute" function also check
if any of the plugins provide that attribute.
This also adds C2x spelling to the example plugin for attributes so that
`__has_c_attribute` can be tested.
Differential Revision: https://reviews.llvm.org/D144405
|
|
The clang-analyzer plugins are not linked to a particular tool, so they
can only be compiled if plugins are broadly supported. We could opt
instead to decide whether to link them to specifically against clang or
with undefined symbols, depending on the value of LLVM_ENABLE_PLUGINS,
but we do not currently expect there to be a use case for that rather
niche configuration.
Differential Revision: https://reviews.llvm.org/D119591
|
|
Ensure CLANG_PLUGIN_SUPPORT is compatible with llvm_add_library.
Fixes an issue noted in D111100.
Differential Revision: https://reviews.llvm.org/D119199
|
|
From GCC's manpage:
-fplugin-arg-name-key=value
Define an argument called key with a value of value for the
plugin called name.
Since we don't have a key-value pair similar to gcc's plugin_argument
struct, simply accept key=value here anyway and pass it along as-is to
plugins.
This translates to the already existing '-plugin-arg-pluginname arg'
that clang cc1 accepts.
There is an ambiguity here because in clang, both the plugin name
as well as the option name can contain dashes, so when e.g. passing
-fplugin-arg-foo-bar-foo
it is not clear whether the plugin is foo-bar and the option is foo,
or the plugin is foo and the option is bar-foo. GCC solves this by
interpreting all dashes as part of the option name. So dashes can't be
part of the plugin name in this case.
Differential Revision: https://reviews.llvm.org/D113250
|
|
Many thanks to @thakis for pointing this out.
That commit should have been a part of https://reviews.llvm.org/D107049
|
|
Original commit message: "
Original commit message: "
Original commit message: "
Original commit message:"
The current infrastructure in lib/Interpreter has a tool, clang-repl, very
similar to clang-interpreter which also allows incremental compilation.
This patch moves clang-interpreter as a test case and drops it as conditionally
built example as we already have clang-repl in place.
"
This patch also ignores ppc due to missing weak symbol for __gxx_personality_v0
which may be a feature request for the jit infrastructure. Also, adds a missing
build system dependency to the orc jit.
"
Additionally, this patch defines a custom exception type and thus avoids the
requirement to include header <exception>, making it easier to deploy across
systems without standard location of the c++ headers.
"
This patch also works around PR49692 and finds a way to use llvm::consumeError
in rtti mode.
"
This patch also checks if stl is built with rtti.
Differential revision: https://reviews.llvm.org/D107049
|
|
Currently we have a way to run a plugin if specified on the command line
after the main action, and ways to unconditionally run the plugin before
or after the main action, but no way to run a plugin if specified on the
command line before the main action.
This introduces the missing option.
This is helpful because -clear-ast-before-backend clears the AST before
codegen, while some plugins may want access to the AST.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D112096
|
|
This reverts commit 1dba6b37bdc70210f75a480eff3715ebe1f1d8be.
Reverting because the ClangReplInterpreterExceptionTests test fails on
our builders with this patch.
|
|
Original commit message: "
Original commit message: "
Original commit message:"
The current infrastructure in lib/Interpreter has a tool, clang-repl, very
similar to clang-interpreter which also allows incremental compilation.
This patch moves clang-interpreter as a test case and drops it as conditionally
built example as we already have clang-repl in place.
Differential revision: https://reviews.llvm.org/D107049
"
This patch also ignores ppc due to missing weak symbol for __gxx_personality_v0
which may be a feature request for the jit infrastructure. Also, adds a missing
build system dependency to the orc jit.
"
Additionally, this patch defines a custom exception type and thus avoids the
requirement to include header <exception>, making it easier to deploy across
systems without standard location of the c++ headers.
"
This patch also works around PR49692 and finds a way to use llvm::consumeError
in rtti mode.
Differential revision: https://reviews.llvm.org/D107049
|
|
This reverts commit 6fe2beba7d2a41964af658c8c59dd172683ef739 which fails on
clang-hexagon-elf
|
|
Original commit message: "
Original commit message:"
The current infrastructure in lib/Interpreter has a tool, clang-repl, very
similar to clang-interpreter which also allows incremental compilation.
This patch moves clang-interpreter as a test case and drops it as conditionally
built example as we already have clang-repl in place.
Differential revision: https://reviews.llvm.org/D107049
"
This patch also ignores ppc due to missing weak symbol for __gxx_personality_v0
which may be a feature request for the jit infrastructure. Also, adds a missing
build system dependency to the orc jit.
"
Additionally, this patch defines a custom exception type and thus avoids the
requirement to include header <exception>, making it easier to deploy across
systems without standard location of the c++ headers.
Differential revision: https://reviews.llvm.org/D107049
|
|
This reverts commit f0514a4d26100239088f08d618f2ba100f59958e.
Test fails on macOS: https://reviews.llvm.org/D107049#2976603
|
|
Original commit message:"
The current infrastructure in lib/Interpreter has a tool, clang-repl, very
similar to clang-interpreter which also allows incremental compilation.
This patch moves clang-interpreter as a test case and drops it as conditionally
built example as we already have clang-repl in place.
Differential revision: https://reviews.llvm.org/D107049
"
This patch also ignores ppc due to missing weak symbol for __gxx_personality_v0
which may be a feature request for the jit infrastructure. Also, adds a missing
build system dependency to the orc jit.
|
|
This reverts commit 319ce98011742141dad8dd95a2f9de9c0449be5c because it fails
on various platforms.
|
|
The current infrastructure in lib/Interpreter has a tool, clang-repl, very
similar to clang-interpreter which also allows incremental compilation.
This patch moves clang-interpreter as a test case and drops it as conditionally
built example as we already have clang-repl in place.
Differential revision: https://reviews.llvm.org/D107049
|
|
|
|
Make the example compile and the test case pass.
|
|
If a virtual method is marked as call_super, the
override method must call it, simpler feature like @CallSuper
in Android Java.
|
|
|
|
0aec49c8531bc5282b095730d34681455826bc2c
|
|
Seems '${cmake_2_8_12_PRIVATE}' was removed a long time ago, so it should
be just PRIVATE keyword here.
Reviewed By: john.brawn
Differential Revision: https://reviews.llvm.org/D86091
|
|
Set the right target name in clang/examples/Attribute.
Add a missing dependency in the TableGen GlobalISel sublibrary.
Skip building the Bye pass plugin example on windows; plugins
that should have undefined symbols that are found in the host
process aren't supported on windows - this matches what was done
for a unit test in bc8e44218810c0db6328b9809c959ceb7d43e3f5.
|
|
Gets rid of a 150k static initializer (Release clang)
|
|
Differential Revision: https://reviews.llvm.org/D31343
|
|
|
|
|
|
The examples are easy to miss.
|
|
|
|
This should fix the build failure on llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast.
llvm-svn: 370151
|
|
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368942
|
|
llvm-svn: 368778
|
|
This will remove the ORCv1 deprecation warnings.
llvm-svn: 366511
|
|
Summary:
Setting CLANG_LINK_CLANG_DYLIB=ON causes clang tools to link against
libclang_shared.so instead of the individual component libraries.
Reviewers: mgorny, beanz, smeenai, phosek, sylvestre.ledru
Subscribers: arphaman, cfe-commits, llvm-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63503
llvm-svn: 365092
|
|
Currently, a pragma AST node's recorded location starts at the
namespace token (such as `omp` in the case of OpenMP) after the
`#pragma` token, and the `#pragma` location isn't available. However,
the `#pragma` location can be useful when, for example, rewriting a
directive using Clang's Rewrite facility.
This patch makes `#pragma` locations available in any `PragmaHandler`
but it doesn't yet make use of them.
This patch also uses the new `struct PragmaIntroducer` to simplify
`Preprocessor::HandlePragmaDirective`. It doesn't do the same for
`PPCallbacks::PragmaDirective` because that changes the API documented
in `clang-tools-extra/docs/pp-trace.rst`, and I'm not sure about
backward compatibility guarantees there.
Reviewed By: ABataev, lebedev.ri, aaron.ballman
Differential Revision: https://reviews.llvm.org/D61643
llvm-svn: 361335
|
|
Buildbots complained that they couldn't find the newly added plugins.
The solution was to move the check-clang cmake target closer to the bottom of
the file, after the new dependencies are added.
Differential Revision: https://reviews.llvm.org/D59464
llvm-svn: 360891
|
|
Buildbots don't seem to find the new plugin.
llvm-svn: 360805
|
|
Also, I moved the existing analyzer plugin to test/ as well, in order not to
give the illusion that the analyzer supports plugins -- it's capable of handling
them, but does not _support_ them.
Differential Revision: https://reviews.llvm.org/D59464
llvm-svn: 360799
|
|
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
llvm-svn: 355340
|
|
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
This was removed from llvm in r349839.
llvm-svn: 349840
|
|
llvm-svn: 349816
|
|
llvm-svn: 349279
|
|
llvm-svn: 349278
|
|
llvm-svn: 347194
|
