Details
Diff Detail
- Repository
- rCTE Clang Tools Extra
- Build Status
Buildable 25218 Build 25217: arc lint + arc unit
Event Timeline
The tests still model the old callbacks using callbacks, unfortunately I see no good way to test same things in any other way.
Nice!
The biggest suggestion I have is merging the callback into ASTCallbacks. That's awkward in initialization (makeUpdateCallbacks probably needs to be called unconditionally with a maybe-null pointer) but it seems like a natural grouping in all the places it gets plumbed around to... and there are a lot!
clangd/ClangdServer.h | ||
---|---|---|
232 | I'm not sure using context here buys much: there aren't many layers, they're fairly coupled, and this information would look pretty natural in the interfaces. What about:
| |
clangd/TUScheduler.h | ||
93 | ISTM the callback would fit nicely on the ASTCallbacks? | |
unittests/clangd/TUSchedulerTests.cpp | ||
32 | (up to you if you feel like fixing while here) | |
36 | Yeah, these are messy. I also don't see something better in general. There's a place or two below where I think we can avoid them without much verbosity, which I think is probably worthwhile even if lots of tests need them :-/ | |
38 | ParseInputs is always getInputs(File), you could do that here (similarly for updateWithDiags) to avoid repetition. | |
501 | can we just increment a counter in the callback, and have DoUpdate look for a delta? |
- Merge the diagnostics callback into ParsingCallbacks
- updateWithDiags(File, getInputs(File...)) -> updateWithDiags(File, ...)
clangd/ClangdServer.h | ||
---|---|---|
232 | I'd keep it separate: ParseInputs is defined in ClangdUnit.cpp and it serves the purpose of defining everything we need to run the compiler. I would rather aim to get rid of DocVersion (for this particular purpose, there are other ways to fix the raciness that the DocVersions workaround). | |
clangd/TUScheduler.h | ||
93 | Done. This is definitely less plumbing, but IMO the public interface looks a bit worse now. But we don't have too many callers, updating those is easy. | |
unittests/clangd/TUSchedulerTests.cpp | ||
32 | Will fix in a separate commit, like it more when cleanups are the only thing in the commit. | |
38 | It's actually a bit more complicated: getInputs(File, Contents), note the second parameter. The calls are now updateWith(S, File, Contents...), there's one place that still relies on the Inputs though (checks the VFS does not change in the following read). | |
501 | Maybe... I haven't looked closely into the test, would prefer to keep this change mostly mechanical and avoid digging into the test logic. |
Just the context thing. Rest is some optional simplifications.
clangd/ClangdServer.cpp | ||
---|---|---|
77 | hmm, the double-indirection for diags seems a bit funny, especially since we have a dedicated method on ClangdServer so the lambda is trivial. Maybe we should just make the CB class nested or friend in ClangdServer, and pass it a ClangdServer*? Then it can access DynamicIdx and consumeDiagnostics directly. The decoupling here isn't that strong to start with. | |
clangd/ClangdServer.h | ||
232 | Yeah, separating it from ParseInputs makes sense conceptually, and getting rid of it is indeed better. I don't think this justifies using Context. Passing it as a separate parameter seems fine to me. Putting it in ParseInputs with a FIXME is a little less principled but avoids interface churn. | |
clangd/TUScheduler.cpp | ||
156 | nit: we generally have the private section at the top without explicitly introducing it (as common in LLVM), or at the bottom. I'm fine with either style but would prefer not to add a third. | |
clangd/TUScheduler.h | ||
93 | (Separate yes, but I'm not sure they're that much more separate than consuming preambles vs ASTs, really. Outside of the 2/1 split of where the data goes today...) | |
unittests/clangd/TUSchedulerTests.cpp | ||
38 | Exactly, thanks! | |
501 | It seems like a trivial change, and it'd be nice not to depend on the new machinery you're introducing here when we don't have to. atomic<unsigned> DiagsReceived; TUScheduler S(..., [&](Diags) { ++ DiagsReceived }, ...); ... DoUpdate = [&] -> bool { // as before unsigned PrevDiags = DiagsReceived; S.update(...); blockUntilIdle(); // as before return DiagsReceived != PrevDiags; } |
clangd/ClangdServer.cpp | ||
---|---|---|
77 | I would avoid doing that, because ClangdServer is not thread-safe and giving the async callbacks that run on a different threads an access to the full class is scary. After D54829, there's no need for double-indirection too, the callback is simply directly calling into the diagnostics consumer, so it shouldn't be an issue. | |
clangd/ClangdServer.h | ||
232 | The versions are not too hard to remove, here's the change that does this: D54829 | |
clangd/TUScheduler.cpp | ||
156 | Yeah, sorry, that was an accidental change. | |
clangd/TUScheduler.h | ||
93 |
ASTs and resulting diagnostics are on different layers of abstraction, so I don't think they fit well in the same interface, even if the data-flow for those is similar. |
I'm not sure using context here buys much: there aren't many layers, they're fairly coupled, and this information would look pretty natural in the interfaces.
What about: