Add an option to cache the generated PCH in the ModuleCache when
emitting it. This protects clients that build PCHs and read them in the
same process, allowing them to avoid race conditions between parallel
jobs the same way that Clang's implicit module build system does.
rdar://problem/48740787
llvm-svn: 355950
Summary:
The revision r355434 had the unfortunate side-effect that it started to
recognize certain ObjC expressions with a call subexpression followed by a
`a->b` subexpression as C++ lambda expressions.
This patch adds a bit of logic to handle these cases and documents them in
tests.
The commented-out test cases in the new test suite are ones that were
problematic before r355434.
Reviewers: MyDeveloperDay, gribozavr
Reviewed By: MyDeveloperDay, gribozavr
Subscribers: MyDeveloperDay, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59210
llvm-svn: 355831
Leverage the InMemoryModuleCache to invalidate a module the first time
it fails to import (and to lock a module as soon as it's built or
imported successfully). For implicit module builds, this optimizes
importing deep graphs where the leaf module is out-of-date; see example
near the end of the commit message.
Previously the cache finalized ("locked in") all modules imported so far
when starting a new module build. This was sufficient to prevent
loading two versions of the same module, but was somewhat arbitrary and
hard to reason about.
Now the cache explicitly tracks module state, where each module must be
one of:
- Unknown: module not in the cache (yet).
- Tentative: module in the cache, but not yet fully imported.
- ToBuild: module found on disk could not be imported; need to build.
- Final: module in the cache has been successfully built or imported.
Preventing repeated failed imports avoids variation in builds based on
shifting filesystem state. Now it's guaranteed that a module is loaded
from disk exactly once. It now seems safe to remove
FileManager::invalidateCache, but I'm leaving that for a later commit.
The new, precise logic uncovered a pre-existing problem in the cache:
the map key is the module filename, and different contexts use different
filenames for the same PCM file. (In particular, the test
Modules/relative-import-path.c does not build without this commit.
r223577 started using a relative path to describe a module's base
directory when importing it within another module. As a result, the
module cache sees an absolute path when (a) building the module or
importing it at the top-level, and a relative path when (b) importing
the module underneath another one.)
The "obvious" fix is to resolve paths using FileManager::getVirtualFile
and change the map key for the cache to a FileEntry, but some contexts
(particularly related to ASTUnit) have a shorter lifetime for their
FileManager than the InMemoryModuleCache. This is worth pursuing
further in a later commit; perhaps by tying together the FileManager and
InMemoryModuleCache lifetime, or moving the in-memory PCM storage into a
VFS layer.
For now, use the PCM's base directory as-written for constructing the
filename to check the ModuleCache.
Example
=======
To understand the build optimization, first consider the build of a
module graph TU -> A -> B -> C -> D with an empty cache:
TU builds A'
A' builds B'
B' builds C'
C' builds D'
imports D'
B' imports C'
imports D'
A' imports B'
imports C'
imports D'
TU imports A'
imports B'
imports C'
imports D'
If we build TU again, where A, B, C, and D are in the cache and D is
out-of-date, we would previously get this build:
TU imports A
imports B
imports C
imports D (out-of-date)
TU builds A'
A' imports B
imports C
imports D (out-of-date)
builds B'
B' imports C
imports D (out-of-date)
builds C'
C' imports D (out-of-date)
builds D'
imports D'
B' imports C'
imports D'
A' imports B'
imports C'
imports D'
TU imports A'
imports B'
imports C'
imports D'
After this commit, we'll immediateley invalidate A, B, C, and D when we
first observe that D is out-of-date, giving this build:
TU imports A
imports B
imports C
imports D (out-of-date)
TU builds A' // The same graph as an empty cache.
A' builds B'
B' builds C'
C' builds D'
imports D'
B' imports C'
imports D'
A' imports B'
imports C'
imports D'
TU imports A'
imports B'
imports C'
imports D'
The new build matches what we'd naively expect, pretty closely matching
the original build with the empty cache.
rdar://problem/48545366
llvm-svn: 355778
Change MemoryBufferCache to InMemoryModuleCache, moving it from Basic to
Serialization. Another patch will start using it to manage module build
more explicitly, but this is split out because it's mostly mechanical.
Because of the move to Serialization we can no longer abuse the
Preprocessor to forward it to the ASTReader. Besides the rename and
file move, that means Preprocessor::Preprocessor has one fewer parameter
and ASTReader::ASTReader has one more.
llvm-svn: 355777
Summary:
In current indexing logic we get references to class itself when we see
a constructor/destructor which is only syntactically true. Semantically
this information is not correct. This patch marks that reference as
NameReference to let clients deal with it.
Reviewers: akyrtzi, gribozavr, nathawes, benlangmuir
Reviewed By: gribozavr, nathawes
Subscribers: nathawes, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58814
llvm-svn: 355668
We should track mutation of a variable within a comma operator expression.
Current code in ExprMutationAnalyzer does not handle it.
This will handle cases like:
(a, b) ++ < == b is modified
(a, b) = c < == b is modifed
Patch by Djordje Todorovic.
Differential Revision: https://reviews.llvm.org/D58894
llvm-svn: 355605
Summary:
Member expressions with explicit template arguments were not imported
correctly: the DeclRefExpr was missing. This patch fixes.
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58830
llvm-svn: 355596
Summary:
Redecl chains of function templates are not handled well currently. We
want to handle them similarly to functions, i.e. try to keep the
structure of the original AST as much as possible. The aim is to not
squash a prototype with a definition, rather we create both and put them
in a redecl chain.
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58494
llvm-svn: 355593
Since
commit 56f548bbbb7e4387a69708f70724d00e9e076153
[modules] Round-trip -Werror flag through explicit module build.
the behavior of CXTranslationUnit_KeepGoing changed:
Unresolved #includes are fatal errors again. As a consequence, some
templates are not instantiated and lead to confusing errors.
Revert to the old behavior: With CXTranslationUnit_KeepGoing fatal
errors are mapped to errors.
Patch by Nikolai Kosjar.
Differential Revision: https://reviews.llvm.org/D58501
llvm-svn: 355586
Summary:
A Lamdba with a return type template with a boolean literal (true,false) behaves differently to an integer literal
https://bugs.llvm.org/show_bug.cgi?id=40910
Reviewers: klimek, djasper, JonasToth, alexfh, krasimir, jkorous
Reviewed By: jkorous
Subscribers: jkorous, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D58922
llvm-svn: 355450
A template specialization of a template foo<int N> can contain integer constants and a whole bunch of operators - e. g. foo< 1 ? !0 : (3+1)%4 >
Inspired by https://reviews.llvm.org/D58922
Differential Revision: https://reviews.llvm.org/D58934
llvm-svn: 355434
Summary:
Redecl chains of classes and class templates are not handled well
currently. We want to handle them similarly to functions, i.e. try to
keep the structure of the original AST as much as possible. The aim is
to not squash a prototype with a definition, rather we create both and
put them in a redecl chain.
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58502
llvm-svn: 355390
Summary:
FileData was only ever used as a container for the values in
llvm::vfs::Status, so they might as well be consolidated.
The `InPCH` member was also always set to false, and unused.
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58924
llvm-svn: 355368
Under the term "subchecker", I mean checkers that do not have a checker class on
their own, like unix.MallocChecker to unix.DynamicMemoryModeling.
Since a checker object was required in order to retrieve checker options,
subcheckers couldn't possess options on their own.
This patch is also an excuse to change the argument order of getChecker*Option,
it always bothered me, now it resembles the actual command line argument
(checkername:option=value).
Differential Revision: https://reviews.llvm.org/D57579
llvm-svn: 355297
Summary:
If the clang-format on/off is in a /* comment */ then the sorting of headers is not ignored
PR40901 - https://bugs.llvm.org/show_bug.cgi?id=40901
Reviewers: djasper, klimek, JonasToth, krasimir, alexfh
Reviewed By: alexfh
Subscribers: alexfh, cfe-commits, llvm-commits
Tags: #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D58819
llvm-svn: 355266
Summary:
clang-formatting wants to add spaces around items in square braces, e.g. [1, 2] -> [ 1, 2 ]. Based on a quick check [1], it seems like most cases are using the [1, 2] format, so make that the consistent one.
[1] in llvm `.td` files, the regex `\[[^ ]` (bracket followed by not-a-space) shows up ~400 times, but `\[\s[^ ]` (bracket followed by one space and one not-a-space) shows up ~40 times => ~90% uses this format.
Reviewers: djasper, krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D55964
llvm-svn: 355158
Summary:
getLLVMStyle() sets the default style, but doesn't take the language as a parameter, so can't set default parameters when they differ from C++. This change adds LanguageKind as an input to getLLVMStyle so that we can start doing that.
See D55964 as a motivation for this, where we want Tablegen to be formatted differently than C++.
Reviewers: djasper, krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: jdoerfert, MyDeveloperDay, kristina, cfe-commits, arphaman
Tags: #clang
Differential Revision: https://reviews.llvm.org/D56943
llvm-svn: 355123
Summary:
This allows ASTs to be merged when they contain ChooseExpr (the GNU
__builtin_choose_expr construction). This is needed, for example, for
cross-CTU analysis of C code that makes use of __builtin_choose_expr.
The node is already supported in the AST, but it didn't have a matcher
in ASTMatchers. So, this change adds the matcher and adds support to
ASTImporter.
This was originally reviewed and approved in
https://reviews.llvm.org/D58292 and submitted as r354832. It was
reverted in r354839 due to failures on the Windows CI builds.
This version fixes the test failures on Windows, which were caused by
differences in template expansion between versions of clang on different
OSes. The version of clang built with MSVC and running on Windows never
expands the template in the C++ test in ImportExpr.ImportChooseExpr in
clang/unittests/AST/ASTImporter.cpp, but the version on Linux does for
the empty arguments and -fms-compatibility.
So, this version of the patch drops the C++ test for
__builtin_choose_expr, since that version was written to catch
regressions of the logic for isConditionTrue() in the AST import code
for ChooseExpr, and those regressions are also caught by
ASTImporterOptionSpecificTestBase.ImportChooseExpr, which does work on
Windows.
Reviewers: shafik, a_sidorin, martong, aaron.ballman, rnk, a.sidorin
Subscribers: cfe-commits, jdoerfert, rnkovacs, aaron.ballman
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58663
llvm-svn: 354916
Summary:
Add indexing of UsingDecl itself.
Also enable generation of USRs for UsingDecls, using the qualified name of the
decl.
Reviewers: ilya-biryukov, akyrtzi
Subscribers: arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58340
llvm-svn: 354878
Summary:
See the added test for some new cases.
This change also removes special code completion calls inside the
ParseExpressionList function now that we properly propagate expected
type to the function responsible for parsing elements of the expression list
(ParseAssignmentExpression).
Reviewers: kadircet
Reviewed By: kadircet
Subscribers: xbolva00, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58541
llvm-svn: 354864
Summary:
This allows ASTs to be merged when they contain ChooseExpr (the GNU
__builtin_choose_expr construction). This is needed, for example, for
cross-CTU analysis of C code that makes use of __builtin_choose_expr.
The node is already supported in the AST, but it didn't have a matcher
in ASTMatchers. So, this change adds the matcher and adds support to
ASTImporter.
Reviewers: shafik, a_sidorin, martong, aaron.ballman
Subscribers: aaron.ballman, rnkovacs, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58292
llvm-svn: 354832
Summary:
This will allow completion consumers to guess the specified scope by
putting together scopes in the context with the specified scope (e.g. when the
specified namespace is not imported yet).
Reviewers: ilya-biryukov
Subscribers: jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58446
llvm-svn: 354570
Summary:
clangd uses indexing api to provide references and it was not possible
to perform symbol information for template parameters. This patch enables
visiting of TemplateTypeParmTypeLocs.
Reviewers: ilya-biryukov, akyrtzi
Subscribers: javed.absar, kristof.beyls, ioeric, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58293
llvm-svn: 354560
Summary:
Currently clang-format would always emit a replacement for a block of Java imports even if it is correctly formatted:
```
% cat /tmp/Aggregator.java
import X;
% clang-format /tmp/Aggregator.java
import X;
% clang-format -output-replacements-xml /tmp/Aggregator.java
<?xml version='1.0'?>
<replacements xml:space='preserve' incomplete_format='false'>
<replacement offset='0' length='9'>import X;</replacement>
</replacements>
%
```
This change makes clang-format not emit replacements in this case. Note that
there is logic to not emit replacements in this case for C++.
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58436
llvm-svn: 354452
Summary:
Indexing context was skipping explicit template instantiations as well.
This patch makes sure it only skips implicit ones.
Subscribers: arphaman, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58189
llvm-svn: 354262
Summary:
This patch unifies all those tests which check the correctness of the
redecl chains. Previously we had several structurally very similar test
cases for each language construct (class, function, variable, function
template, ...).
We still use value-parameterized tests for the different AST
compatibility switches (-fdelayed-template-parsing, -fms-compatibility).
Gtest makes it possible to have either value-parameterized or
type-parameterized fixtures. However, we cannot have both value- and
type-parameterized test fixtures. So we use a value-parameterized test
fixture in the gtest sense. We intend to mimic gtest's type-parameters
via the type template parameter. We manually instantiate the different
tests with the each types.
After this patch I am planning to put the "generic redecl chain" related
tests into their own separate test file (in another patch).
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Differential Revision: https://reviews.llvm.org/D57236
llvm-svn: 354259
Certain combinations of gcc and ccache fail when the raw
string literal is preprocessed. This just moves the string
out as is done elsewhere in the same file.
llvm-svn: 354201
Trailing comments are not always aligned properly when UseTab is set to Always.
Consider:
int a; // x
int bbbbbbbb; // x
With .clang-format:
---
Language: Cpp
BasedOnStyle: LLVM
UseTab: Always
...
The trailing comments of this code block should be aligned, but aren't
To align the first trailing comment it needs to insert 8 spaces. This should be
one tab plus six spaces. It skips the logic of the first partial tab in
FirstTabWidth (=2) + Style.TabWidth (=8) <= Spaces (=8) and only inserts one
tab. Proposed fix and test is attached.
Patch by Hylke Kleve.
Differential revision: https://reviews.llvm.org/D57655
llvm-svn: 354183
Summary:
Previously only the fields were imported. Now every Decl is imported.
This way the destructor decl is not missing after import.
Patch by balazske (Balázs Kéri)
Reviewers: a.sidorin, shafik
Reviewed By: shafik
Subscribers: balazske, cfe-commits, Szelethus, martong, dkrupp
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57740
llvm-svn: 354120
The pathname wasn't previously filled when the getFile() method was called with openFile = false.
We are caching FileEntry-s in ParsedAST::Includes in clangd and this caused the problem.
This fixes an internal test failure in clangd - ClangdTests.GoToInclude.All
rdar://47536127
Differential Revision: https://reviews.llvm.org/D58213
llvm-svn: 354075
Summary:
During import of a global variable with external visibility the lookup
will find variables (with the same name) but with static visibility.
Clearly, we cannot put them into the same redecl chain. The same is
true in case of functions. In this fix we filter the lookup results and
consider only those which have the same visibility as the decl we
currently import.
We consider two decls in two anonymous namsepaces to have the same
visibility only if they are imported from the very same translation
unit.
Reviewers: a_sidorin, shafik, a.sidorin
Reviewed By: shafik
Subscribers: jdoerfert, balazske, rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57232
llvm-svn: 354027
Summary:
Parameters in declarations are useful for clangd, so that we can
provide symbol information for them as well. It also helps clangd to be
consistent whether a function's definition is accessible or not.
Reviewers: hokein, akyrtzi
Subscribers: ilya-biryukov, ioeric, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57949
llvm-svn: 353695
Summary:
We add a new test to show that redecl chains are not handled properly
amongst namespaces. We cannot pass this test now, so this is disabled.
Subsequent patches will make this test pass.
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57901
llvm-svn: 353684
Summary:
Currently, `UnwrappedLineParser` thinks an arrow token after
an ObjC method expression is a C++ lambda arrow, so it formats:
```
[foo bar]->baz
```
as:
```
[foo bar] -> baz
```
Because `UnwrappedLineParser` runs before `TokenAnnotator`, it can't
know if the arrow token is after an ObjC method expression or not.
This diff makes `TokenAnnotator` remove the TT_LambdaArrow on
the arrow token if it follows an ObjC method expression.
Test Plan: New test added. Ran test with:
% ninja FormatTests && ./tools/clang/unittests/Format/FormatTests
Confirmed test failed before diff and passed after diff.
Reviewers: krasimir, djasper, sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57923
llvm-svn: 353531
Summary:
This is to check that operators are handled properly in
`ASTImporterSpecificLookup`. Note, this lookup table is not used in LLDB, only
in CTU.
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57905
llvm-svn: 353505
Summary: Operators kind was not checked, so we reported e.g. op- to be equal with op+
Reviewers: shafik, a_sidorin, aaron.ballman
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57902
llvm-svn: 353504
Summary:
Currently `TestImportBase` is derived from `ParameterizedTestsFixture`
which explicitly states that the gtest parameter can be only an
`ArgVector`. This is a limitation when we want to create tests which may
have different parameters.
E.g. we would like to create tests where we can combine different test
parameters. So, for example we'd like gtest to be able to provide
parameters of `<std::tuple<ArgVector, const char *>` instead of a simple
`ArgVector`.
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Differential Revision: https://reviews.llvm.org/D57322
llvm-svn: 353425
Summary:
From https://bugs.llvm.org/show_bug.cgi?id=40516
```
$ cat a.cpp
const NamespaceName::VeryLongClassName &NamespaceName::VeryLongClassName::myFunction() {
// do stuff
}
const NamespaceName::VeryLongClassName &NamespaceName::VeryLongClassName::operator++() {
// do stuff
}
$ ~/ll/build/opt/bin/clang-format -style=LLVM a.cpp
const NamespaceName::VeryLongClassName &
NamespaceName::VeryLongClassName::myFunction() {
// do stuff
}
const NamespaceName::VeryLongClassName &NamespaceName::VeryLongClassName::
operator++() {
// do stuff
}
```
What was happening is that the split penalty before `operator` was being set to
a smaller value by a prior if block. Moved checks around to fix this and added a
regression test.
Reviewers: djasper
Reviewed By: djasper
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57604
llvm-svn: 353033
Instead of calling CUDA runtime to arrange function arguments,
the new API constructs arguments in a local array and the kernels
are launched with __cudaLaunchKernel().
The old API has been deprecated and is expected to go away
in the next CUDA release.
Differential Revision: https://reviews.llvm.org/D57488
llvm-svn: 352799
Preferred types are used by code completion for ranking. This commit
considerably increases the number of points in code where those types
are propagated.
In order to avoid complicating signatures of Parser's methods, a
preferred type is kept as a member variable in the parser and updated
during parsing.
Differential revision: https://reviews.llvm.org/D56723
llvm-svn: 352788
Summary:
When importing classes we may add a CXXMethodDecl more than once to a CXXRecordDecl when handling overrides. This patch will fix the cases we currently know about and handle the case where we are only dealing with declarations.
Differential Revision: https://reviews.llvm.org/D56936
llvm-svn: 352436
Summary:
New tests added to verify equivalency of templates when their
parameters are different.
Reviewers: a_sidorin, shafik
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Differential Revision: https://reviews.llvm.org/D57235
llvm-svn: 352345
The commit r322690 introduced support for ObjC detection in header files.
Unfortunately some C headers that use designated initializers are now
incorrectly detected as Objective-C.
This commit fixes it by ensuring that `[ token ]` is not annotated as an
Objective-C message send.
rdar://45504376
Differential Revision: https://reviews.llvm.org/D56226
llvm-svn: 352125
Summary:
r347205 fixed a bug in FileManager: first calling
getFile(shouldOpen=false) and then getFile(shouldOpen=true) results in
the file not being open.
Unfortunately, some code was (inadvertently?) relying on this bug: when
building with a PCH, the file entries are obtained first by passing
shouldOpen=false, and then later shouldOpen=true, without any intention
of reading them. After r347205, they do get unneccesarily opened.
Aside from extra operations, this means they need to be closed. Normally
files are closed when their contents are read. As these files are never
read, they stay open until clang exits. On platforms with a low
open-files limit (e.g. Mac), this can lead to spurious file-not-found
errors when building large projects with PCH enabled, e.g.
https://bugs.chromium.org/p/chromium/issues/detail?id=924225
Fixing the callsites to pass shouldOpen=false when the file won't be
read is not quite trivial (that info isn't available at the direct
callsite), and passing shouldOpen=false is a performance regression (it
results in open+fstat pairs being replaced by stat+open).
So an ideal fix is going to be a little risky and we need some fix soon
(especially for the llvm 8 branch).
The problem addressed by r347205 is rare and has only been observed in
clangd. It was present in llvm-7, so we can live with it for now.
Reviewers: bkramer, thakis
Subscribers: ilya-biryukov, ioeric, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D57165
llvm-svn: 352079
Fix remaining unittest errors caused by
__attribute__((no_caller_saved_registers))
Related commit which caused the buildbots to fail:
rL352050
llvm-svn: 352060
Summary:
FunctionType::ExtInfo holds such properties of a function which are needed
mostly for code gen. We should not compare these bits when checking for
structural equivalency.
Checking ExtInfo caused false ODR errors during CTU analysis (of tmux).
Reviewers: a_sidorin, a.sidorin, shafik
Subscribers: rnkovacs, dkrupp, Szelethus, cfe-commits
Differential Revision: https://reviews.llvm.org/D53699
llvm-svn: 352050
Summary:
This patch adds two unit-tests that are the result of reducing a crashing TU
when running ExprMutAnalyzer over it. They are added only to ensure the regression
that has been fixed with https://reviews.llvm.org/D56444 don't creep back.
Reviewers: aaron.ballman, sammccall, rsmith, george.karpenkov
Reviewed By: sammccall
Subscribers: baloghadamsoftware, a.sidorin, Szelethus, donat.nagy, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D56917
llvm-svn: 351743
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
Summary:
Currently both clangd and clang-tidy makes use of this mechanism so
putting it into tooling so that all tools can make use of it.
Reviewers: ilya-biryukov, sammccall
Subscribers: ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D56856
llvm-svn: 351531
SymbolReaper now realizes that our liveness analysis isn't sharp enough
to discriminate between liveness of, say, variables and their fields.
Surprisingly, this didn't quite work before: having a variable live only
through Environment (eg., calling a C++ method on a local variable
as the last action ever performed on that variable) would not keep the
region value symbol of a field of that variable alive.
It would have been broken in the opposite direction as well, but both
Environment and RegionStore use the scanReachableSymbols mechanism for finding
live symbols regions within their values, and due to that they accidentally
end up marking the whole chain of super-regions as live when at least one
sub-region is known to be live.
It is now a direct responsibility of SymbolReaper to maintain this invariant,
and a unit test was added in order to make sure it stays that way.
Differential Revision: https://reviews.llvm.org/D56632
rdar://problem/46914108
llvm-svn: 351499
The test case had a parse error that was causing the condition string to be misreported. We now have better fallback code for error cases.
llvm-svn: 351470
Summary:
Prior to r351069, lambda classes were traversed or not depending on the
{Function, Class, Namespace, TU} DeclContext containing them.
If it was a function (common case) they were not traversed.
If it was a namespace or TU (top-level lambda) they were traversed as part of
that DeclContext traversal.
r351069 "fixed" RAV to traverse these as part of the LambdaExpr, which is the
right place. But top-level lambdas are now traversed twice.
We fix that as blocks and block captures were apparently fixed in the past.
Maybe it would be nicer to avoid adding the lambda classes to the DeclContext
in the first place, but I can't work out the implications of that.
Reviewers: bkramer, klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D56665
llvm-svn: 351075
Summary:
This fixes ASTContext's parent map for nodes in such classes (e.g. operator()).
https://bugs.llvm.org/show_bug.cgi?id=39949
This also changes the observed shape of the AST for implicit RAVs.
- this includes AST MatchFinder: cxxRecordDecl() now matches lambda classes,
functionDecl() matches the call operator, and the parent chain is body -> call
operator -> lambda class -> lambdaexpr rather than body -> lambdaexpr.
- this appears not to matter for the ASTImporterLookupTable builder
- this doesn't matter for the other RAVs in-tree.
In order to do this, we remove the TraverseLambdaBody hook. The problem is it's
hard/weird to ensure this hook is called when traversing via the implicit class.
There were just two users of this hook in-tree, who use it to skip bodies.
I replaced these with explicitly traversing the captures only. Another approach
would be recording the bodies when the lambda is visited, and then recognizing
them later.
I'd be open to suggestion on how to preserve this hook, instead.
Reviewers: aaron.ballman, JonasToth
Subscribers: cfe-commits, rsmith, jdennett
Differential Revision: https://reviews.llvm.org/D56444
llvm-svn: 351047
This adjusts the source range passed in to the preprocessor callbacks to only include the condition range itself, rather than all of the conditionally skipped tokens.
llvm-svn: 350891
The original commit had a memory leak in the test has a leak as it doesn't
dispose of the evaluated cursor result.
This also contains the follow-up NFC refactoring commit r336591.
rdar://45893054
Original commit message:
[libclang] evalute compound statement cursors before trying to evaluate
the cursor like a declaration
This change fixes a bug in libclang in which it tries to evaluate a statement
cursor as a declaration cursor, because that statement still has a pointer to
the declaration parent.
rdar://38888477
Differential Revision: https://reviews.llvm.org/D49051
llvm-svn: 350666
Summary:
`buildASTFromCodeWithArgs()` was creating a memory buffer referencing a
stack-allocated string. This diff changes the implementation to copy the code
string into the memory buffer so that said buffer owns the memory.
Patch by Yitzhak Mandelbaum.
Reviewers: alexfh
Reviewed By: alexfh
Subscribers: cfe-commits, EricWF
Differential Revision: https://reviews.llvm.org/D55765
llvm-svn: 350638
Summary: The LocationE parameter of evalStore is documented as "The location expression that is stored to". When storing from an increment / decrement operator this was not satisfied. In user code this causes an inconsistency between the SVal and Stmt parameters of checkLocation.
Reviewers: NoQ, dcoughlin, george.karpenkov
Reviewed By: NoQ
Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D55701
llvm-svn: 350528
Summary:
Much like hasArg for various call expressions, this allows LibTooling users to
match against a member of an initializer list.
This is currently being used as part of the abseil-duration-scale clang-tidy
check.
Differential Revision: https://reviews.llvm.org/D56090
llvm-svn: 350523
Summary:
It's a new primitive for importing symbols, and should be treated like
the (previously handled) `goog.require` and `goog.forwardDeclare`.
Reviewers: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D56385
llvm-svn: 350516
Add support for distinguishing plain Gentoo distribution, and a unit
test for it. This is going to be used to introduce distro-specific
customizations in the driver code; most notably, it is going to be used
to disable -faddrsig.
Differential Revision: https://reviews.llvm.org/D56024
llvm-svn: 350027
removed
Stat cache chaining was implemented for a StatListener in the PTH writer so that
it could write out the stat information to PTH. r348266 removed support for PTH,
and it doesn't seem like there are other uses of stat cache chaining. We can
remove the chaining support.
Differential Revision: https://reviews.llvm.org/D55455
llvm-svn: 349942
Summary:
There are certain cases when normal C/C++ lookup (localUncachedLookup)
does not find AST nodes. E.g.:
Example 1:
template <class T>
struct X {
friend void foo(); // this is never found in the DC of the TU.
};
Example 2:
// The fwd decl to Foo is not found in the lookupPtr of the DC of the
// translation unit decl.
struct A { struct Foo *p; };
In these cases we create a new node instead of returning with the old one.
To fix it we create a new lookup table which holds every node and we are
not interested in any C++ specific visibility considerations.
Simply, we must know if there is an existing Decl in a given DC.
Reviewers: a_sidorin, a.sidorin
Subscribers: mgorny, rnkovacs, dkrupp, Szelethus, cfe-commits
Differential Revision: https://reviews.llvm.org/D53708
llvm-svn: 349351
Summary:
The crux of the issue that is being fixed is that lookup could not find
previous decls of a friend class. The solution involves making the
friend declarations visible in their decl context (i.e. adding them to
the lookup table).
Also, we simplify `VisitRecordDecl` greatly.
This fix involves two other repairs (without these the unittests fail):
(1) We could not handle the addition of injected class types properly
when a redecl chain was involved, now this is fixed.
(2) DeclContext::removeDecl failed if the lookup table in Vector form
did not contain the to be removed element. This caused troubles in
ASTImporter::ImportDeclContext. This is also fixed.
Reviewers: a_sidorin, balazske, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, cfe-commits
Differential Revision: https://reviews.llvm.org/D53655
llvm-svn: 349349
ClangCheckerRegistry is a very non-obvious, poorly documented, weird concept.
It derives from CheckerRegistry, and is placed in lib/StaticAnalyzer/Frontend,
whereas it's base is located in lib/StaticAnalyzer/Core. It was, from what I can
imagine, used to circumvent the problem that the registry functions of the
checkers are located in the clangStaticAnalyzerCheckers library, but that
library depends on clangStaticAnalyzerCore. However, clangStaticAnalyzerFrontend
depends on both of those libraries.
One can make the observation however, that CheckerRegistry has no place in Core,
it isn't used there at all! The only place where it is used is Frontend, which
is where it ultimately belongs.
This move implies that since
include/clang/StaticAnalyzer/Checkers/ClangCheckers.h only contained a single function:
class CheckerRegistry;
void registerBuiltinCheckers(CheckerRegistry ®istry);
it had to re purposed, as CheckerRegistry is no longer available to
clangStaticAnalyzerCheckers. It was renamed to BuiltinCheckerRegistration.h,
which actually describes it a lot better -- it does not contain the registration
functions for checkers, but only those generated by the tblgen files.
Differential Revision: https://reviews.llvm.org/D54436
llvm-svn: 349275
Duncan P. N. Exon Smith