Author: nridge
Date: Thu May 30 16:54:43 2019
New Revision: 362176
URL: http://llvm.org/viewvc/llvm-project?rev=362176&view=rev
Log:
[clangd] clang-format SymbolCollector.cpp
Modified:
clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp
Modified: clang-tools-extra/trunk/clangd/index/Sym
Author: nridge
Date: Sun Jun 2 21:55:46 2019
New Revision: 362352
URL: http://llvm.org/viewvc/llvm-project?rev=362352&view=rev
Log:
[clangd] Add RelationSlab
Summary:
RelationSlab is a new index data structure that stores relations between
symbols.
Reviewers: kadircet
Subscribers: ilya-biryuko
Author: nridge
Date: Sun Jun 2 22:07:52 2019
New Revision: 362353
URL: http://llvm.org/viewvc/llvm-project?rev=362353&view=rev
Log:
[clangd] Serialization support for RelationSlab
Summary: This builds on D59407 to provide YAML and RIFF serialization support.
Reviewers: kadircet
Subscribers: il
Author: nridge
Date: Mon Jun 3 21:25:44 2019
New Revision: 362467
URL: http://llvm.org/viewvc/llvm-project?rev=362467&view=rev
Log:
[clangd] SymbolCollector support for relations
Summary:
The only relation currently collected is RelationBaseOf, because this is
all we need for type hierarchy subt
Author: nridge
Date: Fri Jun 14 19:26:47 2019
New Revision: 363481
URL: http://llvm.org/viewvc/llvm-project?rev=363481&view=rev
Log:
[clangd] Index API and implementations for relations
Summary:
This builds on the relations support added in D59407, D62459,
and D62471 to expose relations in Symbol
Author: nridge
Date: Sat Jun 15 19:31:37 2019
New Revision: 363506
URL: http://llvm.org/viewvc/llvm-project?rev=363506&view=rev
Log:
[clangd] Type hierarchy subtypes
Summary:
This builds on the relations support added in D59407, D62459, D62471,
and D62839 to implement type hierarchy subtypes.
Re
Author: nridge
Date: Wed Jun 19 16:11:02 2019
New Revision: 363889
URL: http://llvm.org/viewvc/llvm-project?rev=363889&view=rev
Log:
[clangd] Include the diagnostics's code when comparing diagnostics
Summary: This fixes https://github.com/clangd/clangd/issues/60
Reviewers: kadircet
Reviewed By:
Author: nridge
Date: Thu Jul 11 17:24:45 2019
New Revision: 365849
URL: http://llvm.org/viewvc/llvm-project?rev=365849&view=rev
Log:
[clangd] Add a missing early return in getTypeHierarchy()
Reviewers: sammccall
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags:
Author: nridge
Date: Thu Jul 11 20:26:32 2019
New Revision: 365867
URL: http://llvm.org/viewvc/llvm-project?rev=365867&view=rev
Log:
[clangd] Implement typeHierarchy/resolve for subtypes
Summary:
This allows the client to resolve subtypes one level at a time.
For supertypes, this is not necessar
00290003 0x01CDE35AB111
0x00294FD8E330), abort() + 0x31 bytes(s)
...
On Fri, 12 Jul 2019 at 04:26, Nathan Ridge via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: nridge
Date: Thu Jul 11 20:26:32 2019
New Revision: 365867
URL: http://llvm.org/viewvc/llvm-project?r
Author: nridge
Date: Fri Jul 12 20:24:54 2019
New Revision: 365987
URL: http://llvm.org/viewvc/llvm-project?rev=365987&view=rev
Log:
[clangd] Mark type hierarchy as a supported feature in the docs
Reviewers: sammccall
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Author: nridge
Date: Fri Jul 12 20:24:48 2019
New Revision: 365986
URL: http://llvm.org/viewvc/llvm-project?rev=365986&view=rev
Log:
[clangd] Implement typeHierarchy/resolve for subtypes
Summary:
This allows the client to resolve subtypes one level at a time.
For supertypes, this is not necessar
Author: nridge
Date: Wed Jul 17 08:26:49 2019
New Revision: 366338
URL: http://llvm.org/viewvc/llvm-project?rev=366338&view=rev
Log:
[clangd] Type hierarchy: don't resolve parents if the client only asked for
children
Summary: Also reorganize the code for computing supertypes to make it more
sy
Author: nridge
Date: Sun Aug 18 22:11:15 2019
New Revision: 369229
URL: http://llvm.org/viewvc/llvm-project?rev=369229&view=rev
Log:
[clangd] Update features table in the docs with links to LSP extension proposals
Also update the semantic coloring entry to reflect it being supported in
clangd now
Author: nridge
Date: Mon Oct 14 11:26:13 2019
New Revision: 374799
URL: http://llvm.org/viewvc/llvm-project?rev=374799&view=rev
Log:
[clangd] Improve semantic highlighting in dependent contexts (fixes #154)
Reviewers: hokein
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxe
Author: Nathan Ridge
Date: 2020-07-21T01:44:48-04:00
New Revision: 100dbd15624c1ac8d1210e7748462e20fed9a9d9
URL:
https://github.com/llvm/llvm-project/commit/100dbd15624c1ac8d1210e7748462e20fed9a9d9
DIFF:
https://github.com/llvm/llvm-project/commit/100dbd15624c1ac8d1210e7748462e20fed9a9d9.diff
Author: Nathan Ridge
Date: 2020-07-21T02:03:06-04:00
New Revision: 9946dcd3e9c7e8c7383265b82cc250c72a444f24
URL:
https://github.com/llvm/llvm-project/commit/9946dcd3e9c7e8c7383265b82cc250c72a444f24
DIFF:
https://github.com/llvm/llvm-project/commit/9946dcd3e9c7e8c7383265b82cc250c72a444f24.diff
This revision was not accepted when it landed; it landed in state "Needs
Review".
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG9946dcd3e9c7: [clangd] Improve heuristic resolution of
dependent t
Author: Nathan Ridge
Date: 2020-07-29T02:44:26-04:00
New Revision: 89247792c5bdd58500b0e6c5e56532424c2e2ca1
URL:
https://github.com/llvm/llvm-project/commit/89247792c5bdd58500b0e6c5e56532424c2e2ca1
DIFF:
https://github.com/llvm/llvm-project/commit/89247792c5bdd58500b0e6c5e56532424c2e2ca1.diff
Author: Nathan Ridge
Date: 2020-04-05T23:32:03-04:00
New Revision: 8b3b7556e9ab6084e9fd337d64dac1c165867d32
URL:
https://github.com/llvm/llvm-project/commit/8b3b7556e9ab6084e9fd337d64dac1c165867d32
DIFF:
https://github.com/llvm/llvm-project/commit/8b3b7556e9ab6084e9fd337d64dac1c165867d32.diff
Author: Nathan Ridge
Date: 2020-04-15T00:57:08-04:00
New Revision: d83541d1b8f75ff44083c8ba1dba1ca7bac330cf
URL:
https://github.com/llvm/llvm-project/commit/d83541d1b8f75ff44083c8ba1dba1ca7bac330cf
DIFF:
https://github.com/llvm/llvm-project/commit/d83541d1b8f75ff44083c8ba1dba1ca7bac330cf.diff
Author: Nathan Ridge
Date: 2020-06-15T11:59:23-04:00
New Revision: 7759f70fb0ee2cd6752d9188bd2578cc3d9a7a2e
URL:
https://github.com/llvm/llvm-project/commit/7759f70fb0ee2cd6752d9188bd2578cc3d9a7a2e
DIFF:
https://github.com/llvm/llvm-project/commit/7759f70fb0ee2cd6752d9188bd2578cc3d9a7a2e.diff
Author: Nathan Ridge
Date: 2020-06-15T12:18:21-04:00
New Revision: d1505233c85360bf3d9ab07af803b2bb478547a6
URL:
https://github.com/llvm/llvm-project/commit/d1505233c85360bf3d9ab07af803b2bb478547a6
DIFF:
https://github.com/llvm/llvm-project/commit/d1505233c85360bf3d9ab07af803b2bb478547a6.diff
Author: Nathan Ridge
Date: 2020-07-10T01:58:34-04:00
New Revision: 98d763ad051f5eab89fa46167516fc8a84f471d0
URL:
https://github.com/llvm/llvm-project/commit/98d763ad051f5eab89fa46167516fc8a84f471d0
DIFF:
https://github.com/llvm/llvm-project/commit/98d763ad051f5eab89fa46167516fc8a84f471d0.diff
Author: Nathan Ridge
Date: 2020-04-26T00:38:38-04:00
New Revision: 230cae89db3f8619e2b5383ae797462434f69d50
URL:
https://github.com/llvm/llvm-project/commit/230cae89db3f8619e2b5383ae797462434f69d50
DIFF:
https://github.com/llvm/llvm-project/commit/230cae89db3f8619e2b5383ae797462434f69d50.diff
Author: Nathan Ridge
Date: 2020-08-04T02:52:01-04:00
New Revision: 4ede3968498174f35f8456cd4bf95d14811d40d1
URL:
https://github.com/llvm/llvm-project/commit/4ede3968498174f35f8456cd4bf95d14811d40d1
DIFF:
https://github.com/llvm/llvm-project/commit/4ede3968498174f35f8456cd4bf95d14811d40d1.diff
Author: Nathan Ridge
Date: 2020-08-06T21:23:49-04:00
New Revision: f4ba7a100a56b63f9b3eac709ecea9f514d90c00
URL:
https://github.com/llvm/llvm-project/commit/f4ba7a100a56b63f9b3eac709ecea9f514d90c00
DIFF:
https://github.com/llvm/llvm-project/commit/f4ba7a100a56b63f9b3eac709ecea9f514d90c00.diff
Author: Nathan Ridge
Date: 2020-08-07T03:23:10-04:00
New Revision: 57f9518bf032d773c35c86ec99983a47849fd322
URL:
https://github.com/llvm/llvm-project/commit/57f9518bf032d773c35c86ec99983a47849fd322
DIFF:
https://github.com/llvm/llvm-project/commit/57f9518bf032d773c35c86ec99983a47849fd322.diff
Author: Nathan Ridge
Date: 2020-08-10T03:09:18-04:00
New Revision: b1c7f84643ffa63e72733b7089cea89723b82afc
URL:
https://github.com/llvm/llvm-project/commit/b1c7f84643ffa63e72733b7089cea89723b82afc
DIFF:
https://github.com/llvm/llvm-project/commit/b1c7f84643ffa63e72733b7089cea89723b82afc.diff
Author: Nathan Ridge
Date: 2020-08-10T13:27:23-04:00
New Revision: 70d583ad12872ef8714b15f1d1e982f1db6d9a15
URL:
https://github.com/llvm/llvm-project/commit/70d583ad12872ef8714b15f1d1e982f1db6d9a15
DIFF:
https://github.com/llvm/llvm-project/commit/70d583ad12872ef8714b15f1d1e982f1db6d9a15.diff
Author: Nathan Ridge
Date: 2020-08-18T00:30:07-04:00
New Revision: 15673d748acd8f26bdeee18c0aa18f44c775d738
URL:
https://github.com/llvm/llvm-project/commit/15673d748acd8f26bdeee18c0aa18f44c775d738
DIFF:
https://github.com/llvm/llvm-project/commit/15673d748acd8f26bdeee18c0aa18f44c775d738.diff
Author: Nathan Ridge
Date: 2020-08-18T00:32:34-04:00
New Revision: 00d7b7d014f90caef6f9c778614b09356bf0
URL:
https://github.com/llvm/llvm-project/commit/00d7b7d014f90caef6f9c778614b09356bf0
DIFF:
https://github.com/llvm/llvm-project/commit/00d7b7d014f90caef6f9c778614b09356bf0.diff
Author: Nathan Ridge
Date: 2020-08-18T03:03:49-04:00
New Revision: e33ec9d90400a906314ccbd5821dbe05d070108a
URL:
https://github.com/llvm/llvm-project/commit/e33ec9d90400a906314ccbd5821dbe05d070108a
DIFF:
https://github.com/llvm/llvm-project/commit/e33ec9d90400a906314ccbd5821dbe05d070108a.diff
Author: Nathan Ridge
Date: 2020-05-12T02:29:03-04:00
New Revision: 5a7276b3548589590b81975d5c3e487dd91ac097
URL:
https://github.com/llvm/llvm-project/commit/5a7276b3548589590b81975d5c3e487dd91ac097
DIFF:
https://github.com/llvm/llvm-project/commit/5a7276b3548589590b81975d5c3e487dd91ac097.diff
Author: Nathan Ridge
Date: 2022-08-29T12:59:05-04:00
New Revision: 9af0a142e43625cb8478b83692510a5abd39f808
URL:
https://github.com/llvm/llvm-project/commit/9af0a142e43625cb8478b83692510a5abd39f808
DIFF:
https://github.com/llvm/llvm-project/commit/9af0a142e43625cb8478b83692510a5abd39f808.diff
Author: Nathan Ridge
Date: 2022-09-05T03:42:08-04:00
New Revision: 898c421975ed36b99ec2047589384539bd29a40b
URL:
https://github.com/llvm/llvm-project/commit/898c421975ed36b99ec2047589384539bd29a40b
DIFF:
https://github.com/llvm/llvm-project/commit/898c421975ed36b99ec2047589384539bd29a40b.diff
Author: Nathan Ridge
Date: 2022-09-05T03:48:46-04:00
New Revision: c933453858307d060a1b79e257feb99c9ac828d7
URL:
https://github.com/llvm/llvm-project/commit/c933453858307d060a1b79e257feb99c9ac828d7
DIFF:
https://github.com/llvm/llvm-project/commit/c933453858307d060a1b79e257feb99c9ac828d7.diff
HighCommander4 wrote:
This sounds like it might be the culprit behind
https://github.com/clangd/clangd/issues/1358
https://github.com/llvm/llvm-project/pull/71605
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/m
https://github.com/HighCommander4 edited
https://github.com/llvm/llvm-project/pull/71162
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/HighCommander4 requested changes to this pull request.
Thank you for the patch!
https://github.com/llvm/llvm-project/pull/71162
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/c
@@ -0,0 +1,11 @@
+// RUN: cp %s %t.c
HighCommander4 wrote:
I think it would be more consistent with the rest of the clangd subproject if
this was expressed as a unit test.
It can take the form of a new section added to [this existing
test](https://searchfox.or
@@ -176,7 +176,8 @@ bool ExtractionContext::exprIsValidOutside(const
clang::Stmt *Scope) const {
SourceLocation ScopeBegin = Scope->getBeginLoc();
SourceLocation ScopeEnd = Scope->getEndLoc();
for (const Decl *ReferencedDecl : ReferencedDecls) {
-if (SM.isPointWithin
https://github.com/HighCommander4 approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/71162
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/HighCommander4 closed
https://github.com/llvm/llvm-project/pull/71162
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/HighCommander4 updated
https://github.com/llvm/llvm-project/pull/69153
>From 26861317e73e0e1a1d118688472ad0f0fc9af134 Mon Sep 17 00:00:00 2001
From: Nathan Ridge
Date: Mon, 16 Oct 2023 03:51:48 -0400
Subject: [PATCH] [clangd] Correctly identify the next token after the
compl
HighCommander4 wrote:
Rebased
https://github.com/llvm/llvm-project/pull/69153
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1491,6 +1491,46 @@ FuzzyFindRequest
speculativeFuzzyFindRequestForCompletion(
return CachedReq;
}
+// This function is similar to Lexer::findNextToken(), but assumes
+// that the input SourceLocation is the completion point (which is
+// a case findNextToken() does not
HighCommander4 wrote:
Thank you @zyn0217 for the review!
https://github.com/llvm/llvm-project/pull/69153
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/HighCommander4 closed
https://github.com/llvm/llvm-project/pull/69153
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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 a
https://github.com/HighCommander4 commented:
Is it not possible to tell based on the `CallExpr` only (rather than checking
an ancestor of it during traversal of the tree) that "this `CallExpr` is not
explicitly written in the source"?
https://github.com/llvm/llvm-project/pull/71366
___
HighCommander4 wrote:
I see; it's a bit unfortunate that such an "invented" call expression gets an
ordinary `SourceLocation`. I would have hoped it gets a source location in some
sort of virtual buffer like the [rewritten form of
`>>`](https://github.com/clangd/clangd/issues/871#issuecomment-
https://github.com/HighCommander4 created
https://github.com/llvm/llvm-project/pull/74971
None
>From ed2ccbab5bc9641cc857dd6e6d152449aab76431 Mon Sep 17 00:00:00 2001
From: Nathan Ridge
Date: Sun, 10 Dec 2023 00:50:54 -0500
Subject: [PATCH] [clangd] Initialize HighlightingsBuilder::Resolver
-
HighCommander4 wrote:
Fixing issue spotted in
https://github.com/llvm/llvm-project/pull/71279#issuecomment-1848347945.
I tried to construct a testcase that the previous code would fail but couldn't:
`kindForDecl` only does something interesting with the resolver for
`UnresolvedUsingValueDecl`
HighCommander4 wrote:
> @HighCommander4 While at the `HeuristicResolver`, I think we may have a bug
> inside `HighlightingsBuilder` defined in `SemanticHighlighting.cpp`.
>
> https://github.com/llvm/llvm-project/blob/6ed9a81f7ebd23f125867dd270785dd0e63043c6/clang-tools-extra/clangd/SemanticHigh
https://github.com/HighCommander4 updated
https://github.com/llvm/llvm-project/pull/74971
>From 86d99f7b29a131b949b32f18ff15eb1d1f5e4d3a Mon Sep 17 00:00:00 2001
From: Nathan Ridge
Date: Sun, 10 Dec 2023 00:50:54 -0500
Subject: [PATCH] [clangd] Initialize HighlightingsBuilder::Resolver
---
cl
https://github.com/HighCommander4 closed
https://github.com/llvm/llvm-project/pull/74971
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
HighCommander4 wrote:
> I see; it's a bit unfortunate that such an "invented" call expression gets an
> ordinary `SourceLocation`.
Out of curiosity, I dialled into today's LLVM [office
hours](https://llvm.org/docs/GettingInvolved.html#office-hours) and asked Aaron
Ballman about this. He also
HighCommander4 wrote:
@sr-tream just so you know, every time you force-push a PR, github sends every
subscriber an email notification
https://github.com/llvm/llvm-project/pull/72479
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists
HighCommander4 wrote:
The CI run shows the test
[Sema/builtin-dump-struct.c](https://searchfox.org/llvm/source/clang/test/Sema/builtin-dump-struct.c)
is failing.
https://github.com/llvm/llvm-project/pull/72750
___
cfe-commits mailing list
cfe-commits
HighCommander4 wrote:
It looks like the issue is, if the invented CallExpr is ill-formed and the
compiler needs to issue a diagnostic about it, with the invalid SourceLocation
it doesn't have a source location to attach to the diagnostic.
I guess this means the approach of using an invalid Sou
https://github.com/HighCommander4 edited
https://github.com/llvm/llvm-project/pull/71366
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/HighCommander4 requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/71366
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -589,6 +589,24 @@ class InlayHintVisitor : public
RecursiveASTVisitor {
return true;
}
+ bool TraversePseudoObjectExpr(PseudoObjectExpr *E) {
+// Do not show inlay hints for the __builtin_dump_struct, which would
+// expand to a PseudoObjectExpr that include
@@ -1724,6 +1724,33 @@ TEST(InlayHints, RestrictRange) {
ElementsAre(labelIs(": int"), labelIs(": char")));
}
+TEST(ParameterHints, PseudoObjectExpr) {
+ Annotations Code(R"cpp(
+struct S {
+ __declspec(property(get=GetX, put=PutX)) int x[];
+ int
@@ -1724,6 +1724,33 @@ TEST(InlayHints, RestrictRange) {
ElementsAre(labelIs(": int"), labelIs(": char")));
}
+TEST(ParameterHints, PseudoObjectExpr) {
+ Annotations Code(R"cpp(
+struct S {
+ __declspec(property(get=GetX, put=PutX)) int x[];
+ int
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 `DeclC
HighCommander4 wrote:
A somewhat narrow use case where this approach might be workable is unity
builds (groups of source files batched together to be compiled as a single
translation unit for build performance).
That's a situation where the non-self-contained files of interest (the
individual
https://github.com/HighCommander4 approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/70285
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/HighCommander4 closed
https://github.com/llvm/llvm-project/pull/70285
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
HighCommander4 wrote:
What is the relationship between this patch, and clangd 17's ["missing include"
warning](https://clangd.llvm.org/guides/include-cleaner#missing-include-warning)?
Does the quick-fix for the "missing include" warning also respect these config
options?
https://github.com/ll
HighCommander4 wrote:
> Explicitly pinging @kadircet and @sam-mccall for your involvement in the
> mentioned commit. What are your thoughts on this? I looked into this because
> someone on discord asked about this difference.
Added Sam and Kadir as reviewers.
This patch seems to contradict th
https://github.com/HighCommander4 requested changes to this pull request.
Thanks for having a look at this!
Instead of performing the "expand response files" operation twice for commands
coming from a `compile_commands.json` source, what do you think about the
following:
* Restore the call i
https://github.com/HighCommander4 commented:
Thanks for the patch!
I like the idea of having the server announce support for a list of languages,
that seems nice and general and extensible.
A couple of thoughts:
1. Since the key we're adding to the server capabilities is a non-standard
exte
https://github.com/HighCommander4 approved this pull request.
LGTM, thanks for the fix and test!
https://github.com/llvm/llvm-project/pull/75753
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe
https://github.com/HighCommander4 closed
https://github.com/llvm/llvm-project/pull/75753
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
HighCommander4 wrote:
Thanks for the patch.
For the test, it would be better to write it in [this
format](https://github.com/llvm/llvm-project/tree/main/clang/test/CodeCompletion)
rather than using clangd.
https://github.com/llvm/llvm-project/pull/75937
___
HighCommander4 wrote:
> What about a slightly different take? What if in addition to adding
> `clangdLanguages` (without HLSL) we also add `clangdExperimentalFeatures` and
> add `HLSL` there. The problem I'm trying to solve here is to avoid someone
> enabling HLSL on a language server that doe
@@ -589,6 +589,24 @@ class InlayHintVisitor : public
RecursiveASTVisitor {
return true;
}
+ bool TraversePseudoObjectExpr(PseudoObjectExpr *E) {
+// Do not show inlay hints for the __builtin_dump_struct, which would
+// expand to a PseudoObjectExpr that include
@@ -1724,6 +1724,36 @@ TEST(InlayHints, RestrictRange) {
ElementsAre(labelIs(": int"), labelIs(": char")));
}
+TEST(ParameterHints, PseudoObjectExpr) {
+ Annotations Code(R"cpp(
+struct S {
+ __declspec(property(get=GetX, put=PutX)) int x[];
+ int
@@ -1724,6 +1724,33 @@ TEST(InlayHints, RestrictRange) {
ElementsAre(labelIs(": int"), labelIs(": char")));
}
+TEST(ParameterHints, PseudoObjectExpr) {
+ Annotations Code(R"cpp(
+struct S {
+ __declspec(property(get=GetX, put=PutX)) int x[];
+ int
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 th
HighCommander4 wrote:
Thanks, the behaviour changes look reasonable to me.
> I haven't update the test because the hard-coded limit 10 makes it hard to
> write the tests. Any opinion of how to structure this?
I would suggest running most tests with `HintMinLineLimit = 2` (and then have
one te
https://github.com/HighCommander4 requested changes to this pull request.
(see previous comment)
https://github.com/llvm/llvm-project/pull/72345
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe
@@ -585,6 +585,17 @@ TEST_F(TokenCollectorTest, DelayedParsing) {
EXPECT_THAT(collectAndDump(Code), StartsWith(ExpectedTokens));
}
+TEST_F(TokenCollectorTest, UnclosedToken) {
HighCommander4 wrote:
I started looking at this to try and make some progress tow
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 instantia
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++
tem
@@ -585,6 +585,17 @@ TEST_F(TokenCollectorTest, DelayedParsing) {
EXPECT_THAT(collectAndDump(Code), StartsWith(ExpectedTokens));
}
+TEST_F(TokenCollectorTest, UnclosedToken) {
HighCommander4 wrote:
Indeed, it looks like `TokenBuffer::spelledForExpanded()` (
https://github.com/HighCommander4 approved this pull request.
LGTM, thank you!
https://github.com/llvm/llvm-project/pull/71366
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/HighCommander4 closed
https://github.com/llvm/llvm-project/pull/71366
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
HighCommander4 wrote:
I spent a bit more time looking at this. I'd say I'm still quite far from
having a complete understanding of this code, but two things occur to me:
1. `TokenBuffer` operates at the level of the preprocessor.
"spelledForExpanded" is basically an operation which takes as i
https://github.com/HighCommander4 created
https://github.com/llvm/llvm-project/pull/76492
Fixes https://github.com/clangd/clangd/issues/1873
>From b60a2515bbfbfc79bc3b0bb81ef6fe1db13404bd Mon Sep 17 00:00:00 2001
From: Nathan Ridge
Date: Thu, 28 Dec 2023 02:47:04 -0500
Subject: [PATCH] [clangd
https://github.com/HighCommander4 updated
https://github.com/llvm/llvm-project/pull/76492
>From ec31d400915dba372501c49db8bab7c8123228df Mon Sep 17 00:00:00 2001
From: Nathan Ridge
Date: Thu, 28 Dec 2023 02:47:04 -0500
Subject: [PATCH] [clangd] Avoid crash when summarizing pointer-to-member exp
HighCommander4 wrote:
> btw, it looks like there is a FIXME
> (https://github.com/llvm/llvm-project/blob/main/clang/lib/AST/ExprCXX.cpp#L677)
> for supporting this particular case.
I saw it, but I'm not clear on what that would look like.
Which member function a member function pointer resolv
https://github.com/HighCommander4 closed
https://github.com/llvm/llvm-project/pull/76492
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
HighCommander4 wrote:
> You mentioned `inconsistencies`, is it inside clangd or in other places that
> surface clang-tidy findings?
I understood it as, the appearance of `modernize-*` clang-tidy diagnostics in
the editor is not consistent with the appearance of other (non-`modernize-*`)
clang
https://github.com/HighCommander4 approved this pull request.
Thanks, the change looks good to me!
I went through the existing callers of `Node::getDeclContext()`, and I was able
to construct a test case where the patch actually changes behaviour (in a good
way):
```c++
namespace NS {
void un
HighCommander4 wrote:
> Happy New Year 2024!
You too!
https://github.com/llvm/llvm-project/pull/76329
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/HighCommander4 approved this pull request.
Thanks, LGTM!
https://github.com/llvm/llvm-project/pull/75694
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/HighCommander4 approved this pull request.
Thanks, looks good with the added comments.
https://github.com/llvm/llvm-project/pull/76668
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis
1 - 100 of 974 matches
Mail list logo
