|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6 |
|
| #
ca4af13e |
| 21-Jun-2022 |
Kazu Hirata <[email protected]> |
[clang] Don't use Optional::getValue (NFC)
|
|
Revision tags: llvmorg-14.0.5 |
|
| #
9d6d069f |
| 08-Jun-2022 |
Andy Soffer <[email protected]> |
Add a parameter to LoadFromASTFile that accepts a file system and defaults to the real file-system.
Reviewed By: ymandel
Differential Revision: https://reviews.llvm.org/D126888
|
|
Revision tags: llvmorg-14.0.4 |
|
| #
00a3c9f2 |
| 07-May-2022 |
Sam McCall <[email protected]> |
[Frontend] Flip default of CreateInvocationOptions::ProbePrecompiled to false
This is generally a better default for tools other than the compiler, which
shouldn't assume a PCH file on disk is somet
[Frontend] Flip default of CreateInvocationOptions::ProbePrecompiled to false
This is generally a better default for tools other than the compiler, which
shouldn't assume a PCH file on disk is something they can consume.
Preserve the old behavior in places associated with libclang/c-index-test
(including ASTUnit) as there are tests relying on it and most important
consumers are out-of-tree. It's unclear whether the tests are specifically
trying to test this functionality, and what the downstream implications of
removing it are. Hopefully someone more familiar can clean this up in future.
Differential Revision: https://reviews.llvm.org/D125149
show more ...
|
| #
499d0b96 |
| 05-May-2022 |
Sam McCall <[email protected]> |
[clang] createInvocationFromCommandLine -> createInvocation, delete former. NFC
(Followup from 40c13720a4b977d4347bbde53c52a4d0703823c2)
Differential Revision: https://reviews.llvm.org/D125012
|
|
Revision tags: llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
| #
17d4bd3d |
| 09-Jan-2022 |
Kazu Hirata <[email protected]> |
[clang] Fix bugprone argument comments (NFC)
Identified with bugprone-argument-comment.
|
| #
92417eaf |
| 27-Dec-2021 |
Sam McCall <[email protected]> |
[CodeCompletion] Signature help for braced constructor calls
Implementation is based on the "expected type" as used for
designated-initializers in braced init lists. This means it can deduce the typ
[CodeCompletion] Signature help for braced constructor calls
Implementation is based on the "expected type" as used for
designated-initializers in braced init lists. This means it can deduce the type
in some cases where it's not written:
void foo(Widget);
foo({ /*help here*/ });
Only basic constructor calls are in scope of this patch, excluded are:
- aggregate initialization (no help is offered for aggregates)
- initializer_list initialization (no help is offered for these constructors)
Fixes https://github.com/clangd/clangd/issues/306
Differential Revision: https://reviews.llvm.org/D116317
show more ...
|
|
Revision tags: llvmorg-13.0.1-rc1 |
|
| #
d245f2e8 |
| 17-Oct-2021 |
Kazu Hirata <[email protected]> |
[clang] Use llvm::erase_if (NFC)
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2 |
|
| #
ece4e920 |
| 07-Aug-2021 |
Sam McCall <[email protected]> |
[CodeComplete] Basic code completion for attribute names.
Only the bare name is completed, with no args.
For args to be useful we need arg names. These *are* in the tablegen but
not currently emitte
[CodeComplete] Basic code completion for attribute names.
Only the bare name is completed, with no args.
For args to be useful we need arg names. These *are* in the tablegen but
not currently emitted in usable form, so left this as future work.
C++11, C2x, GNU, declspec, MS syntax is supported, with the appropriate
spellings of attributes suggested.
`#pragma clang attribute` is supported but not terribly useful as we
only reach completion if parens are balanced (i.e. the line is not truncated)
There's no filtering of which attributes might make sense in this
grammatical context (e.g. attached to a function). In code-completion context
this is hard to do, and will only work in few cases :-(
There's also no filtering by langopts: this is because currently the
only way of checking is to try to produce diagnostics, which requires a
valid ParsedAttr which is hard to get.
This should be fairly simple to fix but requires some tablegen changes
to expose the logic without the side-effect.
Differential Revision: https://reviews.llvm.org/D107696
show more ...
|
|
Revision tags: llvmorg-13.0.0-rc1, llvmorg-14-init |
|
| #
11b47c10 |
| 12-Jul-2021 |
Vassil Vassilev <[email protected]> |
Reland "[clang-repl] Implement partial translation units and error recovery."
Original commit message:
[clang-repl] Implement partial translation units and error recovery.
https://reviews.llvm.org
Reland "[clang-repl] Implement partial translation units and error recovery."
Original commit message:
[clang-repl] Implement partial translation units and error recovery.
https://reviews.llvm.org/D96033 contained a discussion regarding efficient
modeling of error recovery. @rjmccall has outlined the key ideas:
Conceptually, we can split the translation unit into a sequence of partial
translation units (PTUs). Every declaration will be associated with a unique PTU
that owns it.
The first key insight here is that the owning PTU isn't always the "active"
(most recent) PTU, and it isn't always the PTU that the declaration
"comes from". A new declaration (that isn't a redeclaration or specialization of
anything) does belong to the active PTU. A template specialization, however,
belongs to the most recent PTU of all the declarations in its signature - mostly
that means that it can be pulled into a more recent PTU by its template
arguments.
The second key insight is that processing a PTU might extend an earlier PTU.
Rolling back the later PTU shouldn't throw that extension away. For example, if
the second PTU defines a template, and the third PTU requires that template to
be instantiated at float, that template specialization is still part of the
second PTU. Similarly, if the fifth PTU uses an inline function belonging to the
fourth, that definition still belongs to the fourth. When we go to emit code in
a new PTU, we map each declaration we have to emit back to its owning PTU and
emit it in a new module for just the extensions to that PTU. We keep track of
all the modules we've emitted for a PTU so that we can unload them all if we
decide to roll it back.
Most declarations/definitions will only refer to entities from the same or
earlier PTUs. However, it is possible (primarily by defining a
previously-declared entity, but also through templates or ADL) for an entity
that belongs to one PTU to refer to something from a later PTU. We will have to
keep track of this and prevent unwinding to later PTU when we recognize it.
Fortunately, this should be very rare; and crucially, we don't have to do the
bookkeeping for this if we've only got one PTU, e.g. in normal compilation.
Otherwise, PTUs after the first just need to record enough metadata to be able
to revert any changes they've made to declarations belonging to earlier PTUs,
e.g. to redeclaration chains or template specialization lists.
It should even eventually be possible for PTUs to provide their own slab
allocators which can be thrown away as part of rolling back the PTU. We can
maintain a notion of the active allocator and allocate things like Stmt/Expr
nodes in it, temporarily changing it to the appropriate PTU whenever we go to do
something like instantiate a function template. More care will be required when
allocating declarations and types, though.
We would want the PTU to be efficiently recoverable from a Decl; I'm not sure
how best to do that. An easy option that would cover most declarations would be
to make multiple TranslationUnitDecls and parent the declarations appropriately,
but I don't think that's good enough for things like member function templates,
since an instantiation of that would still be parented by its original class.
Maybe we can work this into the DC chain somehow, like how lexical DCs are.
We add a different kind of translation unit `TU_Incremental` which is a
complete translation unit that we might nonetheless incrementally extend later.
Because it is complete (and we might want to generate code for it), we do
perform template instantiation, but because it might be extended later, we don't
warn if it declares or uses undefined internal-linkage symbols.
This patch teaches clang-repl how to recover from errors by disconnecting the
most recent PTU and update the primary PTU lookup tables. For instance:
```./clang-repl
clang-repl> int i = 12; error;
In file included from <<< inputs >>>:1:
input_line_0:1:13: error: C++ requires a type specifier for all declarations
int i = 12; error;
^
error: Parsing failed.
clang-repl> int i = 13; extern "C" int printf(const char*,...);
clang-repl> auto r1 = printf("i=%d\n", i);
i=13
clang-repl> quit
```
Differential revision: https://reviews.llvm.org/D104918
show more ...
|
| #
5922f234 |
| 11-Jul-2021 |
Vassil Vassilev <[email protected]> |
Revert "[clang-repl] Implement partial translation units and error recovery."
This reverts commit 6775fc6ffa3ca1c36b20c25fa4e7f48f81213cf2.
It also reverts "[lldb] Fix compilation by adjusting to t
Revert "[clang-repl] Implement partial translation units and error recovery."
This reverts commit 6775fc6ffa3ca1c36b20c25fa4e7f48f81213cf2.
It also reverts "[lldb] Fix compilation by adjusting to the new ASTContext signature."
This reverts commit 03a3f86071c10a1f6cbbf7375aa6fe9d94168972.
We see some failures on the lldb infrastructure, these changes might play a role
in it. Let's revert it now and see if the bots will become green.
Ref: https://reviews.llvm.org/D104918
show more ...
|
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
| #
6775fc6f |
| 12-May-2021 |
Vassil Vassilev <[email protected]> |
[clang-repl] Implement partial translation units and error recovery.
https://reviews.llvm.org/D96033 contained a discussion regarding efficient
modeling of error recovery. @rjmccall has outlined the
[clang-repl] Implement partial translation units and error recovery.
https://reviews.llvm.org/D96033 contained a discussion regarding efficient
modeling of error recovery. @rjmccall has outlined the key ideas:
Conceptually, we can split the translation unit into a sequence of partial
translation units (PTUs). Every declaration will be associated with a unique PTU
that owns it.
The first key insight here is that the owning PTU isn't always the "active"
(most recent) PTU, and it isn't always the PTU that the declaration
"comes from". A new declaration (that isn't a redeclaration or specialization of
anything) does belong to the active PTU. A template specialization, however,
belongs to the most recent PTU of all the declarations in its signature - mostly
that means that it can be pulled into a more recent PTU by its template
arguments.
The second key insight is that processing a PTU might extend an earlier PTU.
Rolling back the later PTU shouldn't throw that extension away. For example, if
the second PTU defines a template, and the third PTU requires that template to
be instantiated at float, that template specialization is still part of the
second PTU. Similarly, if the fifth PTU uses an inline function belonging to the
fourth, that definition still belongs to the fourth. When we go to emit code in
a new PTU, we map each declaration we have to emit back to its owning PTU and
emit it in a new module for just the extensions to that PTU. We keep track of
all the modules we've emitted for a PTU so that we can unload them all if we
decide to roll it back.
Most declarations/definitions will only refer to entities from the same or
earlier PTUs. However, it is possible (primarily by defining a
previously-declared entity, but also through templates or ADL) for an entity
that belongs to one PTU to refer to something from a later PTU. We will have to
keep track of this and prevent unwinding to later PTU when we recognize it.
Fortunately, this should be very rare; and crucially, we don't have to do the
bookkeeping for this if we've only got one PTU, e.g. in normal compilation.
Otherwise, PTUs after the first just need to record enough metadata to be able
to revert any changes they've made to declarations belonging to earlier PTUs,
e.g. to redeclaration chains or template specialization lists.
It should even eventually be possible for PTUs to provide their own slab
allocators which can be thrown away as part of rolling back the PTU. We can
maintain a notion of the active allocator and allocate things like Stmt/Expr
nodes in it, temporarily changing it to the appropriate PTU whenever we go to do
something like instantiate a function template. More care will be required when
allocating declarations and types, though.
We would want the PTU to be efficiently recoverable from a Decl; I'm not sure
how best to do that. An easy option that would cover most declarations would be
to make multiple TranslationUnitDecls and parent the declarations appropriately,
but I don't think that's good enough for things like member function templates,
since an instantiation of that would still be parented by its original class.
Maybe we can work this into the DC chain somehow, like how lexical DCs are.
We add a different kind of translation unit `TU_Incremental` which is a
complete translation unit that we might nonetheless incrementally extend later.
Because it is complete (and we might want to generate code for it), we do
perform template instantiation, but because it might be extended later, we don't
warn if it declares or uses undefined internal-linkage symbols.
This patch teaches clang-repl how to recover from errors by disconnecting the
most recent PTU and update the primary PTU lookup tables. For instance:
```./clang-repl
clang-repl> int i = 12; error;
In file included from <<< inputs >>>:1:
input_line_0:1:13: error: C++ requires a type specifier for all declarations
int i = 12; error;
^
error: Parsing failed.
clang-repl> int i = 13; extern "C" int printf(const char*,...);
clang-repl> auto r1 = printf("i=%d\n", i);
i=13
clang-repl> quit
```
Differential revision: https://reviews.llvm.org/D104918
show more ...
|
| #
aaba3718 |
| 29-Jun-2021 |
Melanie Blower <[email protected]> |
[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.o
[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D104729
show more ...
|
| #
1d85d087 |
| 28-Jun-2021 |
Melanie Blower <[email protected]> |
Revert "[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options"
This reverts commit 2dbe1c675fe94eeb7973dcc25b049d25f4ca4fa0.
Mo
Revert "[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options"
This reverts commit 2dbe1c675fe94eeb7973dcc25b049d25f4ca4fa0.
More buildbot failures
show more ...
|
| #
2dbe1c67 |
| 28-Jun-2021 |
Melanie Blower <[email protected]> |
[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.o
[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D104729
show more ...
|
| #
8815ef82 |
| 28-Jun-2021 |
Melanie Blower <[email protected]> |
Revert "[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options"
This reverts commit 2c02b0c3f45414ac6c64583e006a26113c028304.
bu
Revert "[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options"
This reverts commit 2c02b0c3f45414ac6c64583e006a26113c028304.
buildbot fails
show more ...
|
| #
2c02b0c3 |
| 08-Jun-2021 |
Melanie Blower <[email protected]> |
[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.o
[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D104729
show more ...
|
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5 |
|
| #
14a7296c |
| 06-Apr-2021 |
oToToT <[email protected]> |
[clang][clangd] Avoid inconsistent target creation
As proposed in D97109, I tried to make target creation consistent in `clang` and `clangd` by replacing the original procedure with a single functio
[clang][clangd] Avoid inconsistent target creation
As proposed in D97109, I tried to make target creation consistent in `clang` and `clangd` by replacing the original procedure with a single function introduced in D97493.
This also helps `clangd` works with CUDA, OpenMP, etc.
Reviewed By: kadircet
Differential Revision: https://reviews.llvm.org/D98128
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1 |
|
| #
f4d02fbe |
| 10-Nov-2020 |
Duncan P. N. Exon Smith <[email protected]> |
Frontend: Take VFS and MainFileBuffer by reference in PrecompiledPreamble::CanReuse, NFC
Clarify that `PrecompiledPreamble::CanReuse` requires non-null arguments
for `VFS` and `MainFileBuffer`, taki
Frontend: Take VFS and MainFileBuffer by reference in PrecompiledPreamble::CanReuse, NFC
Clarify that `PrecompiledPreamble::CanReuse` requires non-null arguments
for `VFS` and `MainFileBuffer`, taking them by reference instead of by
pointer.
Differential Revision: https://reviews.llvm.org/D91297
show more ...
|
| #
b0e89906 |
| 21-Jan-2021 |
Argyrios Kyrtzidis <[email protected]> |
[ASTReader] Allow controlling separately whether validation should be disabled for a PCH vs a module file
This addresses an issue with how the PCH preable works, specifically:
1. When using a PCH/p
[ASTReader] Allow controlling separately whether validation should be disabled for a PCH vs a module file
This addresses an issue with how the PCH preable works, specifically:
1. When using a PCH/preamble the module hash changes and a different cache directory is used
2. When the preamble is used, PCH & PCM validation is disabled.
Due to combination of #1 and #2, reparsing with preamble enabled can end up loading a stale module file before a header change and using it without updating it because validation is disabled and it doesn’t check that the header has changed and the module file is out-of-date.
rdar://72611253
Differential Revision: https://reviews.llvm.org/D95159
show more ...
|
| #
c3ff9939 |
| 05-Nov-2020 |
Duncan P. N. Exon Smith <[email protected]> |
Remove RemappedFiles param from ASTUnit::LoadFromASTFile, NFC
This parameter is always set to `None`. Remove it.
Differential Revision: https://reviews.llvm.org/D90889
|
| #
51f3432f |
| 10-Nov-2020 |
Duncan P. N. Exon Smith <[email protected]> |
Frontend: Clarify logic for using the preamble in ASTUnit::CodeComplete, almost NFC
Clarify the logic for using the preamble (and overriding the main file
buffer) in `ASTUnit::CodeComplete` by facto
Frontend: Clarify logic for using the preamble in ASTUnit::CodeComplete, almost NFC
Clarify the logic for using the preamble (and overriding the main file
buffer) in `ASTUnit::CodeComplete` by factoring out a couple of lambdas
(`getUniqueID` and `hasSameUniqueID`). While refactoring the logic,
hoist the check for `Line > 1` and locally check if the filenames are
equal (both to avoid unnecessary `stat` calls) and skip copying out the
filenames to `std::string`.
Besides fewer calls to `stat`, there's no functionality change here.
Differential Revision: https://reviews.llvm.org/D91296
show more ...
|
| #
99b823c2 |
| 04-Nov-2020 |
Duncan P. N. Exon Smith <[email protected]> |
Frontend: Remove redundant call to CompilerInstance::setFileManager, NFC
`ASTUnit::Parse` sets up the `FileManager` earlier in the same function,
ensuring `ASTUnit::getFileManager()` matches `Clang-
Frontend: Remove redundant call to CompilerInstance::setFileManager, NFC
`ASTUnit::Parse` sets up the `FileManager` earlier in the same function,
ensuring `ASTUnit::getFileManager()` matches `Clang->getFileManager()`.
Remove the later call to `setFileManager(getFileManager())` since it
does nothing.
Differential Revision: https://reviews.llvm.org/D90888
show more ...
|
| #
5834996f |
| 18-Nov-2020 |
Ben Barham <[email protected]> |
[Frontend] Add flag to allow PCM generation despite compiler errors
As with precompiled headers, it's useful for indexers to be able to
continue through compiler errors in dependent modules.
Resolv
[Frontend] Add flag to allow PCM generation despite compiler errors
As with precompiled headers, it's useful for indexers to be able to
continue through compiler errors in dependent modules.
Resolves rdar://69816264
Reviewed By: akyrtzi
Differential Revision: https://reviews.llvm.org/D91580
show more ...
|
| #
cfde3ede |
| 08-Nov-2020 |
Duncan P. N. Exon Smith <[email protected]> |
Frontend: Remove unused parameter from ASTUnit::LoadFromCompilerInvocationAction, NFC
Drop `IncludeBriefCommentsInCodeCompletion` since it is always `false`.
Differential Revision: https://reviews.
Frontend: Remove unused parameter from ASTUnit::LoadFromCompilerInvocationAction, NFC
Drop `IncludeBriefCommentsInCodeCompletion` since it is always `false`.
Differential Revision: https://reviews.llvm.org/D91295
show more ...
|
| #
4c55c3b6 |
| 05-Nov-2020 |
Duncan P. N. Exon Smith <[email protected]> |
Frontend: Change ComputePreambleBounds to take MemoryBufferRef, NFC
Avoid requiring an actual MemoryBuffer in ComputePreambleBounds, when
a MemoryBufferRef will do just fine.
Differential Revision:
Frontend: Change ComputePreambleBounds to take MemoryBufferRef, NFC
Avoid requiring an actual MemoryBuffer in ComputePreambleBounds, when
a MemoryBufferRef will do just fine.
Differential Revision: https://reviews.llvm.org/D90890
show more ...
|