llvm-project/clang
Sam McCall 128ce70eef [CodeCompletion] Avoid spurious signature help for init-list args
Somewhat surprisingly, signature help is emitted as a side-effect of
computing the expected type of a function argument.
The reason is that both actions require enumerating the possible
function signatures and running partial overload resolution, and doing
this twice would be wasteful and complicated.

Change #1: document this, it's subtle :-)

However, sometimes we need to compute the expected type without having
reached the code completion cursor yet - in particular to allow
completion of designators.
eb4ab3358c did this but introduced a
regression - it emits signature help in the wrong location as a side-effect.

Change #2: only emit signature help if the code completion cursor was reached.

Currently there is PP.isCodeCompletionReached(), but we can't use it
because it's set *after* running code completion.
It'd be nice to set this implicitly when the completion token is lexed,
but ConsumeCodeCompletionToken() makes this complicated.

Change #3: call cutOffParsing() *first* when seeing a completion token.

After this, the fact that the Sema::Produce*SignatureHelp() functions
are even more confusing, as they only sometimes do that.
I don't want to rename them in this patch as it's another large
mechanical change, but we should soon.

Change #4: prepare to rename ProduceSignatureHelp() to GuessArgumentType() etc.

Differential Revision: https://reviews.llvm.org/D98488
2021-03-16 12:46:40 +01:00
..
INPUTS
bindings
cmake [Fuchsia] Add check-polly to CLANG_BOOTSTRAP_TARGETS 2021-03-12 18:31:20 -08:00
docs [ASTMatchers] Fix documentation for hasAnyBody matcher 2021-03-15 13:06:49 +00:00
examples Refactoring the attribute plugin example to fit the new API 2020-12-21 08:24:09 -05:00
include [CodeCompletion] Avoid spurious signature help for init-list args 2021-03-16 12:46:40 +01:00
lib [CodeCompletion] Avoid spurious signature help for init-list args 2021-03-16 12:46:40 +01:00
runtime [compiler-rt] Fix stale incremental builds when using `LLVM_BUILD_EXTERNAL_COMPILER_RT=ON`. 2021-03-10 09:42:24 -08:00
test [CodeCompletion] Avoid spurious signature help for init-list args 2021-03-16 12:46:40 +01:00
tools [clang-format] Rename case sorting 2021-03-05 21:42:45 +01:00
unittests [AST] Add generator for source location introspection 2021-03-15 10:52:44 +00:00
utils [RISCV] Don't emit #undef BUILTIN from RISCVVEmitter.cpp 2021-03-16 14:57:45 +08:00
www [www] Add cxx_status tracking for C++23. 2021-02-25 14:47:43 -08:00
.clang-format
.clang-tidy
.gitignore
CMakeLists.txt [test] Add ability to get error messages from CMake for errc substitution 2021-03-15 20:56:08 +01:00
CODE_OWNERS.TXT
INSTALL.txt
LICENSE.TXT
ModuleInfo.txt
NOTES.txt
README.txt

README.txt

//===----------------------------------------------------------------------===//
// C Language Family Front-end
//===----------------------------------------------------------------------===//

Welcome to Clang.  This is a compiler front-end for the C family of languages
(C, C++, Objective-C, and Objective-C++) which is built as part of the LLVM
compiler infrastructure project.

Unlike many other compiler frontends, Clang is useful for a number of things
beyond just compiling code: we intend for Clang to be host to a number of
different source-level tools.  One example of this is the Clang Static Analyzer.

If you're interested in more (including how to build Clang) it is best to read
the relevant web sites.  Here are some pointers:

Information on Clang:             http://clang.llvm.org/
Building and using Clang:         http://clang.llvm.org/get_started.html
Clang Static Analyzer:            http://clang-analyzer.llvm.org/
Information on the LLVM project:  http://llvm.org/

If you have questions or comments about Clang, a great place to discuss them is
on the Clang development mailing list:
  http://lists.llvm.org/mailman/listinfo/cfe-dev

If you find a bug in Clang, please file it in the LLVM bug tracker:
  http://llvm.org/bugs/