Dummy is a word with inappropriate associations. This patch updates the
references to it in clangd code base with more precise ones.
The only user-visible change is the default variable name used when extracting a
variable. It will be named as `placeholder` from now on.
Differential Revision: https://reviews.llvm.org/D99065
Explicit specifier can only be mentioned on the in-line declaration of a
constructor, so don't carry it over to the definition.
Differential Revision: https://reviews.llvm.org/D98164
Refactor cross file rename to use a Filesystem instead of a function for getting buffer contents of open files.
Depends on D94554
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D95043
The patch also does some cleanup on the interface of the entry
points from TargetFinder into the heuristic resolution code.
Since the heuristic resolver is created in a place where the
ASTContext is available, it can store the ASTContext and the
NameFactory hack can be removed.
Differential revision: https://reviews.llvm.org/D92290
This patch only focuses on the flag. Removing actual single-file mode
(and the flag in RenameOption) will come in a follow-up.
Differential Revision: https://reviews.llvm.org/D96495
- Infrastructure to support modifiers (protocol etc)
- standard modifiers:
- declaration (but no definition, yet)
- deprecated
- readonly (based on a fairly fuzzy const checking)
- static (for class members and locals, but *not* file-scope things!)
- abstract (for C++ classes, and pure-virtual methods)
- nonstandard modifier:
- deduced (on "auto" whose Kind is Class etc)
Happy to drop this if it's controversial at all.
- While here, update sample tweak to use our internal names, in
anticipation of theia TM scopes going away.
This addresses some of the goals of D77702, but leaves some things undone.
Mostly because I think these will want some discussion.
- no split between dependent type/name.
(We may want to model this as a modifier, type+dependent vs ???+dependent)
- no split between primitive/typedef.
(Is introducing a nonstandard kind is worth this distinction?)
- no nonstandard local attribute
This probably makes sense, I'm wondering if we want others and how
they fit together.
There's one minor regression in explicit template specialization declarations
due to a latent bug in findExplicitReferences, but fixing it after seems OK.
Differential Revision: https://reviews.llvm.org/D77811
Follow-up on D95925: adds better detection for function arguments and also
checks for conflicts in muli-variable init statements in ForStmt.
Reviewed By: hokein
Differential Revision: https://reviews.llvm.org/D96009
This patch allows detecting conflicts with variables defined in the current
CompoundStmt or If/While/For variable init statements.
Reviewed By: hokein
Differential Revision: https://reviews.llvm.org/D95925
We cannot expand auto when used inside a template param (C++17 feature),
so do not offer it there.
Differential Revision: https://reviews.llvm.org/D94719
Only show the keyword as the hover "Name".
Show whether the type is deduced or undeduced as
the hover "Documentation".
Show the deduced type (if any) as the "Definition".
Don't show any hover information for:
- the "auto" word of "decltype(auto)"
- "auto" in lambda parameters
- "auto" in template arguments
---------------
This diff is a suggestion based on what @sammccall suggested in https://reviews.llvm.org/D92977 about hover on "auto". It somehow "hacks" onto the "Documentation" and "Definition" fields of `HoverInfo`. It sure looks good on VSCode, let me know if this seem acceptable to you.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D93227
SmallVector<T> with default size is now the recommended version (D92522).
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D92788
We can't expand lambda types anyway. Now we simply not offer the code
action instead of showing it and then returning an error in apply().
Differential Revision: https://reviews.llvm.org/D92847
apply() will fail in those cases, so it's better to detect it in
prepare() already and hide code action from the user.
This was especially annoying on code bases that use a lot of
RETURN_IF_ERROR-like macros.
Differential Revision: https://reviews.llvm.org/D92408
If the enum is a dependent type, we would crash somewhere in
getIntWidth(). -Wswitch diagnostic doesn't work on dependent enums
either.
Differential Revision: https://reviews.llvm.org/D92051
When type/function is defined in the middle of the file, previuosly we
would sometimes insert a "using" line before that definition, leading to
a compilation error. With this fix, we pick a point after such
definition in translation unit.
This is not a perfect solution. For example, it still doesn't handle
"using namespace" directives. It is, however, a significant improvement.
Differential Revision: https://reviews.llvm.org/D92053
This patch introduces new canonicalization rules which are used for AST-based
rename in Clangd. By comparing two canonical declarations of inspected nodes,
Clangd determines whether both of them belong to the same entity user would
like to rename. Such functionality is relatively concise compared to the
Clang-Rename API that is used right now. It also helps to overcome the
limitations that Clang-Rename originally had and helps to eliminate several
classes of bugs.
Clangd AST-based rename currently relies on Clang-Rename which has design
limitations and also lacks some features. This patch breaks this dependency and
significantly reduces the amount of code to maintain (Clang-Rename is ~2000 LOC,
this patch is just <30 LOC of replacement code).
We eliminate technical debt by simultaneously
* Maintaining feature parity and ensuring no regressions
* Opening a straightforward path to improving existing rename bugs
* Making it possible to add more capabilities to rename feature which would not
be possible with Clang-Rename
Reviewed By: hokein
Differential Revision: https://reviews.llvm.org/D71880
With this patch, we reject the rename if the new name would conflict with
any other decls in the decl context of the renamed decl.
Differential Revision: https://reviews.llvm.org/D89790
If an enum has different names for the same constant, make sure only the first one declared gets added into the switch. Failing to do so results in a compiler error as 2 case labels can't represent the same value.
```
lang=c
enum Numbers{
One,
Un = One,
Two,
Deux = Two,
Three,
Trois = Three
};
// Old behaviour
switch (<Number>) {
case One:
case Un:
case Two:
case Duex:
case Three:
case Trois: break;
}
// New behaviour
switch (<Number>) {
case One:
case Two:
case Three: break;
}
```
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D90555
We were default initializing SymbolIDs before, which would leave
indeterminate values in underlying std::array.
This patch updates the underlying data initalization to be value-init and adds a
way to check for validness of a SymbolID.
Differential Revision: https://reviews.llvm.org/D90397
This patch introduces hoisting detection logic into prepare state with
a partial AST traversal of the enclosing function.
We had some complaints from the users about this code action being almost always
available but failing most of the time. Hopefully this should reduce that noise.
The latency/correctness tradeoff is a bunch of hand-waving, but at least today
we don't have any other actions that are available on selection of statements,
so when we get to do the traversal it is quite likely that all the other checks
will bail out early. But this is still up for discussion, I am happy to abandon
the patch if you believe this is not practical.
Differential Revision: https://reviews.llvm.org/D85354
several changes:
- return a structure result in rename API;
- prepareRename now returns more information (main-file occurrences);
- remove the duplicated detecting-touch-identifier code in prepareRename (which is implemented in rename API);
Differential Revision: https://reviews.llvm.org/D88634
It fixes the -Wswitch warning, though we mark it as a fix even if that is off.
This makes it the "recommended" action on an incomplete switch, which seems OK.
Differential Revision: https://reviews.llvm.org/D88726
Intent was a nice idea but it ends up being a bit awkward/heavyweight
without adding much.
In particular, it makes it hard to implement `CodeActionParams.only` properly
(there's an inheritance hierarchy for kinds).
Differential Revision: https://reviews.llvm.org/D88427
Improve the recently-added PopulateSwitch tweak to work on non-empty switches.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D88434
Add a tweak that populates an empty switch statement of an enumeration type with all of the enumerators of that type.
Before:
```
enum Color { RED, GREEN, BLUE };
void f(Color color) {
switch (color) {}
}
```
After:
```
enum Color { RED, GREEN, BLUE };
void f(Color color) {
switch (color) {
case RED:
case GREEN:
case BLUE:
break;
}
}
```
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D88383
For style guides forbid "using" declarations for namespaces like "std".
With this new config option, AddUsing can be selectively disabled on
those.
Differential Revision: https://reviews.llvm.org/D87775
Kadir Cetinkaya