I can't fully remember the discussion but what about the case in which we don't have a declaration in the main file, but see a definition and multiple forward declarations. Is there a good reason to still include re-decls in this case?
for whatever reason I remembered the std::remove to have been referenced ~17k. looks like these two are much closer. I don't think it makes sense to prefer one or the other here.
Tue, Nov 30
Mon, Nov 29
Fri, Nov 26
My main remaining concern is just that this will trigger too often when there's no confusion over types, and clutter the display.
Some common cases I'm worried about:
- std::string -> basic_string<char>. Maybe we should special-case this to hide the aka?
- int64_t vs long long et al. I have no idea what to do about this.
Sorry for forgetting about this one. Hopefully I can still help now by disagreeing with Kadir and creating an awkward stalemate instead.
It's annoying that we see comments and inclusion directives out-of-order, we can try fixing it on the parser side (I think it is incidental that these are issued in that order currently, they are eagerly trying to generate a fix/diagnostic for tokens after a pp-directive. hence we can first issue the PP callback, and then diagnose for rest of the line instead).
But I don't think it matters in the long run especially when we want to handle different types of pragmas in the future (which is the plan IIRC), they might not even necessarily be in the main file, let alone being seen with right sequencing.
Thu, Nov 25
Wed, Nov 24
As discussed offline this definitely LGTM, let me summarize the reasoning here.
Tue, Nov 23
thanks, lgtm! let me know of your email address (for commit attribution) if you want me to land this for you.
thanks, LG in general, just a couple polishing touches
Mon, Nov 22
Wed, Nov 17
I agree with Nathan on this one. It's unclear why there are two functions that does the same thing in different ways and some usages in sema looks suspicious enough to require caution (there are subtle checks for shadowing and whatnot and I don't know how these rules come into play in objc contexts).
Tue, Nov 16
Mon, Nov 15
Sat, Nov 13
Fri, Nov 12
I got a couple of concerns about the general ideas in the change. Even though the convenience of using ~/.config/clangd/config.yaml seems nice, I think it'll just end up creating confusion in the long run.
Wed, Nov 10
Mon, Nov 8
Thu, Nov 4
thanks this looks amazing! i am also not an expert in these parts of the code but AFAICT the proposed behavior is in line with the contract. i am a little worried about the cost of extra copy (especially when there are only a handful of elements), but it should be probably fine.
Oct 29 2021
oops forgot to LGTM, thanks!
Oct 28 2021
Oct 27 2021
Oct 26 2021
(oops, i didn't notice i wasn't the reviewer :D)
Oct 25 2021
I suppose this is obseleted by https://reviews.llvm.org/D111260
Thanks for fixing this, LGTM! (This also reminds me that we should probably invalidate preambles on config changes one day)
Oct 20 2021
- Rather than dropping the entry, perform an extra check during invalidate. As
the entry actually backs the data for main file strings in associations.
Oct 19 2021
Oct 8 2021
thanks, mostly LG, a couple of nits :)
Oct 6 2021
- Improve tests
- split changes in libindex
- fix the issue with non-traversal of forward-decls
- add unittests into RAV
- Fix tests
Oct 5 2021
Oct 4 2021
Oct 1 2021
- update comments
Sep 30 2021
- Use isImplicit rather than earlyClaim
Sep 29 2021