[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 ...

[clang] Rename StringRef _lower() method calls to _insensitive()

This is mostly a mechanical change, but a testcase that contains
parts of the StringRef class (clang/test/Analysis/llvm-conventions.c

[clang] Rename StringRef _lower() method calls to _insensitive()

This is mostly a mechanical change, but a testcase that contains
parts of the StringRef class (clang/test/Analysis/llvm-conventions.cpp)
isn't touched.

show more ...

[clang] p1099 using enum part 2

This implements the 'using enum maybe-qualified-enum-tag ;' part of
1099. It introduces a new 'UsingEnumDecl', subclassed from
'BaseUsingDecl'. Much of the diff is th

[clang] p1099 using enum part 2

This implements the 'using enum maybe-qualified-enum-tag ;' part of
1099. It introduces a new 'UsingEnumDecl', subclassed from
'BaseUsingDecl'. Much of the diff is the boilerplate needed to get the
new class set up.

There is one case where we accept ill-formed, but I believe this is
merely an extended case of an existing bug, so consider it
orthogonal. AFAICT in class-scope the c++20 rule is that no 2 using
decls can bring in the same target decl ([namespace.udecl]/8). But we
already accept:

struct A { enum { a }; };
struct B : A { using A::a; };
struct C : B { using A::a;
using B::a; }; // same enumerator

this patch permits mixtures of 'using enum Bob;' and 'using Bob::member;' in the same way.

Differential Revision: https://reviews.llvm.org/D102241

show more ...

Add support for #elifdef and #elifndef

WG14 adopted N2645 and WG21 EWG has accepted P2334 in principle (still
subject to full EWG vote + CWG review + plenary vote), which add
support for #elifdef as

Add support for #elifdef and #elifndef

WG14 adopted N2645 and WG21 EWG has accepted P2334 in principle (still
subject to full EWG vote + CWG review + plenary vote), which add
support for #elifdef as shorthand for #elif defined and #elifndef as
shorthand for #elif !defined. This patch adds support for the new
preprocessor directives.

show more ...

Introduce -Wreserved-identifier

Warn when a declaration uses an identifier that doesn't obey the reserved
identifier rule from C and/or C++.

Differential Revision: https://reviews.llvm.org/D93095

[clang] NFC: Fix range-based for loop warnings related to decl lookup

[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

[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.
eb4ab3358cd4dc834a761191b5531b38114f7b13 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

show more ...

[CodeCompletion] Don't track preferred types if code completion is disabled.

Some of this work isn't quite trivial.

(As requested in D96058)

Differential Revision: https://reviews.llvm.org/D98459

[clang][CodeComplete] Ensure there are no crashes when completing with ParenListExprs as LHS

Differential Revision: https://reviews.llvm.org/D96950

[CodeComplete] Member completion: heuristically resolve some dependent base exprs

Today, inside a template, you can get completion for:

Foo<T> t;
t.^

t has dependent type Foo<T>, and we use the pr

[CodeComplete] Member completion: heuristically resolve some dependent base exprs

Today, inside a template, you can get completion for:

Foo<T> t;
t.^

t has dependent type Foo<T>, and we use the primary template to find its members.
However we also want this to work:

t.foo.bar().^

The type of t.foo.bar() is DependentTy, so we attempt to resolve using similar
heuristics (e.g. primary template).

Differential Revision: https://reviews.llvm.org/D96376

show more ...

[clang][CodeComplete] Fix crash on ParenListExprs

Fixes https://github.com/clangd/clangd/issues/676.

Differential Revision: https://reviews.llvm.org/D95935

[CodeComplete] Guess type for designated initializers

This enables:
- completion in { .x.^ }
- completion in { .x = { .^ } }
- type-based ranking of candidates for { .x = ^ }

Differential Revisi

[CodeComplete] Guess type for designated initializers

This enables:
- completion in { .x.^ }
- completion in { .x = { .^ } }
- type-based ranking of candidates for { .x = ^ }

Differential Revision: https://reviews.llvm.org/D96058

show more ...

[clangd] Fix a crash when indexing invalid ObjC method declaration

This fix will make us not crash, but ideally we would handle this case
better.

Differential Revision: https://reviews.llvm.org/D94

[clangd] Fix a crash when indexing invalid ObjC method declaration

This fix will make us not crash, but ideally we would handle this case
better.

Differential Revision: https://reviews.llvm.org/D94919

show more ...

[CodeComplete] Add ranged for loops code pattern.

Add code pattersn for c++ `range for` loops and objective c `for...in` loops.

Reviewed By: kadircet

Differential Revision: https://reviews.llvm.or

[CodeComplete] Add ranged for loops code pattern.

Add code pattersn for c++ `range for` loops and objective c `for...in` loops.

Reviewed By: kadircet

Differential Revision: https://reviews.llvm.org/D95131

show more ...

[clang] Add a new nullability annotation for swift async: _Nullable_result

_Nullable_result generally like _Nullable, except when being imported into a
swift async method. rdar://70106409

Different

[clang] Add a new nullability annotation for swift async: _Nullable_result

_Nullable_result generally like _Nullable, except when being imported into a
swift async method. rdar://70106409

Differential revision: https://reviews.llvm.org/D92495

show more ...

Convert TypeSpecifierSign from Specifiers.h to a scoped enum; NFC

[NFC, Refactor] Rename the (scoped) enum DeclaratorContext's enumerators to remove duplication

Since these are scoped enumerators, they have to be prefixed by DeclaratorContext, so lets remove Conte

[NFC, Refactor] Rename the (scoped) enum DeclaratorContext's enumerators to remove duplication

Since these are scoped enumerators, they have to be prefixed by DeclaratorContext, so lets remove Context from the name, and return some characters to the multiverse.

Patch was reviewed here: https://reviews.llvm.org/D91011

Thank you to aaron, bruno, wyatt and barry for indulging me.

show more ...

[clang] Make signature help work with dependent args

Fixes https://github.com/clangd/clangd/issues/490

Differential Revision: https://reviews.llvm.org/D85826

[CodeComplete] Add code completion after function equals

Summary:
Provide `default` and `delete` completion after the function equals.

Reviewers: kadircet, sammccall

Tags: #clang

Differential Rev

[CodeComplete] Add code completion after function equals

Summary:
Provide `default` and `delete` completion after the function equals.

Reviewers: kadircet, sammccall

Tags: #clang

Differential Revision: https://reviews.llvm.org/D82548

show more ...

[CodeComplete] Tweak completion for else.

If an `if` statement uses braces for its `then` block, suggest braces for the `else` and `else if` completion blocks, Otherwise don't suggest them.

Reviewe

[CodeComplete] Tweak completion for else.

If an `if` statement uses braces for its `then` block, suggest braces for the `else` and `else if` completion blocks, Otherwise don't suggest them.

Reviewed By: sammccall

Differential Revision: https://reviews.llvm.org/D82626

show more ...

[CodeComplete] Add code completion for using alias.

Add code completion for using alias.

Patch By @lh123 !

Reviewers: kadircet

Differential Revision: https://reviews.llvm.org/D82535

[CodeComplete] Tweak code completion for `typename`.

Summary:
Currently, clangd always completes `typename` as `typename qualifier::name`, I think the current behavior is not useful when the code co

[CodeComplete] Tweak code completion for `typename`.

Summary:
Currently, clangd always completes `typename` as `typename qualifier::name`, I think the current behavior is not useful when the code completion is triggered in `template <>`. So I tweak it to `typename identifier`.

Patch by @lh123 !

Reviewers: sammccall, kadircet

Reviewed By: kadircet

Subscribers: ilya-biryukov, usaxena95, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D82373

show more ...

[Sema][CodeComplete][ObjC] Don't split the first selector fragment

Summary:
Standardize the formatting of selector fragments to include the ':',
e.g. for `- (void)foobar:(int)foobar;`, report `{foob

[Sema][CodeComplete][ObjC] Don't split the first selector fragment

Summary:
Standardize the formatting of selector fragments to include the ':',
e.g. for `- (void)foobar:(int)foobar;`, report `{foobar:}` instead of
`{foobar}{:}`. This was normally the case except for a couple of places
where it was split.

This also improves integration with clangd since it relies upon the `:`
to identify ObjC selectors.

NOTE: It is possible to have selector fragments that are just `:` with
no text, we now handle this properly for the first fragment.

Reviewers: sammccall, doug.gregor

Subscribers: ilya-biryukov, dexonsmith, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D82306

show more ...

[Sema][CodeComplete][ObjC] Don't include arrow/dot fixits

Summary:
Exempt ObjC from arrow/dot fixits since this has limited value for
Objective-C, where properties (referenced by dot syntax) are nor

[Sema][CodeComplete][ObjC] Don't include arrow/dot fixits

Summary:
Exempt ObjC from arrow/dot fixits since this has limited value for
Objective-C, where properties (referenced by dot syntax) are normally
backed by ivars (referenced by arrow syntax).

In addition, the current implementation doesn't properly mark
the fix it condition for Objective-C.

This was initially added in https://reviews.llvm.org/D41537
for C++ and then later C, don't believe the Objective-C changes
were intentional.

Reviewers: sammccall, yvvan

Subscribers: jfb, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D81263

show more ...

[NFC] Refactoring PropertyAttributeKind for ObjCPropertyDecl and ObjCDeclSpec.

This is a code clean up of the PropertyAttributeKind and
ObjCPropertyAttributeKind enums in ObjCPropertyDecl and ObjCDe

[NFC] Refactoring PropertyAttributeKind for ObjCPropertyDecl and ObjCDeclSpec.

This is a code clean up of the PropertyAttributeKind and
ObjCPropertyAttributeKind enums in ObjCPropertyDecl and ObjCDeclSpec that are
exactly identical. This non-functional change consolidates these enums
into one. The changes are to many files across clang (and comments in LLVM) so
that everything refers to the new consolidated enum in DeclObjCCommon.h.

2nd Landing Attempt...

Differential Revision: https://reviews.llvm.org/D77233

show more ...