Prototyping a test runner feature using code lenses

[jonasbb]

I am prototyping a way to use the code lens feature to run tests individually.

1. Is there a way to determine which functions have the #[test] annotation? Unfortunately there is nothing similar in the save-analysis data.
2. VS Code performs the code lens request right after opening the file. At this point the save-analysis data is not yet loaded and requests to self.analysis.symbols() fail.
   What would be a good way to synchronize a thread with the build thread such that the data is always loaded. Ideally, this would also allow me to wait for any re-builds after a change. This way I can ensure that the save-analysis data is always up-to-date and all ranges in the code lenses match the current file.

For 2. I was thinking that an atomic counter and a Condvar might work. The Condvar allows any thread to sleep until new save-analysis data is loaded. The atomic counter allows the thread to know that the save-analysis data is newer.

1. Code Lens thread performs an atomic increment_and_get on the counter, stores the value in a variable, say c, and waits on the Condvar
2. The build thread has finished building, performs the increment_and_get on the counter, stores both the counter value, say sa-c, and the save-analysis data, and notifies all threads waiting on the Condvar
3. Any thread now woken up compares c with sa-c. If sa-c < c wait again otherwise the data can be used.

[nrc]

1

I don't think there is a good way to do this. It seems reasonable to add attributes to declarations in save-analysis, so if you wanted to add that in the compiler, that seems like the best way (I can help if you want to get stuck in there). Failing that, you would need to just search the text of the function (iirc the attributes are included in the span of the function). You would need to take comments in to account here.

2

Why do you need the save-analysis to be up to date? In most cases I would think it would not affect your code (e.g., we do not wait for doing jump to def, we try to make this work as soon as possible). There is only ever one version of save-analysis data, so you can never have older data (if I understand what you are proposing correctly). I.e., if you get a notification that there is new data, it will always be more recent than the last data you saw.

If that is correct, then it seems that all you need to do is sleep if there is no data at all, and then I think a condvar is all you need.

[jonasbb]

I think the only stable way is to include this information in the save-analysis data. If I can use the save-analysis data as my only source then I don't think ordering matters anymore. Can you point me to the parts of the compiler which I would need to change for this?

What I did for testing is to see if the line before the function symbol is #[test]. (Which is of course totally broken). The problem if I use the file content and save-analysis data is that they may be out of sync and the function range does not contain the annotation anymore. Therefore, some synchronizing would be needed. But my idea from above would not help me in insuring that vfs and analysis are based on the same content. It would only ensure that the analysis data is at least as knew as the code lens request.

EDIT:
There can be older data. Consider this:

1. build starts
2. changes accumulate
3. code lens request
4. build finishes

=> The analysis data in 4. is older then the code lens request and because of the changes in 2. the spans might be inaccurate.

If I only need to sleep on the first time, I would need to put the condvar somewhere in the AnalysisHost to use the mutex around analysis such that there are no races. Thinking about it. It might make sense to implement it there. This would fix all problems related to non-available analysis, e.g., the symbols request is also affected by it.

[nrc]

For the save-analysis data, look at the librustc_save_analysis crate. In particular, look at get_item_data: https://github.com/rust-lang/rust/blob/master/src/librustc_save_analysis/lib.rs#L119. You'd need to propagate an attributes field through the various lowering steps into JSON data.

I don't think you should worry so much about being absolutly in sync. In most cases, if you get recent data it will be good enough. And if it is not good enough, you might miss a test or something for the user for a few seconds - as long as you don't crash, I don't think that is a problem.

[nrc]

Hi @jonasbb did you get any further with this? It sounded like a really interesting idea and I'm interested to know about the ways we can stretch stuff like code lens to make cool features.