Revision tags: llvmorg-21-init |
|
#
263fed7c |
| 17-Jan-2025 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
[AST] Add OriginalDC argument to ExternalASTSource::FindExternalVisibleDeclsByName (#123152)
Part for relanding https://github.com/llvm/llvm-project/pull/122887.
I split this to test where the pe
[AST] Add OriginalDC argument to ExternalASTSource::FindExternalVisibleDeclsByName (#123152)
Part for relanding https://github.com/llvm/llvm-project/pull/122887.
I split this to test where the performance regession comes from if
modules are not used.
show more ...
|
#
731db2a0 |
| 16-Jan-2025 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
Revert "[C++20] [Modules] Support module level lookup (#122887)"
This reverts commit 7201cae106260aeb3e9bbbb7d5291ff30f05076a.
|
#
7201cae1 |
| 15-Jan-2025 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
[C++20] [Modules] Support module level lookup (#122887)
Close https://github.com/llvm/llvm-project/issues/90154
This patch is also an optimization to the lookup process to utilize the
informatio
[C++20] [Modules] Support module level lookup (#122887)
Close https://github.com/llvm/llvm-project/issues/90154
This patch is also an optimization to the lookup process to utilize the
information provided by `export` keyword.
Previously, in the lookup process, the `export` keyword only takes part
in the check part, it doesn't get involved in the lookup process. That
said, previously, in a name lookup for 'name', we would load all of
declarations with the name 'name' and check if these declarations are
valid or not. It works well. But it is inefficient since it may load
declarations that may not be wanted.
Note that this patch actually did a trick in the lookup process instead
of bring module information to DeclarationName or considering module
information when deciding if two declarations are the same. So it may
not be a surprise to me if there are missing cases. But it is not a
regression. It should be already the case. Issue reports are welcomed.
In this patch, I tried to split the big lookup table into a lookup table
as before and a module local lookup table, which takes a combination of
the ID of the DeclContext and hash value of the primary module name as
the key. And refactored `DeclContext::lookup()` method to take the
module information. So that a lookup in a DeclContext won't load
declarations that are local to **other** modules.
And also I think it is already beneficial to split the big lookup table
since it may reduce the conflicts during lookups in the hash table.
BTW, this patch introduced a **regression** for a reachability rule in
C++20 but it was false-negative. See
'clang/test/CXX/module/module.interface/p7.cpp' for details.
This patch is not expected to introduce any other
regressions for non-c++20-modules users since the module local lookup
table should be empty for them.
---
On the API side, this patch unfortunately add a maybe-confusing argument
`Module *NamedModule` to
`ExternalASTSource::FindExternalVisibleDeclsByName()`. People may think
we can get the information from the first argument `const DeclContext
*DC`. But sadly there are declarations (e.g., namespace) can appear in
multiple different modules as a single declaration. So we have to add
additional information to indicate this.
show more ...
|
Revision tags: llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4 |
|
#
5845688e |
| 13-Nov-2024 |
Kadir Cetinkaya <kadircet@google.com> |
Reapply "[clang] Introduce diagnostics suppression mappings (#112517)"
This reverts commit 5f140ba54794fe6ca379362b133eb27780e363d7.
|
#
5f140ba5 |
| 12-Nov-2024 |
Kadir Cetinkaya <kadircet@google.com> |
Revert "[clang] Introduce diagnostics suppression mappings (#112517)"
This reverts commit 12e3ed8de8c6063b15916b3faf67c8c9cd17df1f. This reverts commit 41e3919ded78d8870f7c95e9181c7f7e29aa3cc4.
The
Revert "[clang] Introduce diagnostics suppression mappings (#112517)"
This reverts commit 12e3ed8de8c6063b15916b3faf67c8c9cd17df1f. This reverts commit 41e3919ded78d8870f7c95e9181c7f7e29aa3cc4.
There are some buildbot breakages in https://lab.llvm.org/buildbot/#/builders/18/builds/6832.
show more ...
|
#
41e3919d |
| 12-Nov-2024 |
kadir çetinkaya <kadircet@google.com> |
[clang] Introduce diagnostics suppression mappings (#112517)
This implements
https://discourse.llvm.org/t/rfc-add-support-for-controlling-diagnostics-severities-at-file-level-granularity-through-
[clang] Introduce diagnostics suppression mappings (#112517)
This implements
https://discourse.llvm.org/t/rfc-add-support-for-controlling-diagnostics-severities-at-file-level-granularity-through-command-line/81292.
Users now can suppress warnings for certain headers by providing a
mapping with globs, a sample file looks like:
```
[unused]
src:*
src:*clang/*=emit
```
This will suppress warnings from `-Wunused` group in all files that
aren't under `clang/` directory. This mapping file can be passed to
clang via `--warning-suppression-mappings=foo.txt`.
At a high level, mapping file is stored in DiagnosticOptions and then
processed with rest of the warning flags when creating a
DiagnosticsEngine. This is a functor that uses SpecialCaseLists
underneath to match against globs coming from the mappings file.
This implies processing warning options now performs IO, relevant
interfaces are updated to take in a VFS, falling back to RealFileSystem
when one is not available.
show more ...
|
Revision tags: 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 |
|
#
eb5dbaf8 |
| 29-Jun-2024 |
Kazu Hirata <kazu@google.com> |
[clang] Use std::make_unique (NFC) (#97176)
This patch is based on clang-tidy's modernize-make-unique but limited
to those cases where type names are mentioned twice like
`std::unique_ptr<Type>(ne
[clang] Use std::make_unique (NFC) (#97176)
This patch is based on clang-tidy's modernize-make-unique but limited
to those cases where type names are mentioned twice like
`std::unique_ptr<Type>(new Type())`, which is a bit mouthful.
show more ...
|
Revision tags: 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 |
|
#
8c296d58 |
| 19-Dec-2023 |
Kazu Hirata <kazu@google.com> |
[Interpreter] Fix warnings
This patch fixes:
clang/lib/Interpreter/CodeCompletion.cpp:126:35: error: 'startswith' is deprecated: Use starts_with instead [-Werror,-Wdeprecated-declarations]
[Interpreter] Fix warnings
This patch fixes:
clang/lib/Interpreter/CodeCompletion.cpp:126:35: error: 'startswith' is deprecated: Use starts_with instead [-Werror,-Wdeprecated-declarations]
clang/lib/Interpreter/CodeCompletion.cpp:189:42: error: 'startswith' is deprecated: Use starts_with instead [-Werror,-Wdeprecated-declarations]
show more ...
|
#
35b366ac |
| 19-Dec-2023 |
Fred Fu <moonsolo@gmail.com> |
[ClangRepl] Reland Semanic Code Completion (#75556)
This patch contains changes from
002d471a4a3cd8b429e4ca7c84fd54a642e50e4c, in
addition to a bug fix that added a virtual destructor to
`Complet
[ClangRepl] Reland Semanic Code Completion (#75556)
This patch contains changes from
002d471a4a3cd8b429e4ca7c84fd54a642e50e4c, in
addition to a bug fix that added a virtual destructor to
`CompletionContextHandler`
The original changes in the orginal commit piggybacks on clang's
semantic modules to enable semantic completion. In particular, we use
`CodeCompletionContext` to differentiate two types of code completion.
We also
extract the relevant type information from it.
show more ...
|
Revision tags: llvmorg-17.0.6 |
|
#
9ebe6e28 |
| 23-Nov-2023 |
Fred Fu <moonsolo@gmail.com> |
Revert "[ClangRepl] Type Directed Code Completion" (#73259)
Reverts llvm/llvm-project#67349
There are some issues with the sanitizers. We will reland once that's fixed.
|
#
002d471a |
| 23-Nov-2023 |
Fred Fu <moonsolo@gmail.com> |
[ClangRepl] Type Directed Code Completion (#67349)
Differential Revision: https://reviews.llvm.org/D159128
|
Revision tags: 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 |
|
#
79af92bb |
| 28-Aug-2023 |
Fred Fu <moonsolo@gmail.com> |
Reland "[clang-repl] support code completion at a REPL."
Original commit message: " This patch enabled code completion for ClangREPL. The feature was built upon three existing Clang components: a li
Reland "[clang-repl] support code completion at a REPL."
Original commit message: " This patch enabled code completion for ClangREPL. The feature was built upon three existing Clang components: a list completer for LineEditor, a CompletionConsumer from SemaCodeCompletion, and the ASTUnit::codeComplete method. The first component serves as the main entry point of handling interactive inputs.
Because a completion point for a compiler instance has to be unchanged once it is set, an incremental compiler instance is created for each code completion. Such a compiler instance carries over AST context source from the main interpreter compiler in order to obtain declarations or bindings from previous input in the same REPL session.
The most important API codeComplete in Interpreter/CodeCompletion is a thin wrapper that calls with ASTUnit::codeComplete with necessary arguments, such as a code completion point and a ReplCompletionConsumer, which communicates completion results from SemaCodeCompletion back to the list completer for the REPL.
In addition, PCC_TopLevelOrExpression and CCC_TopLevelOrExpression` top levels were added so that SemaCodeCompletion can treat top level statements like expression statements at the REPL. For example,
clang-repl> int foo = 42; clang-repl> f<tab>
From a parser's persective, the cursor is at a top level. If we used code completion without any changes, PCC_Namespace would be supplied to Sema::CodeCompleteOrdinaryName, and thus the completion results would not include foo.
Currently, the way we use PCC_TopLevelOrExpression and CCC_TopLevelOrExpression is no different from the way we use PCC_Statement and CCC_Statement respectively.
Differential revision: https://reviews.llvm.org/D154382 "
The new patch also fixes clangd and several memory issues that the bots reported and upload the missing files.
show more ...
|
#
eb0e6c31 |
| 22-Aug-2023 |
Fred Fu <moonsolo@gmail.com> |
[clang-repl] support code completion at a REPL.
This patch enabled code completion for ClangREPL. The feature was built upon three existing Clang components: a list completer for LineEditor, a Compl
[clang-repl] support code completion at a REPL.
This patch enabled code completion for ClangREPL. The feature was built upon three existing Clang components: a list completer for LineEditor, a CompletionConsumer from SemaCodeCompletion, and the ASTUnit::codeComplete method. The first component serves as the main entry point of handling interactive inputs.
Because a completion point for a compiler instance has to be unchanged once it is set, an incremental compiler instance is created for each code completion. Such a compiler instance carries over AST context source from the main interpreter compiler in order to obtain declarations or bindings from previous input in the same REPL session.
The most important API codeComplete in Interpreter/CodeCompletion is a thin wrapper that calls with ASTUnit::codeComplete with necessary arguments, such as a code completion point and a ReplCompletionConsumer, which communicates completion results from SemaCodeCompletion back to the list completer for the REPL.
In addition, PCC_TopLevelOrExpression and CCC_TopLevelOrExpression` top levels were added so that SemaCodeCompletion can treat top level statements like expression statements at the REPL. For example,
clang-repl> int foo = 42; clang-repl> f<tab>
From a parser's persective, the cursor is at a top level. If we used code completion without any changes, PCC_Namespace would be supplied to Sema::CodeCompleteOrdinaryName, and thus the completion results would not include foo.
Currently, the way we use PCC_TopLevelOrExpression and CCC_TopLevelOrExpression is no different from the way we use PCC_Statement and CCC_Statement respectively.
Differential revision: https://reviews.llvm.org/D154382
show more ...
|