Should we also have another test for SymbolCollector, to ensure we don't regress this somehow in the future?
thanks! this mostly looks good, as discussed offline I believe having an infra that we can improve over time is better than not having anything until we've got the "perfect" solution.
Mon, Sep 28
Fri, Sep 25
Thu, Sep 24
(I do wonder whether it's safe to just drop the mapping table entirely now...)
Wed, Sep 23
Hey! Sorry for the late reply, this has been open in my tabs since day 1 just didn't get a chance to take a look at it.
Thanks! This looks great. I've mostly did the full review anyway but feel free to land in small patches just in case some compiler becomes upset and you need to revert.
Mon, Sep 21
Just for the record, as I think Kadir and Adam are both aware...
We discussed making this a bit richer and less reliant on static state.
We'd build a tree-shaped profile by passing a tree-builder recursively into various components.
Then the metrics would be exported at the top level, but we'd also want to expose it via debugging actions. (The tree edges from e.g. dynamic index to individual files would probably be optional - collapsed for metrics but present for debugging)
LMK if I have this wrong and you want to move forward with a simpler approch.
Wed, Sep 16
Tue, Sep 15
oh shoot, thanks for catching this. i'll leave the stamp to sam, just came here to remind that this needs to be cherry-picked into release branch :/
oops, looks like i forgot to hit submit in the morning..
Thanks! Mostly looks good, just couple of nits.
Mon, Sep 14
Fri, Sep 11
Wed, Sep 9
thanks, comments around some implementations. the only high level question i have is about the choice of location for fix-it (see the detailed comment inline)
Tue, Sep 8
As discussed offline, this is trading off some accuracy between getting -I correct vs -std and it is unclear whether that's beneficial or harmful. It is easy to come up with examples for both and we were split 50/50 between each.
In the end all of this is a heuristic work and it is quite likely that we might break this for more people, while trying to fix this one specific case. So I don't think it's worth it.
Aug 20 2020
Aug 17 2020
- Rename the overload
- Add comments around possible caveats that might result in inaccuracies.
- Move the metric recording itself into another thread.
- Keep the calculations in the main thread, as they seemed to have <1ms latency, even with huge preambles/asts.
Aug 13 2020
- Address comments
no I am totally fine with the change. I just wanted to give Adam some time to take a look too :D
mostly looks good to me, as discussed offline I would rather expose AST within a thread, both to keep the API changes to a minimum in the future and possibly indicating the "view-ness" of the exposed structs like AST more explicitly.
Aug 12 2020
- Change logic to find all signatures without any dependent args and post filter non-viable overloads using the argument counts.
- Fix typo in comment
- Add tests into clang-lit
- Make sure current number of args is less than overloads param count.
Aug 11 2020
thanks, lgtm. mostly comments arounds tests, sorry for not looking at them before.
- Move new test closer to other FakeHeaderGuard tests.
- Drop the comment
Aug 10 2020
Aug 8 2020
Aug 7 2020
Regarding tests, it feels like we can also test this in ASTUnitTests which is directly in clang, as it is also using PrecompiledPreamble::Build. What about moving the test there instead?
Aug 5 2020
you might want this to be cherry-picked into 11 release
I'm not quite sure there should be no tooltip for a #define. Such tooltip is not really useful, but at the same time clangd shows tooltips for function declarations/defnitions, namespaces, variables, etc. and not showing it for macro definition will be a little bit inconsistent from my point of view.
- Address comments
Sigh, (I think) this is working for macros defined in preamble region as a side effect of preamble being loaded separately and before anything in the main file. E.g.
Aug 3 2020
- Change bitwise assignment to logical operators, as bitwise operators do not have short-circuting.
- Rename AlreadyHas to ShouldAdd (and revert the logic)