| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This PR passes the VFS down to `llvm::cl` functions so that they don't
assume the real file system.
|
|
|
|
This PR changes the behavior of `clang::ExecuteCompilerInvocation()` so
that it only returns early when the `DiagnosticsEngine` emitted errors
**within** the function. Handling errors emitted before the function got
called is a responsibility of the caller. Necessary for #158381.
|
|
`rootsig-define` (#154639)
This pr implements the functionality of `rootsig-define` as described
[here](https://github.com/llvm/wg-hlsl/blob/main/proposals/0029-root-signature-driver-options.md#option--rootsig-define).
This is accomplished by:
- Defining the `fdx-rootsignature-define`, and `rootsig-define` alias,
driver options. It simply specifies the name of a macro that will expand
to a `LiteralString` to be interpreted as a root signature.
- Introduces a new general frontend action wrapper,
`HLSLFrontendAction`. This class allows us to introduce `HLSL` specific
behaviour on the underlying action (primarily `ASTFrontendAction`).
Which will be further extended, or modularly wrapped, when considering
future DXC options.
- Using `HLSLFrontendAction` we can add a new `PPCallback` that will
eagerly parse the root signature specified with `rootsig-define` and
push it as a `TopLevelDecl` to `Sema`. This occurs when the macro has
been lexed.
- Since the root signature is parsed early, before any function
declarations, we can then simply attach it to the entry function once it
is encountered. Overwriting any applicable root signature attrs.
Resolves https://github.com/llvm/llvm-project/issues/150274
##### Implementation considerations
To implement this feature, note that:
1. We need access to all defined macros. These are created as part of
the first `Lex` in `Parser::Initialize` after `PP->EnterMainSourceFile`
2. `RootSignatureDecl` must be added to `Sema` before
`Consumer->HandleTranslationUnit` is invoked in `ParseAST`
Therefore, we can't handle the root signature in
`HLSLFrontendAction::ExecuteAction` before (from 1.) or after (from 2.)
invoking the underlying `ASTFrontendAction`.
This means we could alternatively:
- Manually handle this case
[here](https://github.com/llvm/llvm-project/blob/ac8f0bb070c9071742b6f6ce03bebc9d87217830/clang/lib/Parse/ParseAST.cpp#L168)
before parsing the first top level decl.
- Hook into when we [return the entry function
decl](https://github.com/llvm/llvm-project/blob/ac8f0bb070c9071742b6f6ce03bebc9d87217830/clang/lib/Parse/Parser.cpp#L1190)
and then parse the root signature and override its `RootSignatureAttr`.
The proposed solution handles this in the most modular way which should
work on any `FrontendAction` that might use the `Parser` without
invoking `ParseAST`, and, is not subject to needing to call the hook in
multiple different places of function declarators.
|
|
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
|
|
This change introduces the cir-canonicalize pass. This is a simple
cir-to-cir transformation that eliminates empty scopes and redundant
branches. It will be expanded in future changes to simplify other
redundant instruction sequences.
MLIR verification and mlir-specific command-line option handling is also
introduced here.
|
|
|
|
Add frontend actions to support emitting assembly, bitcode, and object
files when compiling with ClangIR. This change also correctly sets and
propagates the target triple in the MLIR and LLVM modules, which was a
necessary prerequisite for emitting assembly and object files.
|
|
Create the skeleton framework for lowering from ClangIR to LLVM IR. This
initial implementation just creates an empty LLVM IR module. Actual
lowering of even minimal ClangIR is deferred to a later patch.
|
|
In the discussion around #116792, @rjmccall mentioned that ARCMigrate
has been obsoleted and that we could go ahead and remove it from Clang,
so this patch does just that.
|
|
https://github.com/llvm/clangir/issues/1025 discusses the motivation.
The mechanical parts of this change were done via:
find clang \( -name '*.h' -o -name '*.cpp' -o -name '*.td' \) -print0 |
xargs -0 perl -pi -e 's/mlir::cir/cir/g'
find clang \( -name '*.h' -o -name '*.cpp' \) -print0 | xargs -0 perl
-pi -e 's/::cir/cir/g'
There were some manual fixups and a clang-format run afterwards.
|
|
Build out the necessary infrastructure for the main entry point into
ClangIR generation -- CIRGenModule. A set of boilerplate classes exist
to facilitate this -- CIRGenerator, CIRGenAction, EmitCIRAction and
CIRGenConsumer. These all mirror the corresponding types from LLVM
generation by Clang's CodeGen.
The main entry point to CIR generation is
`CIRGenModule::buildTopLevelDecl`. It is currently just an empty
function. We've added a test to ensure that the pipeline reaches this
point and doesn't fail, but does nothing else. This will be removed in
one of the subsequent patches that'll add basic `cir.func` emission.
This patch also re-adds `-emit-cir` to the driver. lib/Driver/Driver.cpp
requires that a driver flag exists to facilirate the selection of the
right actions for the driver to create. Without a driver flag you get
the standard behaviors of `-S`, `-c`, etc. If we want to emit CIR IR
and, eventually, bytecode we'll need a driver flag to force this. This
is why `-emit-llvm` is a driver flag. Notably, `-emit-llvm-bc` as a cc1
flag doesn't ever do the right thing. Without a driver flag it is
incorrectly ignored and an executable is emitted. With `-S` a file named
`something.s` is emitted which actually contains bitcode.
Reviewers: AaronBallman, MaskRay, bcardosolopes
Reviewed By: bcardosolopes, AaronBallman
Pull Request: https://github.com/llvm/llvm-project/pull/91007
|
|
Introduce just the option definitions and support for their existance at
a few different points in the frontend. This will be followed soon by
functionality that uses it.
Reviewers: bcardosolopes, jansvoboda11, AaronBallman, erichkeane, MaskRay
Reviewed By: erichkeane
Pull Request: https://github.com/llvm/llvm-project/pull/89030
|
|
Reenables b31414bf4f9898f7817a9fcf8a91f62ec26f3eaf.
Also adds a new warning for missing `--symbol-graph-dir` arg when
`--emit-extension-symbol-graphs` is provided. This also reverts the
commit that removed.
|
|
(#86676)"
This failed the test suite due to missing DiagGroup for a new warning.
This reverts commit b31414bf4f9898f7817a9fcf8a91f62ec26f3eaf.
|
|
This extends ExtractAPI to take into account symbols defined in categories to types defined in an external module.
This introduces 2 new command line flags, `--symbol-graph-dir=DIR` and `--emit-extension-symbol-graphs`, when used together this generates additional symbol graph files at `DIR/ExtendedModule@ProductName.symbols.json` for each external module that is extended in this way.
Additionally this makes some cleanups to tests to make them more resilient and cleans up the `APISet` data structure.
|
|
Close https://github.com/llvm/llvm-project/issues/71034
See
https://discourse.llvm.org/t/rfc-c-20-modules-introduce-thin-bmi-and-decls-hash/74755
This patch introduces reduced BMI, which doesn't contain the definitions
of functions and variables if its definitions won't contribute to the
ABI.
Testing is a big part of the patch. We want to make sure the reduced BMI
contains the same behavior with the existing and relatively stable
fatBMI. This is pretty helpful for further reduction.
The user interfaces part it left to following patches to ease the
reviewing.
|
|
Installapi has important distinctions when compared to the clang driver,
so much that, it doesn't make much sense to try to integrate into it.
This patch partially reverts the CC1 action & driver support to replace
with its own driver as a clang tool.
For distribution, we could use `LLVM_TOOL_LLVM_DRIVER_BUILD` mechanism
for integrating the functionality into clang such that the toolchain
size is less impacted.
|
|
This introduces a basic outline of installapi as a clang driver option.
It captures relevant information as cc1 args, which are common arguments
already passed to the linker to encode into TBD file outputs. This is
effectively an upstream for what already exists as `tapi installapi` in
Xcode toolchains, but directly in Clang. This patch does not handle any
AST traversing on input yet.
InstallAPI is broadly an operation that takes a series of header files
that represent a single dynamic library and generates a TBD file out of
it which represents all the linkable symbols and necessary attributes
for statically linking in clients. It is the linkable object in all
Apple SDKs and when building dylibs in Xcode. `clang -installapi` also
will support verification where it compares all the information recorded
for the TBD files against the already built binary, to catch possible
mismatches like when a declaration is missing a definition for an
exported symbol.
|
|
|
|
|
|
This is a big refactor of the clang driver's option handling to use
the Visibility flags introduced in https://reviews.llvm.org/D157149.
There are a few distinct parts, but they can't really be split into
separate commits and still be made to compile.
1. We split out some of the flags in ClangFlags to ClangVisibility.
Note that this does not include any subtractive flags.
2. We update the Flag definitions and OptIn/OptOut constructs in
Options.td by hand.
3. We introduce and use a script, update_options_td_flags, to ease
migration of flag definitions in Options.td, and we run that on
Options.td. I intend to remove this later, but I'm committing it so
that downstream forks can use the script to simplify merging.
4. We update calls to OptTable in the clang driver, cc1as, flang, and
clangd to use the visibility APIs instead of Include/Exclude flags.
5. We deprecate the Include/Exclude APIs and add a release note.
*if you are running into conflicts with this change:*
Note that https://reviews.llvm.org/D157150 may also be the culprit and
if so it should be handled first.
The script in `clang/utils/update_options_td_flags.py` can help. Take
the downstream side of all conflicts and then run the following:
```
% cd clang/include/clang/Driver
% ../../../utils/update_options_td_flags.py Options.td > Options.td.new
% mv Options.td.new Options.td
```
This will hopefully be sufficient, please take a look at the diff.
Differential Revision: https://reviews.llvm.org/D157151
|
|
Add new --emit-symbol-graph=<DIR> option which generates ExtractAPI symbol
graph information of .c/.m files on regular compilation job and put them in
the provided "DIR" directory.
Reviewed By: dang
Differential Revision: https://reviews.llvm.org/D152356
|
|
Currently there is a -emit-header-module mode, which can combine several
headers together as a module interface. However, this breaks our
assumption (for standard c++ modules) about module interface. The module
interface should come from a module interface unit. And if it is a
header, it should be a header unit. And currently we have no ideas to
combine several headers together.
So I think this mode is an experimental one and it is not maintained and
it is not used. So it will be better to remove them.
Reviewed By: Bigcheese, dblaikie, bruno
Differential Revision: https://reviews.llvm.org/D137609
|
|
This is the first in a series of patches that introduce C++20 importable
header units.
These differ from clang header modules in that:
(a) they are identifiable by an internal name
(b) they represent the top level source for a single header - although
that might include or import other headers.
We name importable header units with the path by which they are specified
(although that need not be the absolute path for the file).
So "foo/bar.h" would have a name "foo/bar.h". Header units are made a
separate module type so that we can deal with diagnosing places where they
are permitted but a named module is not.
Differential Revision: https://reviews.llvm.org/D121095
|
|
- 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
|
|
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
|
|
This is the initial commit for the clang-extract-api RFC
<https://lists.llvm.org/pipermail/cfe-dev/2021-September/068768.html>
Add a new driver option `-extract-api` and associate it with a dummy
(for now) frontend action to set up the initial structure for
incremental works.
Differential Revision: https://reviews.llvm.org/D117809
|
|
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
|
|
Differential revision: https://reviews.llvm.org/D110484
|
|
This reverts commit 81fb640f83b6a5d099f9124739ab3049be79ea56 due to bot failures:
https://lab.llvm.org/buildbot#builders/57/builds/10807
|
|
Differential revision: https://reviews.llvm.org/D110484
|
|
To be consistent with other member functions and match the coding standard.
|
|
|
|
Prior to this change the clang interface stubs format resembled
something ending with a symbol list like this:
Symbols:
a: { Type: Func }
This was problematic because we didn't actually want a map format and
also because we didn't like that an empty symbol list required
"Symbols: {}". That is to say without the empty {} llvm-ifs would crash
on an empty list.
With this new format it is much more clear which field is the symbol
name, and instead the [] that is used to express an empty symbol vector
is optional, ie:
Symbols:
- { Name: a, Type: Func }
or
Symbols: []
or
Symbols:
This further diverges the format from existing llvm-elftapi. This is a
good thing because although the format originally came from the same
place, they are not the same in any way.
Differential Revision: https://reviews.llvm.org/D76979
|
|
CheckerManager to be constructed for non-analysis purposes"
Originally commited in rG57b8a407493c34c3680e7e1e4cb82e097f43744a, but
it broke the modules bot. This is solved by putting the contructors of
the CheckerManager class to the Frontend library.
Differential Revision: https://reviews.llvm.org/D75360
|
|
CheckerManager to be constructed for non-analysis purposes"
Temporarily reverting this patch because it breaks the modules build.
|
|
to be constructed for non-analysis purposes
Its been a while since my CheckerRegistry related patches landed, allow me to
refresh your memory:
During compilation, TblGen turns
clang/include/clang/StaticAnalyzer/Checkers/Checkers.td into
(build directory)/tools/clang/include/clang/StaticAnalyzer/Checkers/Checkers.inc.
This is a file that contains the full name of the checkers, their options, etc.
The class that is responsible for parsing this file is CheckerRegistry. The job
of this class is to establish what checkers are available for the analyzer (even
from plugins and statically linked but non-tblgen generated files!), and
calculate which ones should be turned on according to the analyzer's invocation.
CheckerManager is the class that is responsible for the construction and storage
of checkers. This process works by first creating a CheckerRegistry object, and
passing itself to CheckerRegistry::initializeManager(CheckerManager&), which
will call the checker registry functions (for example registerMallocChecker) on
it.
The big problem here is that these two classes lie in two different libraries,
so their interaction is pretty awkward. This used to be far worse, but I
refactored much of it, which made things better but nowhere near perfect.
---
This patch changes how the above mentioned two classes interact. CheckerRegistry
is mainly used by CheckerManager, and they are so intertwined, it makes a lot of
sense to turn in into a field, instead of a one-time local variable. This has
additional benefits: much of the information that CheckerRegistry conveniently
holds is no longer thrown away right after the analyzer's initialization, and
opens the possibility to pass CheckerManager in the shouldRegister* function
rather then LangOptions (D75271).
There are a few problems with this. CheckerManager isn't the only user, when we
honor help flags like -analyzer-checker-help, we only have access to a
CompilerInstance class, that is before the point of parsing the AST.
CheckerManager makes little sense without ASTContext, so I made some changes and
added new constructors to make it constructible for the use of help flags.
Differential Revision: https://reviews.llvm.org/D75360
|
|
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
|
|
Short and sweet. Whenever I use -analyzer-list-enabled-checkers, I'm only
interested about the configuration, not about the analysis.
Differential Revision: https://reviews.llvm.org/D66714
llvm-svn: 371756
|
|
Summary:
This significantly reduces the time required to run clangd tests, by
~10%.
Should also have an effect on other tests that run command-line parsing
multiple times inside a single invocation.
Reviewers: gribozavr, sammccall
Reviewed By: sammccall
Subscribers: kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67163
llvm-svn: 370908
|
|
I've been working on a new tool, llvm-ifs, for merging interface stub files
generated by clang and I've iterated on my derivative format of TBE to a newer
format. llvm-ifs will only support the new format, so I am going to drop the
older experimental interface stubs formats in this commit to make things
simpler.
Differential Revision: https://reviews.llvm.org/D66573
llvm-svn: 369719
|
|
After posting llvm-ifs on phabricator, I made some progress in hardening up how
I think the format for Interface Stubs should look. There are a number of
things I think the TBE format was missing (no endianness, no info about the
Object Format because it assumes ELF), so I have added those and broken off
from being as similar to the TBE schema. In a subsequent commit I can drop the
other formats.
An example of how The format will look is as follows:
--- !experimental-ifs-v1
IfsVersion: 1.0
Triple: x86_64-unknown-linux-gnu
ObjectFileFormat: ELF
Symbols:
_Z9nothiddenv: { Type: Func }
_Z10cmdVisiblev: { Type: Func }
...
The format is still marked experimental.
Differential Revision: https://reviews.llvm.org/D66446
llvm-svn: 369715
|
|
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
|
|
This change reverts r363649; effectively re-landing r363626. At this point
clang::Index::CodegenNameGeneratorImpl has been refactored into
clang::AST::ASTNameGenerator. This makes it so that the previous circular link
dependency no longer exists, fixing the previous share lib
(-DBUILD_SHARED_LIBS=ON) build issue which was the reason for r363649.
Clang interface stubs (previously referred to as clang-ifsos) is a new frontend
action in clang that allows the generation of stub files that contain mangled
name info that can be used to produce a stub library. These stub libraries can
be useful for breaking up build dependencies and controlling access to a
library's internal symbols. Generation of these stubs can be invoked by:
clang -fvisibility=<visibility> -emit-interface-stubs \
-interface-stub-version=<interface format>
Notice that -fvisibility (along with use of visibility attributes) can be used
to control what symbols get generated. Currently the interface format is
experimental but there are a wide range of possibilities here.
Currently clang-ifs produces .ifs files that can be thought of as analogous to
object (.o) files, but just for the mangled symbol info. In a subsequent patch
I intend to add support for merging the .ifs files into one .ifs/.ifso file
that can be the input to something like llvm-elfabi to produce something like a
.so file or .dll (but without any of the code, just symbols).
Differential Revision: https://reviews.llvm.org/D60974
llvm-svn: 363948
|
|
This reverts commit rC363626.
clangIndex depends on clangFrontend. r363626 adds a dependency from
clangFrontend to clangIndex, which creates a circular dependency.
This is disallowed by -DBUILD_SHARED_LIBS=on builds:
CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle):
"clangFrontend" of type SHARED_LIBRARY
depends on "clangIndex" (weak)
"clangIndex" of type SHARED_LIBRARY
depends on "clangFrontend" (weak)
At least one of these targets is not a STATIC_LIBRARY. Cyclic dependencies are allowed only among static libraries.
Note, the dependency on clangIndex cannot be removed because
libclangFrontend.so is linked with -Wl,-z,defs: a shared object must
have its full direct dependencies specified on the linker command line.
In -DBUILD_SHARED_LIBS=off builds, this appears to work when linking
`bin/clang-9`. However, it can cause trouble to downstream clang library
users. The llvm build system links libraries this way:
clang main_program_object_file ... lib/libclangIndex.a ... lib/libclangFrontend.a -o exe
libclangIndex.a etc are not wrapped in --start-group.
If the downstream application depends on libclangFrontend.a but not any
other clang libraries that depend on libclangIndex.a, this can cause undefined
reference errors when the linker is ld.bfd or gold.
The proper fix is to not include clangIndex files in clangFrontend.
llvm-svn: 363649
|
|
Clang interface stubs (previously referred to as clang-ifsos) is a new frontend
action in clang that allows the generation of stub files that contain mangled
name info that can be used to produce a stub library. These stub libraries can
be useful for breaking up build dependencies and controlling access to a
library's internal symbols. Generation of these stubs can be invoked by:
clang -fvisibility=<visibility> -emit-interface-stubs \
-interface-stub-version=<interface format>
Notice that -fvisibility (along with use of visibility attributes) can be used
to control what symbols get generated. Currently the interface format is
experimental but there are a wide range of possibilities here.
Differential Revision: https://reviews.llvm.org/D60974
llvm-svn: 363626
|
|
that might affect the dependency list for a compilation
This commit introduces a dependency directives source minimizer to clang
that minimizes header and source files to the minimum necessary preprocessor
directives for evaluating includes. It reduces the source down to #define, #include,
The source minimizer works by lexing the input with a custom fast lexer that recognizes
the preprocessor directives it cares about, and emitting those directives in the minimized source.
It ignores source code, comments, and normalizes whitespace. It gives up and fails if seems
any directives that it doesn't recognize as valid (e.g. #define 0).
In addition to the source minimizer this patch adds a
-print-dependency-directives-minimized-source CC1 option that allows you to invoke the minimizer
from clang directly.
Differential Revision: https://reviews.llvm.org/D55463
llvm-svn: 362459
|
|
developer
Same patch as D62093, but for checker/plugin options, the only
difference being that options for alpha checkers are implicitly marked
as alpha.
Differential Revision: https://reviews.llvm.org/D62093
llvm-svn: 361566
|
|
These options are now only visible under
-analyzer-checker-option-help-developer.
Differential Revision: https://reviews.llvm.org/D61839
llvm-svn: 361561
|
