Before:
```
(lldb) expression some_template_func<int, long>(5)
˄
╰─ error: 'some_template_func' does not name a template but is followed by template arguments
note: Ran expression as 'C++14'.
note: note: non-template declaration found by name lookup
```
After:
```
(lldb) expression some_template_func<int, long>(5)
˄
╰─ error: 'some_template_func' does not name a template but is followed by template arguments
note: Ran expression as 'C++14'.
note: note: non-template declaration found by name lookup
note: Naming template instantiation not yet supported. Template functions can be invoked via their mangled name. E.g., expression _Z3fooIiEvi(5)
```
There isn't a great way to get to the actual function being named (and
its mangled name) since we're just dealing with raw text. So I just
print an example mangled name.
This doesn't work for all template instantiations. E.g.,:
```
(lldb) p f.method<long>(10)
˄ ˄
│ ╰─ error: expected '(' for function-style cast or type construction
╰─ error: no member named 'method' in 'Foo<int>'
note: Ran expression as 'C++14'.
```
This is a consequence of how we construct the AST for template methods.
Once we fix that, this hint will get emitted there too.
Note this will also trigger in cases where no function is being called
(hence I used the defensive phrase "Template functions can be invoked").
rdar://135725807
Depends on:
* https://github.com/llvm/llvm-project/pull/177921
* https://github.com/llvm/llvm-project/pull/177926
(only last commit is relevant for this review)
This patch emits a workaround suggestion (in the form of a `note:`
diagnostic) when an expression fails due to trying to mutate state/call
functions with CV-qualifiers that are disallowed by C++ language rules
based on the context the expression is evaluated in. The note looks as
follows:
```
(lldb) expr next.method()
˄
╰─ error: 'this' argument to member function 'method' has type 'const Bar', but function is not marked const
note: Ran expression as 'C++14'.
note: note: 'method' declared here
note: Possibly trying to mutate object in a const context. Try running the expression with: expression --c++-ignore-context-qualifiers -- <your expression>
```
We stopped marking `__lldb_expr` with the function qualifiers of the
method LLDB is stopped in ever since
`8bdcd522510f923185cdfaec66c4a78d0a0d38c0`. The assumption was that it
wasn't ever required for correctness (i.e., LLDB should just always
pretend it's in a mutable context). But since function qualifiers affect
overloading in C++, this assumption can lead to unexpected expression
evaluator behaviour. E.g., if a function is overloaded on qualifiers
(`const` vs. `non-const`), the expression evaluator would currently
always call the non-CV qualified overload.
This patch adds function qualifiers to `$__lldb_class::$__lldb_expr`
that resemble the qualifiers of the method that we're stopped in.
However, mutating variables or calling arbitrary member functions from
CV-qualified methods can be useful/is something users already may be
used to. To provide users with the ability to ignore the CV-qualifiers
of the current context, we will provide an expression evaluator flag
that switches this off in a follow-up patch.
Introducing `llvm::createStringErrorV` caused a `0.5%` compile-time
regression because it's an inline function in a core header. This moves
the API to a new header to prevent including this function in files that
don't need it.
Also includes the header in the source files that have been using
`createStringErrorV` (which currently is just LLDB).
Essentially, figuring out how to use `CodeGenerator` was very confusing
to me and I figured the API could be improved a bit, so:
- the `CodeGenerator` ctor is now protected since an instance of
`CodeGenerator` that is not a `CodeGeneratorImpl` is a bit useless (and
deriving from it and implementing it yourself honestly just defeats the
point of using this to begin with);
- `ReleaseModule()` releases ownership of the module, so it should
return a `unique_ptr`;
- `CreateLLVMCodeGen()` also returns a `unique_ptr` now;
- added a `CreateLLVMCodeGen()` overload that takes a
`CompilerInstance&` and uses some of its state instead of requiring the
user to pass everything in manually; this is consistent w/ other parts
of our API, and most uses of this function in the codebase can be
refactored to use that overload instead (and a code search I did also
showed that a lot of people that use this API also just use the state
from a `CompilerInstance`).
I should have liked to replace `CreateLLVMCodeGen` w/
`CodeGenerator::Create`, but there are a lot of uses of
`CreateLLVMCodeGen()` in the wild, so the only thing we could do is keep
`CreateLLVMCodeGen()` and deprecate it, and at that point I don’t think
it’s really worth it; I added a comment to the `CodeGenerator()`
constructor declaration that points to it though.
Fixes#172169.
I've been trying to wrap my head around this code but there's a lot of
action-at-a-distance going on which I'm having trouble following. This
patch cleans up a small part of it.
We were passing the `context`s namespace map as a separate mutable
argument. But nothing in this function requires it to be mutable (and
separate from the owning structure). This patch drops the redundant
argument and passes the shared_ptr by value.
We fall back to `Objective-C++` when running C++ expressions in frames
that don't have debug-info. But we were missing a fallback note for this
situation. We would now print following note on expression error:
```
note: Possibly stopped inside system library, so speculatively enabled Objective-C. Ran expression as 'Objective C++'.
```
When you run an expression and the result has a dynamic type that is
different from the expression's static result type, we print the result
variable using the dynamic type, but at present when you use the result
variable in an expression later on, we only give you access to the
static type. For instance:
```
(lldb) expr MakeADerivedReportABase()
(Derived *) $0 = 0x00000001007e93e0
(lldb) expr $0->method_from_derived()
^
error: no member named 'method_from_derived' in 'Base'
(lldb)
```
The static return type of that function is `Base *`, but we printed that
the result was a `Derived *` and then only used the `Base *` part of it
in subsequent expressions. That's not very helpful, and forces you to
guess and then cast the result types to their dynamic type in order to
be able to access the full type you were returned, which is
inconvenient.
This patch makes lldb retain the dynamic type of the result variable
(and ditto for persistent result variables).
It also adds more testing of expression result variables with various
types of dynamic values, to ensure we can access both the ivars and
methods of the type we print the result as.
This relands #165277 by reverting #169397.
This also relands the corresponding Bazel port by reverting #169410.
The original revert was due to a report of a broken build, which was
later resolved by fully clearing the build directory.
This removes the dependency on clangDriver from clangFrontend and
flangFrontend.
This refactoring is part of a broader effort to support driver-managed
builds for compilations using C++ named modules and/or Clang modules.
It is required for linking the dependency scanning tooling against the
driver without introducing cyclic dependencies, which would otherwise
cause build failures when dynamic linking is enabled.
In particular, clangFrontend must no longer depend on clangDriver
for this to be possible.
This change was discussed in the following RFC:
https://discourse.llvm.org/t/rfc-new-clangoptions-library-remove-dependency-on-clangdriver-from-clangfrontend-and-flangfrontend/88773
d076608d58d1ec55016eb747a995511e3a3f72aa moved some deps around to avoid
cycles and left clang/Frontend/FrontendDiagnostic.h as a shim that
simply includes clang/Basic/DiagnosticFrontend.h. This PR inlines it so
that nothing in tree still includes clang/Frontend/FrontendDiagnostic.h.
Doing this will help prevent future layering issues. See #162865.
Frontend already depends on Basic, so no new deps need to be added
anywhere except for places that do strict dep checking.
This aligns `ClangDiagnosticManagerAdapter` with how we set up the
diagnostics in `ClangModulesDeclVendor`. We fixed lifetime issues around
the same kind of setup here:
https://github.com/llvm/llvm-project/pull/167724
This class didn't suffer from the same lifetime issue because it used
`shared_ptr`s. So the stream wasn't freed before
`~TextDiagnosticPrinter` accessing it. But that begged the question of
why these are `shared_ptr`s in the first place. This patch makes these
`unique_ptr`s and fixes the destruction order that would now be an
issue.
This got exposed by `09262656f32ab3f2e1d82e5342ba37eecac52522`.
The underlying stream of `m_os` is referenced by the `TextDiagnostic`
member of `TextDiagnosticPrinter`. It got turned into a
`llvm::formatted_raw_ostream` in the commit above. When
`~TextDiagnosticPrinter` (and thus `~TextDiagnostic`) is invoked, we now
call `~formatted_raw_ostream`, which tries to access the underlying
stream. But `m_os` was already deleted because it is earlier in the
order of destruction in `TextDiagnosticPrinter`. Move the `m_os` member
before the `TextDiagnosticPrinter` to avoid a use-after-free.
Drive-by:
* Also move the `m_output` member which the `m_os` holds a reference to.
The fact it's a reference indicates the expectation is most likely that
the string outlives the stream.
The ASAN macOS bot is currently failing with this:
```
08:15:39 =================================================================
08:15:39 ==61103==ERROR: AddressSanitizer: heap-use-after-free on address 0x60600012cf40 at pc 0x00012140d304 bp 0x00016eecc850 sp 0x00016eecc848
08:15:39 READ of size 8 at 0x60600012cf40 thread T0
08:15:39 #0 0x00012140d300 in llvm::formatted_raw_ostream::releaseStream() FormattedStream.h:205
08:15:39 #1 0x00012140d3a4 in llvm::formatted_raw_ostream::~formatted_raw_ostream() FormattedStream.h:145
08:15:39 #2 0x00012604abf8 in clang::TextDiagnostic::~TextDiagnostic() TextDiagnostic.cpp:721
08:15:39 #3 0x00012605dc80 in clang::TextDiagnosticPrinter::~TextDiagnosticPrinter() TextDiagnosticPrinter.cpp:30
08:15:39 #4 0x00012605dd5c in clang::TextDiagnosticPrinter::~TextDiagnosticPrinter() TextDiagnosticPrinter.cpp:27
08:15:39 #5 0x0001231fb210 in (anonymous namespace)::StoringDiagnosticConsumer::~StoringDiagnosticConsumer() ClangModulesDeclVendor.cpp:47
08:15:39 #6 0x0001231fb3bc in (anonymous namespace)::StoringDiagnosticConsumer::~StoringDiagnosticConsumer() ClangModulesDeclVendor.cpp:47
08:15:39 #7 0x000129aa9d70 in clang::DiagnosticsEngine::~DiagnosticsEngine() Diagnostic.cpp:91
08:15:39 #8 0x0001230436b8 in llvm::RefCountedBase<clang::DiagnosticsEngine>::Release() const IntrusiveRefCntPtr.h:103
08:15:39 #9 0x0001231fe6c8 in (anonymous namespace)::ClangModulesDeclVendorImpl::~ClangModulesDeclVendorImpl() ClangModulesDeclVendor.cpp:93
08:15:39 #10 0x0001231fe858 in (anonymous namespace)::ClangModulesDeclVendorImpl::~ClangModulesDeclVendorImpl() ClangModulesDeclVendor.cpp:93
...
08:15:39
08:15:39 0x60600012cf40 is located 32 bytes inside of 56-byte region [0x60600012cf20,0x60600012cf58)
08:15:39 freed by thread T0 here:
08:15:39 #0 0x0001018abb88 in _ZdlPv+0x74 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x4bb88)
08:15:39 #1 0x0001231fb1c0 in (anonymous namespace)::StoringDiagnosticConsumer::~StoringDiagnosticConsumer() ClangModulesDeclVendor.cpp:47
08:15:39 #2 0x0001231fb3bc in (anonymous namespace)::StoringDiagnosticConsumer::~StoringDiagnosticConsumer() ClangModulesDeclVendor.cpp:47
08:15:39 #3 0x000129aa9d70 in clang::DiagnosticsEngine::~DiagnosticsEngine() Diagnostic.cpp:91
08:15:39 #4 0x0001230436b8 in llvm::RefCountedBase<clang::DiagnosticsEngine>::Release() const IntrusiveRefCntPtr.h:103
08:15:39 #5 0x0001231fe6c8 in (anonymous namespace)::ClangModulesDeclVendorImpl::~ClangModulesDeclVendorImpl() ClangModulesDeclVendor.cpp:93
08:15:39 #6 0x0001231fe858 in (anonymous namespace)::ClangModulesDeclVendorImpl::~ClangModulesDeclVendorImpl() ClangModulesDeclVendor.cpp:93
...
08:15:39
08:15:39 previously allocated by thread T0 here:
08:15:39 #0 0x0001018ab760 in _Znwm+0x74 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x4b760)
08:15:39 #1 0x0001231f8dec in lldb_private::ClangModulesDeclVendor::Create(lldb_private::Target&) ClangModulesDeclVendor.cpp:732
08:15:39 #2 0x00012320af58 in lldb_private::ClangPersistentVariables::GetClangModulesDeclVendor() ClangPersistentVariables.cpp:124
08:15:39 #3 0x0001232111f0 in lldb_private::ClangUserExpression::PrepareForParsing(lldb_private::DiagnosticManager&, lldb_private::ExecutionContext&, bool) ClangUserExpression.cpp:536
08:15:39 #4 0x000123213790 in lldb_private::ClangUserExpression::Parse(lldb_private::DiagnosticManager&, lldb_private::ExecutionContext&, lldb_private::ExecutionPolicy, bool, bool) ClangUserExpression.cpp:647
08:15:39 #5 0x00012032b258 in lldb_private::UserExpression::Evaluate(lldb_private::ExecutionContext&, lldb_private::EvaluateExpressionOptions const&, llvm::StringRef, llvm::StringRef, std::__1::shared_ptr<lldb_private::ValueObject>&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*, lldb_private::ValueObject*) UserExpression.cpp:280
08:15:39 #6 0x000120724010 in lldb_private::Target::EvaluateExpression(llvm::StringRef, lldb_private::ExecutionContextScope*, std::__1::shared_ptr<lldb_private::ValueObject>&, lldb_private::EvaluateExpressionOptions const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*, lldb_private::ValueObject*) Target.cpp:2905
08:15:39 #7 0x00011fc7bde0 in lldb::SBTarget::EvaluateExpression(char const*, lldb::SBExpressionOptions const&) SBTarget.cpp:2305
08:15:39 ==61103==ABORTING
...
```
Depends on:
* https://github.com/llvm/llvm-project/pull/166917
* https://github.com/llvm/llvm-project/pull/166940
While these errors can contribute to an expression failing, they are
never *the* reason the expression failed. I.e., they are always just
'note:' diagnostics that we hand-emit. Because they are quite noisy (and
we potentially have many of them if we auto-load all modules in a CU),
this patch logs the errors to the `expr` log, instead of the console.
Previously these errors would only get omitted when the expression
itself failed. Meaning if the expression failed, we'd dump these 'note'
module load errors in next to the actual expression error, obscuring the
output. Moreover, if the expression succeeded, any module load errors
would be dropped. Now we always log all module loading errors to the
expression log, regardless of whether the expression fails or not.
Depends on:
* https://github.com/llvm/llvm-project/pull/166917
When loading all Clang modules for a CU, we stop on first error. This
means benign module loading errors may stop us from importing actually
useful modules. There's no good reason to bail on the first one. The
pathological case would be if we try to load a large number of Clang
modules
but all fail to load for the same reason. That could happen, but in
practice I've always seen only a handful of modules failing to load out
of a large number. Particularly system modules are useful and usually
don't fail to load. Whereas project-specific Clang modules are more
likely to fail because the build system moves the modulemap/sources
around.
This patch accumulates all module loading errors and doesn't stop when
an error is encountered.
Instead of propagating the errors as a `bool`+`Stream` we change the
`ClangModulesDeclVendor` module loading APIs to use `llvm::Error`. We
also reword some of the diagnostics (notably removing the hardcoded
`error:` prefix). A follow-up patch will further make the module loading
errors less noisy.
See the new tests for what the errors look like.
rdar://164002569
This avoids unintentional comparisons between `SourceLanguage` and
`LanguageType`.
Also marks `operator bool` explicit so we don't implicitly convert to
bool.
Since https://github.com/llvm/llvm-project/pull/158381 the
`CompilerInstance` is aware of the VFS and co-owns it. To reduce scope
of that PR, the VFS was being inherited from the `FileManager` during
`setFileManager()` if it wasn't configured before. However, the
implementation of that setter was buggy. This PR fixes the bug, and
moves us closer to the long-term goal of `CompilerInstance` requiring
the VFS to be configured explicitly and owned by the instance.
The `ClangDeclVendor` used to contain more Clang-specific code than it
does nowadays. But at this point, all it does is wrap the
`DeclVendor::FindDecls` call and copy the resulting decls into
`std::vector<clang::NamedDecl*>`. I.e., it converts the generic
`CompilerDecl`s to `clang::NamedDecl*`s.
In my opinion at this point it doesn't do enough to justify making it
part of the `DeclVendor` hierarchy.
This patch removes the `ClangDeclVendor` and instead does the conversion
at callsite.
This rename was made as part of
https://github.com/llvm/llvm-project/pull/147835 in order to ease
rebasing the PR, and give a nice window for other patches to get rebased
as well.
It has been a while already, so lets go ahead and rename it back.
Depends on:
* https://github.com/llvm/llvm-project/pull/162050
Since it's a 'Note' diagnostic it would only show up when expression
evaluation actually failed. This helps with expression evaluation
failure reports in mixed language environments where it's not quite
clear what language the expression ran as. It may also reduce confusion
around why the expression evaluator ran an expression in a language it
wasn't asked to run (a softer alternative to what I attempted in
https://github.com/llvm/llvm-project/pull/156648).
Here are some example outputs:
```
# Without target
(lldb) expr blah
note: Falling back to default language. Ran expression as 'Objective C++'.
# Stopped in target
(lldb) expr blah
note: Ran expression as 'C++14'.
(lldb) expr -l objc -- blah
note: Expression evaluation in pure Objective-C not supported. Ran expression as 'Objective C++'.
(lldb) expr -l c -- blah
note: Expression evaluation in pure C not supported. Ran expression as 'ISO C++'.
(lldb) expr -l c++14 -- blah
note: Ran expression as 'C++14'
(lldb) expr -l c++20 -- blah
note: Ran expression as 'C++20'
(lldb) expr -l objective-c++ -- blah
note: Ran expression as 'Objective C++'
(lldb) expr -l D -- blah
note: Expression evaluation in D not supported. Falling back to default language. Ran expression as 'Objective C++'.
```
I didn't put the diagnostic on the same line as the inline diagnostic
for now because of implementation convenience, but if reviewers deem
that a blocker I can take a stab at that again.
Also, other language plugins (namely Swift), won't immediately benefit
from this and will have to emit their own diagnistc. I played around
with having a virtual API on `UserExpression` or `ExpressionParser` that
will be called consistently, but by the time we're about to parse the
expression we are already several frames deep into the plugin. Before
(and at the beginning of) the generic `UserExpression::Parse` call we
don't have enough information to notify which language we're going to
parse in (at least for the C++ plugin).
rdar://160297649
rdar://159669244
The `CompilerInstance::createSourceManager()` function currently accepts
the `FileManager` to be used. However, all clients call
`CompilerInstance::createFileManager()` prior to creating the
`SourceManager`, and it never makes sense to use a `FileManager` in the
`SourceManager` that's different from the rest of the compiler. Passing
the `FileManager` explicitly is redundant, error-prone, and deviates
from the style of other `CompilerInstance` initialization APIs.
This PR therefore removes the `FileManager` parameter from
`createSourceManager()` and also stops returning the `FileManager`
pointer from `createFileManager()`, since that was its primary use. Now,
`createSourceManager()` internally calls `getFileManager()` instead.
This PR changes `llvm::FileCollector` to use the `llvm::vfs::FileSystem`
API for making file paths absolute instead of using
`llvm::sys::fs::make_absolute()` directly. This matches the behavior of
the compiler on most other input files.
Here's an example crash that we've seen sporadically over the years:
```
0 libsystem_kernel.dylib 0x19d392388 __pthread_kill + 8
1 libsystem_pthread.dylib 0x19d3cb88c pthread_kill + 296
2 libsystem_c.dylib 0x19d29cd04 raise + 32
3 LLDB 0x112cbbc94 SignalHandler(int, __siginfo*, void*) + 324
4 libsystem_platform.dylib 0x19d4056a4 _sigtramp + 56
5 LLDB 0x110dcbd38 clang::TextDiagnosticPrinter::HandleDiagnostic(clang::DiagnosticsEngine::Level, clang::Diagnostic const&) + 1216
6 LLDB 0x110dcbd38 clang::TextDiagnosticPrinter::HandleDiagnostic(clang::DiagnosticsEngine::Level, clang::Diagnostic const&) + 1216
7 LLDB 0x10de12128 ClangDiagnosticManagerAdapter::HandleDiagnostic(clang::DiagnosticsEngine::Level, clang::Diagnostic const&) + 332
8 LLDB 0x1121eb3dc clang::DiagnosticIDs::ProcessDiag(clang::DiagnosticsEngine&) const + 200
9 LLDB 0x1121e67a0 clang::DiagnosticsEngine::EmitCurrentDiagnostic(bool) + 100
10 LLDB 0x111d766cc IsStructurallyEquivalent(clang::StructuralEquivalenceContext&, clang::FieldDecl*, clang::FieldDecl*, clang::QualType) + 1568
11 LLDB 0x111d71b54 IsStructurallyEquivalent(clang::StructuralEquivalenceContext&, clang::RecordDecl*, clang::RecordDecl*) + 2076
12 LLDB 0x111d6e448 clang::StructuralEquivalenceContext::Finish() + 204
13 LLDB 0x111d6e1e0 clang::StructuralEquivalenceContext::IsEquivalent(clang::Decl*, clang::Decl*) + 32
14 LLDB 0x111d3b788 clang::ASTNodeImporter::IsStructuralMatch(clang::Decl*, clang::Decl*, bool, bool) + 168
15 LLDB 0x111d404e0 clang::ASTNodeImporter::VisitFunctionDecl(clang::FunctionDecl*) + 1300
16 LLDB 0x111d5cae0 clang::ASTImporter::ImportImpl(clang::Decl*) + 24
17 LLDB 0x10ddf30bc lldb_private::ClangASTImporter::ASTImporterDelegate::ImportImpl(clang::Decl*) + 308
18 LLDB 0x111d48140 clang::ASTImporter::Import(clang::Decl*) + 984
19 LLDB 0x10ddee9dc lldb_private::ClangASTImporter::CopyDecl(clang::ASTContext*, clang::Decl*) + 100
20 LLDB 0x10ddfab40 lldb_private::ClangASTSource::FindExternalLexicalDecls(clang::DeclContext const*, llvm::function_ref<bool (clang::Decl::Kind)>, llvm::SmallVectorImpl<clang::Decl*>&) + 1692
21 LLDB 0x111e1cb84 clang::DeclContext::LoadLexicalDeclsFromExternalStorage() const + 180
22 LLDB 0x111e1df50 clang::DeclContext::buildLookup() + 204
23 LLDB 0x111e1dcf4 clang::DeclContext::makeDeclVisibleInContextWithFlags(clang::NamedDecl*, bool, bool) + 504
24 LLDB 0x111d3b01c clang::ASTNodeImporter::ImportDeclContext(clang::DeclContext*, bool) + 724
25 LLDB 0x111d62d10 clang::ASTImporter::ImportDefinition(clang::Decl*) + 428
26 LLDB 0x10ddf1cb0 lldb_private::ClangASTImporter::ASTImporterDelegate::ImportDefinitionTo(clang::Decl*, clang::Decl*) + 524
27 LLDB 0x10ddef3c8 (anonymous namespace)::CompleteTagDeclsScope::~CompleteTagDeclsScope() + 616
28 LLDB 0x10ddef6dc lldb_private::ClangASTImporter::DeportDecl(clang::ASTContext*, clang::Decl*) + 436
29 LLDB 0x10ddec3dc lldb_private::ASTResultSynthesizer::CommitPersistentDecls() + 236
30 LLDB 0x10de1091c lldb_private::ClangExpressionParser::ParseInternal(lldb_private::DiagnosticManager&, clang::CodeCompleteConsumer*, unsigned int, unsigned int) + 2292
31 LLDB 0x10de21238 lldb_private::ClangUserExpression::TryParse(lldb_private::DiagnosticManager&, lldb_private::ExecutionContext&, lldb_private::ExecutionPolicy, bool, bool) + 328
...
```
Here `ASTImporter::IsStructurallyEquivalent` is trying to emit a
diagnostic using `ClangExpressionParser`'s
`ClangDiagnosticManagerAdapter`. But `TextDiagnosticPrinter::TextDiag`
seems to be `nullptr`. This can only happen when we call
`HandleDiagnostic` on `ClangDiagnosticManagerAdapter` after we called
`EndSourceFile`. Specifically, it looks like when moving a type from
`Expression` AST to `Scratch` AST (in `CommitPersistentDecls`),
something went wrong, so the ASTImporter tried to emit a diagnostic, but
we already called `EndSourceFile` at that point.
This patch moves the call to `ResetManager` to before
`CommitPersistentDecls`, so if we called `HandleDiagnostic`, we would
correctly short-circuit out of it. This seems to have been intended
anyway based on this comment:
cecdff9283/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp (L200-L204)
But something must have broken that during a refactor.
I'm not 100% sure how best to test this because we need a scenario where
moving a type into the scratch AST fails, but the expression itself
succeeded.
rdar://159647906
This PR is a part of the effort to make the VFS used in the compiler
more explicit and consistent.
Instead of creating the VFS deep within the compiler (in
`CompilerInstance::createFileManager()`), clients are now required to
explicitly call `CompilerInstance::createVirtualFileSystem()` and
provide the base VFS from the outside.
This PR also helps in breaking up the dependency cycle where creating a
properly configured `DiagnosticsEngine` requires a properly configured
VFS, but creating properly configuring a VFS requires the
`DiagnosticsEngine`.
Both `CompilerInstance::create{FileManager,Diagnostics}()` now just use
the VFS already in `CompilerInstance` instead of taking one as a
parameter, making the VFS consistent across the instance sub-object.
This patch moves the `frame_lang` logic to just the logging (because
that's what it was always used for anyway). The callsites decide whether
to fall back on to the frame language or not when running the
expression.
This reintroduces `Type.h`, having earlier been renamed to `TypeBase.h`,
as a redirection to `TypeBase.h`, and redirects most users to include
the former instead.
This is a preparatory patch for being able to provide inline definitions
for `Type` methods which would otherwise cause a circular dependency
with `Decl{,CXX}.h`.
Doing these operations into their own NFC patch helps the git rename
detection logic work, preserving the history.
This patch makes clang just a little slower to build (~0.17%), just
because it makes more code indirectly include `DeclCXX.h`.
This is a preparatory patch, to be able to provide inline definitions
for `Type` functions which depend on `Decl{,CXX}.h`. As the latter also
depends on `Type.h`, this would not be possible without some
reorganizing.
Splitting this rename into its own patch allows git to track this as a
rename, and preserve all git history, and not force any code
reformatting.
A later NFC patch will reintroduce `Type.h` as redirection to
`TypeBase.h`, rewriting most places back to directly including `Type.h`
instead of `TypeBase.h`, leaving only a handful of places where this is
necessary.
Then yet a later patch will exploit this by making more stuff inline.
This patch works around an assertion that we hit in the `LambdaExpr`
constructor when we call it from `ASTNodeImporter::VisitLambdaExpr` (see
https://github.com/llvm/llvm-project/issues/149477). The lambda that we
imported doesn't have the `NumCaptures` field accurately set to the one
on the source decl. This is because in `MinimalImport` mode, we skip
importing of lambda definitions:
e21b0dd819/clang/lib/AST/ASTImporter.cpp (L2499)
In practice we have seen this assertion occur in our `import-std-module`
test-suite when libc++ headers decide to use lambdas inside inline
function bodies (the latest failure being caused by
https://github.com/llvm/llvm-project/pull/144602).
To avoid running into this whenever libc++ decides to use lambdas in
headers, this patch skips `ASTImport` of lambdas alltogether. Ideally
this would bubble up to the user or log as an error, but we swallow the
`ASTImportError`s currently. The only way this codepath is hit is when
lambdas are used inside functions in defined in the expression
evaluator, or when importing AST nodes from Clang modules. Both of these
are very niche use-cases (for now), so a workaround seemed appropriate.
This is a major change on how we represent nested name qualifications in
the AST.
* The nested name specifier itself and how it's stored is changed. The
prefixes for types are handled within the type hierarchy, which makes
canonicalization for them super cheap, no memory allocation required.
Also translating a type into nested name specifier form becomes a no-op.
An identifier is stored as a DependentNameType. The nested name
specifier gains a lightweight handle class, to be used instead of
passing around pointers, which is similar to what is implemented for
TemplateName. There is still one free bit available, and this handle can
be used within a PointerUnion and PointerIntPair, which should keep
bit-packing aficionados happy.
* The ElaboratedType node is removed, all type nodes in which it could
previously apply to can now store the elaborated keyword and name
qualifier, tail allocating when present.
* TagTypes can now point to the exact declaration found when producing
these, as opposed to the previous situation of there only existing one
TagType per entity. This increases the amount of type sugar retained,
and can have several applications, for example in tracking module
ownership, and other tools which care about source file origins, such as
IWYU. These TagTypes are lazily allocated, in order to limit the
increase in AST size.
This patch offers a great performance benefit.
It greatly improves compilation time for
[stdexec](https://github.com/NVIDIA/stdexec). For one datapoint, for
`test_on2.cpp` in that project, which is the slowest compiling test,
this patch improves `-c` compilation time by about 7.2%, with the
`-fsyntax-only` improvement being at ~12%.
This has great results on compile-time-tracker as well:
This patch also further enables other optimziations in the future, and
will reduce the performance impact of template specialization resugaring
when that lands.
It has some other miscelaneous drive-by fixes.
About the review: Yes the patch is huge, sorry about that. Part of the
reason is that I started by the nested name specifier part, before the
ElaboratedType part, but that had a huge performance downside, as
ElaboratedType is a big performance hog. I didn't have the steam to go
back and change the patch after the fact.
There is also a lot of internal API changes, and it made sense to remove
ElaboratedType in one go, versus removing it from one type at a time, as
that would present much more churn to the users. Also, the nested name
specifier having a different API avoids missing changes related to how
prefixes work now, which could make existing code compile but not work.
How to review: The important changes are all in
`clang/include/clang/AST` and `clang/lib/AST`, with also important
changes in `clang/lib/Sema/TreeTransform.h`.
The rest and bulk of the changes are mostly consequences of the changes
in API.
PS: TagType::getDecl is renamed to `getOriginalDecl` in this patch, just
for easier to rebasing. I plan to rename it back after this lands.
Fixes#136624
Fixes https://github.com/llvm/llvm-project/issues/43179
Fixes https://github.com/llvm/llvm-project/issues/68670
Fixes https://github.com/llvm/llvm-project/issues/92757
This commit handles the following types:
- clang::ExternalASTSource
- clang::TargetInfo
- clang::ASTContext
- clang::SourceManager
- clang::FileManager
Part of cleanup #151026
Handles clang::DiagnosticsEngine and clang::DiagnosticIDs.
For DiagnosticIDs, this mostly migrates from `new DiagnosticIDs` to
convenience method `DiagnosticIDs::create()`.
Part of cleanup https://github.com/llvm/llvm-project/issues/151026
This switches to `makeIntrusiveRefCnt<FileSystem>` where creating a new
object, and to passing/returning by `IntrusiveRefCntPtr<FileSystem>`
instead of `FileSystem*` or `FileSystem&`, when dealing with existing
objects.
Part of cleanup #151026.
Split out from https://github.com/llvm/llvm-project/pull/148877
This patch prepares `TypeSystemClang` APIs to take `AsmLabel`s which
concatenated strings (hence `std::string`) instead of a plain `const
char*`.
This is a continuation of 68fd102, which did the same thing but only for
StopInfo. Using make_shared is both safer and more efficient:
- With make_shared, the object and the control block are allocated
together, which is more efficient.
- With make_shared, the enable_shared_from_this base class is properly
linked to the control block before the constructor finishes, so
shared_from_this() will be safe to use (though still not recommended
during construction).
