zyn0217 wrote:
Another issue I've encountered while at it is that, given the following code,
```cpp
void foo();
auto lambda = [] {
return ^foo();
};
```
let `N` represent the selection node for the expression `foo()`,
`N.getDeclContext()` then yields `TranslationUnitDecl` rather than the
HighCommander4 wrote:
> @HighCommander4 While at the `HeuristicResolver`, I think we may have a bug
> inside `HighlightingsBuilder` defined in `SemanticHighlighting.cpp`.
>
>
zyn0217 wrote:
@HighCommander4 While at the `HeuristicResolver`, I think we may have a bug
inside `HighlightingsBuilder` defined in `SemanticHighlighting.cpp`.
HighCommander4 wrote:
> > I also discovered some complications related to nested templates [...]
>
> Does my previous comment elaborate on the same issue you've encountered?
I believe so, yes.
> Could you kindly share your thoughts more?
Let's consider a nested template like this:
```c++
HighCommander4 wrote:
Thinking some more about "Approach 2", I realized there is a challenge with it:
given the node we are trying to resolve (for example, a dependent member expr)
as a starting point, we need to find the enclosing template decl, so that we
can query it for its "only
zyn0217 wrote:
> I also discovered some complications related to nested templates, and I have
> some thoughts on how to resolve them, but I'm going to suggest that we start
> with getting a simple case (e.g. just one level of templates, no nested
> templates) to work, and then tackle nested
zyn0217 wrote:
Thank you again for bothering with this, and sorry for not responding for over
a week.
Just now, I replicated the experimentation
> I've done some local experimentation, and what I'm seeing is that
> `TemplateTypeParmDecl::getDeclContext()` does return the FunctionDecl or
>
HighCommander4 wrote:
I thought some more about this.
I appreciate better now the question you asked here:
> I realized that we had to tackle synthesized types e.g.
> > ```c++
> > template typename C, typename D, int E>
> > void work() {
> > C complicated_type;
> > // ^ Shall we perform
HighCommander4 wrote:
> I suspect it won't work with the present `TemplateTypeParm{Type,Decl}`
> models. `TemplateTypeParmDecl` per se is not tied to any `CXXRecordDecl` nor
> `FunctionDecl` that the template parameter is declaring with. (For the most
> seemingly-relevant part, i.e. the
zyn0217 wrote:
> If so, get its TemplateTypeParmDecl, find the template whose parameter it is,
> and see if the template has a getOnlyInstantiation.
Thanks for the suggestion! Admittedly, it looks neat and terse. However, I
suspect it won't work with the present `TemplateTypeParm{Type,Decl}`
https://github.com/HighCommander4 commented:
Thanks very much for looking at this!
I'm wondering if it's possible to achieve the same results (and also solve your
`CXXUnresolvedConstructExpr` issue) with a more targeted change that may also
be simpler.
While I haven't experimented with this
https://github.com/zyn0217 updated
https://github.com/llvm/llvm-project/pull/71279
>From d73a8e2ee683e6812c21cb1de7363b14565a96d1 Mon Sep 17 00:00:00 2001
From: Younan Zhang
Date: Sat, 4 Nov 2023 18:43:58 +0800
Subject: [PATCH 1/3] [clangd] Resolve the dependent type from its single
@@ -150,6 +246,11 @@ std::vector
HeuristicResolver::resolveMemberExpr(
if (ME->isArrow()) {
BaseType = getPointeeType(BaseType);
}
+
+ if (BaseType->isDependentType())
zyn0217 wrote:
I don't know if I should assume the non-nullity for `BaseType`:
https://github.com/zyn0217 updated
https://github.com/llvm/llvm-project/pull/71279
>From d73a8e2ee683e6812c21cb1de7363b14565a96d1 Mon Sep 17 00:00:00 2001
From: Younan Zhang
Date: Sat, 4 Nov 2023 18:43:58 +0800
Subject: [PATCH 1/2] [clangd] Resolve the dependent type from its single
@@ -150,6 +246,11 @@ std::vector
HeuristicResolver::resolveMemberExpr(
if (ME->isArrow()) {
BaseType = getPointeeType(BaseType);
}
+
+ if (BaseType->isDependentType())
sr-tream wrote:
Check BaseType before access (line 254)
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff cd6022916bff1d6fab007b554810b631549ba43c
d73a8e2ee683e6812c21cb1de7363b14565a96d1 --
https://github.com/zyn0217 edited
https://github.com/llvm/llvm-project/pull/71279
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvmbot wrote:
@llvm/pr-subscribers-clangd
Author: Younan Zhang (zyn0217)
Changes
This is an enhancement to the HeuristicResolver, trying to extract the deduced
type from the single instantiation for a template. This partially addresses the
point #1 from
@@ -46,6 +50,98 @@ const Type *resolveDeclsToType(const std::vector ,
return nullptr;
}
+// Visitor that helps to extract deduced type from instantiated entities.
+// This merely performs the source location comparison against each Decl
+// until it finds a Decl with the
https://github.com/zyn0217 created
https://github.com/llvm/llvm-project/pull/71279
This is an enhancement to the HeuristicResolver, trying to extract the deduced
type from the single instantiation for a template. This partially addresses the
point #1 from
20 matches
Mail list logo
