This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Record the file being processed in a TUScheduler thread in context.
ClosedPublic

Authored by ioeric on Aug 8 2018, 6:17 AM.

Details

Summary

This allows implementations like different symbol indexes to know what
the current active file is. For example, some customized index implementation
might decide to only return results for some files.

Diff Detail

Repository
rL LLVM

Event Timeline

ioeric created this revision.Aug 8 2018, 6:17 AM

Short summary of the offline discussion: I suggest adding this parameter into the corresponding requests of the index (FuzzyFindRequest, FindDefinitionsRequest) instead of stashing it in the context. Context has all the same problems as the global variables, so we should try to avoid using it where possible.
On the other hand, where this key is stored might not be terribly important if we don't have too many usages and remove it when we can workaround the limitations that we're currently facing.

In any case, we should add a comment that the active file should be avoided and will be removed.

clangd/ClangdServer.cpp
162 ↗(On Diff #159701)

If we want to set this value more consistently, maybe do it in TUScheduler::runWithPreamble/runWithAST?
All interesting operations that work on files go through those, so it's easier to certify that the file is set correctly.

clangd/Context.cpp
35 ↗(On Diff #159701)

Maybe move it somewhere else? E.g. to Index.h, since that's where it's supposed to be used to workaround current limitations?
Context.h/cpp is a general-purpose support library for the contexts, application-specific keys do not fit in well there.

35 ↗(On Diff #159701)

Maybe use std::string? Contexts can easily be cloned/migrated between threads, so it's very easy to end up with pointers to dead strings here.

clangd/Context.h
223 ↗(On Diff #159701)

Maybe choose a scarier name and add a comment that we're not gonna use it in the long-term?
Maybe also add a comment that this is only used in our index implementation to workaround the limitations of the current design?

ioeric added a comment.Aug 8 2018, 7:36 AM

Short summary of the offline discussion: I suggest adding this parameter into the corresponding requests of the index (FuzzyFindRequest, FindDefinitionsRequest) instead of stashing it in the context. Context has all the same problems as the global variables, so we should try to avoid using it where possible.

Thanks for the summary! Just for the record, my concerns were:

  1. The concept of active files are not really index-specific.
  2. We need to do this for all 3 different requests (need "scary" comments 3 places?).
  3. The context value seems to be trivial enough and hard to be misused.

On the other hand, where this key is stored might not be terribly important if we don't have too many usages and remove it when we can workaround the limitations that we're currently facing.

clangd/ClangdServer.cpp
162 ↗(On Diff #159701)

I have two concerns about doing this:

  1. Setting it in the TUScheduler seems to bury this deeper e.g. into scheduling logic. Limiting this in specific callbacks right before it's needed seems to make it less accessible.
  1. There are operations like workspaceSymbols (although not handled in this patch) that do not go through TUScheduler.
clangd/Context.cpp
35 ↗(On Diff #159701)

I intentionally used StringRef here to make it harder to use and hoped that users would be more careful when using this. For the current simple use cases, StringRef should be sufficient IMO.

35 ↗(On Diff #159701)

We should probably look for some other place to put this, but I don't think Index.h is the right place. Although context might not be the best place to host the active file, the active file seems to be a well-defined concept in clangd in general and not index-specific.

ilya-biryukov added inline comments.Aug 8 2018, 8:27 AM
clangd/ClangdServer.cpp
162 ↗(On Diff #159701)
  1. Setting it in the TUScheduler seems to bury this deeper e.g. into scheduling logic. Limiting this in specific callbacks right before it's needed seems to make it less accessible.

If we want to make the data-flow explicit, let's add this to the index request parameters.
Otherwise, I suggest we do something consistent across all requests, rather than special-casing the index-calling ones. E.g. if someone adds an index call in onHover, they'll need to remember to also update the ClangdServer call to set this value and they really shouldn't care about this hack of ours. The less intrusive this thing is, the better.

  1. There are operations like workspaceSymbols (although not handled in this patch) that do not go through TUScheduler.

And we don't set the file path for them anyway, because there's not active file in that case. How is that different in either of the approaches?

clangd/Context.cpp
35 ↗(On Diff #159701)

Maybe move it ClangdServer.h or TUScheduler,h then? (depending on where we set it).

I still don't think Context.h is the right place for it, it should not contain any application-specific keys.

35 ↗(On Diff #159701)

We're relying too much on the data flow of contexts, which is implicit and we completely don't control. Even if we don't access dead StringRefs now, it's very easy to accidentally introduce this behavior later.

We should use string here, there's just too high risk of hitting a bug otherwise. What are the disadvantages of using string here?

ioeric updated this revision to Diff 159746.Aug 8 2018, 9:52 AM
ioeric marked 3 inline comments as done.
  • Addressed review comments.
ioeric added a comment.Aug 8 2018, 9:53 AM

Ok, I am convinced :) Putting the context key into TUScheduler.cpp and exposing a static method to access it sound like a better idea afterall. Thanks for the suggestions!

ioeric retitled this revision from [clangd] Record the currently active file in context for codeCompletion and findDefinitions. to [clangd] Record the file being processed in a TUScheduler thread in context..Aug 9 2018, 1:49 AM
ilya-biryukov accepted this revision.Aug 9 2018, 1:59 AM

LGTM. Thanks!

clangd/TUScheduler.h
145 ↗(On Diff #159746)

NIT: accidental whitespace change?

This revision is now accepted and ready to land.Aug 9 2018, 1:59 AM
This revision was automatically updated to reflect the committed changes.