requested by client
This is a follow up to r319702 which records parsing invocations.
These files are not emitted by default, and the client has to specify the
invocation emission path first.
rdar://35322543
llvm-svn: 320085
Summary:
This enables us to use information in Preprocessor when handling symbol
occurrences.
Reviewers: arphaman, hokein
Reviewed By: hokein
Subscribers: malaperle, cfe-commits
Differential Revision: https://reviews.llvm.org/D40884
llvm-svn: 320030
This can be used by clients in conjunction with an offset returned by
e.g. clang_getFileLocation. Now those clients do not need to also
open/read the file.
Differential Revision: https://reviews.llvm.org/D40643
llvm-svn: 319881
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
Differential Revision: https://reviews.llvm.org/D40823
llvm-svn: 319840
Storing the contents of unsaved files is too expensive.
Instead a hash is stored with a record invocation. When a reproducer is
generated, Clang will compare the stored hashes to the new hashes to determine
if the contents of a file has changed. This way we'll know when a reproducer was
generated for a different source to the one that triggered the original crash.
rdar://35322543
llvm-svn: 319729
by client
This patch extends libclang by allowing it to record parsing operations to a
temporary JSON file. The file is deleted after parsing succeeds. When a crash
happens during parsing, the file is preserved and the client will be able to use
it to generate a reproducer for the crash.
These files are not emitted by default, and the client has to specify the
invocation emission path first.
rdar://35322543
Differential Revision: https://reviews.llvm.org/D40527
llvm-svn: 319702
Summary:
When 'buffer-file-name' is nil 'call-process-region' returned a segmentation fault error.
This was a problem when using clang-format-buffer on an orgmode source code editing buffer.
I fixed this problem by excluding the '-assume-filename' argument when 'buffer-file-name' is nil.
To make it a bit more flexible I also added an optional argument, 'assume-file-name', to specify an assume-filename that overrides 'buffer-file-name'.
Reviewers: klimek, djasper, phst, phi
Reviewed By: phst, phi
Subscribers: phi, jholewinski, mgorny, javed.absar, eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D37903
llvm-svn: 319621
Use this function to create the install targets rather than doing so
manually, which gains us the `-stripped` install targets to perform
stripped installations.
Differential Revision: https://reviews.llvm.org/D40675
llvm-svn: 319489
These functions were defined as static members of TemplateSpecializationType.
Now they are moved to namespace level. Previously there were different
implementations for lists containing TemplateArgument and TemplateArgumentLoc,
now these implementations share the same code.
This change is a result of refactoring patch D40508. NFC.
llvm-svn: 319178
Enabled crash recovery for some libclang operations on a calling thread even
when LIBCLANG_NOTHREAD is specified.
Previously it would only run under crash recovery if LIBCLANG_NOTHREAD is not
set. Moved handling of LIBCLANG_NOTHREAD env variable into RunSafely from its
call sites.
llvm-svn: 318142
CLion's Sax parser threw this error:
Failed to parse clang-format XML replacements. Input: <?xml version='1.0'?>
<replacements xml:space='preserve' incomplete_format='true' line=89>
[...]
[org.xml.sax.SAXParseException; lineNumber: 2; columnNumber: 66; Open quote is expected for attribute "line" associated with an element type "replacements".]
Patch by Justine Tunney (jart@google.com)!
llvm-svn: 317205
`LLVM_DISTRIBUTION_COMPONENTS` assumes that each component has both
`component` and `install-component` targets. Add a dummy no-op target
for `libclang-headers` to placate this check.
Differential Revision: https://reviews.llvm.org/D39524
llvm-svn: 317188
`add_clang_tool` includes a call to `add_clang_executable`, but it also
sets up the install rule, and adds an `install-*` target. The latter is
required for using `LLVM_DISTRIBUTION_COMPONENTS`.
Differential Revision: https://reviews.llvm.org/D39522
llvm-svn: 317150
This allows including clang-refactor in LLVM_DISTRIBUTION_COMPONENTS
to build clang-refactor as part of the toolchain distribution.
Differential Revision: https://reviews.llvm.org/D39266
llvm-svn: 316540
This commit adds an initial, skeleton outline of the "extract function"
refactoring. The extracted function doesn't capture variables / rewrite code
yet, it just basically does a simple copy-paste.
The following initiation rules are specified:
- extraction can only be done for executable code in a function/method/block.
This means that you can't extract a global variable initialize into a function
right now.
- simple literals and references are not extractable.
This commit also adds support for full source ranges to clang-refactor's test
mode.
Differential Revision: https://reviews.llvm.org/D38982
llvm-svn: 316465
o) Add a 'Location' class that represents the four properties of a
physical location
o) Enhance 'SourceLocation' to provide 'expansion' and 'spelling'
locations, maintaining backwards compatibility with existing code by
forwarding the four properties to 'expansion'.
o) Update the implementation to use 'clang_getExpansionLocation'
instead of the deprecated 'clang_getInstantiationLocation', which
has been present since 2011.
o) Update the implementation of 'clang_getSpellingLocation' to actually
obtain spelling location instead of file location.
llvm-svn: 316278
Summary:
Change clang-refactor default behavior to print the new code after refactoring
(instead of editing the source files), which would make it easier to use
and debug the refactoring action.
Reviewers: arphaman, ioeric
Reviewed By: arphaman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D39092
llvm-svn: 316212
It'd be better that they are #cmakedefine01 rather than #cmakedefine.
(#if FOO rather than #if defined(FOO))
Then we can find missing #include "clang/Config/config.h" in the future.
Differential Revision: https://reviews.llvm.org/D35541
llvm-svn: 316061
Summary: Previously, `VisitAttributes` was not called for function and class templates and thus their attributes were not accessible using libclang.
Reviewers: bkramer, arphaman, rsmith, jbcoe
Reviewed By: jbcoe
Subscribers: cfe-commits
Tags: #clang
Patch by jklaehn (Johann Klähn)
Differential Revision: https://reviews.llvm.org/D36955
llvm-svn: 315958
This commit allows the refactoring library to use its own set of
refactoring-specific diagnostics to reports things like initiation errors.
Differential Revision: https://reviews.llvm.org/D38772
llvm-svn: 315924
The fixed commit ensures that ParsedSourceRange works correctly
with Windows paths.
Original message:
This commit actually brings clang-refactor to a usable state as it can now
apply the refactoring changes to source files.
The -selection option is now also fully supported.
Differential Revision: https://reviews.llvm.org/D38402
llvm-svn: 315918
Summary:
Convert clang::LangAS to a strongly typed enum
Currently both clang AST address spaces and target specific address spaces
are represented as unsigned which can lead to subtle errors if the wrong
type is passed. It is especially confusing in the CodeGen files as it is
not possible to see what kind of address space should be passed to a
function without looking at the implementation.
I originally made this change for our LLVM fork for the CHERI architecture
where we make extensive use of address spaces to differentiate between
capabilities and pointers. When merging the upstream changes I usually
run into some test failures or runtime crashes because the wrong kind of
address space is passed to a function. By converting the LangAS enum to a
C++11 we can catch these errors at compile time. Additionally, it is now
obvious from the function signature which kind of address space it expects.
I found the following errors while writing this patch:
- ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address
space to TargetInfo::getPointer{Width,Align}()
- TypePrinter::printAttributedAfter() prints the numeric value of the
clang AST address space instead of the target address space.
However, this code is not used so I kept the current behaviour
- initializeForBlockHeader() in CGBlocks.cpp was passing
LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}()
- CodeGenFunction::EmitBlockLiteral() was passing a AST address space to
TargetInfo::getPointerWidth()
- CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space
to Qualifiers::addAddressSpace()
- CGOpenMPRuntimeNVPTX::getParameterAddress() was using
llvm::Type::getPointerTo() with a AST address space
- clang_getAddressSpace() returns either a LangAS or a target address
space. As this is exposed to C I have kept the current behaviour and
added a comment stating that it is probably not correct.
Other than this the patch should not cause any functional changes.
Reviewers: yaxunl, pcc, bader
Reviewed By: yaxunl, bader
Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits
Differential Revision: https://reviews.llvm.org/D38816
llvm-svn: 315871
This commit actually brings clang-refactor to a usable state as it can now
apply the refactoring changes to source files.
The -selection option is now also fully supported.
Differential Revision: https://reviews.llvm.org/D38402
llvm-svn: 315738
The recommit fixes a UB bug that occurred only on a small number of bots.
Original message:
This commit adds initial support for refactoring options. One can now use
optional and required std::string options.
This commit also adds a NewNameOption for the local-rename refactoring action to
allow rename to work with custom names.
Differential Revision: https://reviews.llvm.org/D37856
llvm-svn: 315661
Summary:
Compile with DummyClangFuzzer.cpp as entry point rather than
libFuzzer's main when coverage instrumentation is missing.
https://llvm.org/pr34314
Reviewers: kcc, bogner, vitalybuka
Reviewed By: vitalybuka
Subscribers: cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D38642
llvm-svn: 315336
Alex Lorenz