Prototyping a test runner feature using code lenses #173
Comments
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.
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. |
|
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 EDIT:
=> 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 |
|
For the save-analysis data, look at the librustc_save_analysis crate. In particular, look at 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. |
Export attributes in save-analysis data Since this is my first pull-request to rust, I would like to get some feedback about obvious errors in this implementation. I would like to change the save-analysis data to include arbitrary attribute data. A use-case I have in mind for this is identifying functions with `#[test]` annotations such that tools like rls can offer a test-runner feature. I described my idea here [rls#173](rust-lang/rls#173). My changes contain: 1. track a vector of attributes in the various `*Data` types in `data.rs` and `external_data.rs` 2. implement lowering for `Attribute` and `MetaItem` 3. adjust `JsonDumper` to print the attributes In the lowering of `Attribute` I remove the distinction between `MetaItem` and `NestedMetaItem`. I did this because this distinction is somewhat confusing. For example, `NestedMetaItemKind::Literal` has two identical spans, because both `NestedMetaItem` and `Lit` are defined as `Spanned<_>`. My model is strictly more general, as it allows an `LitKind` instead of a `Symbol` for `MetaItem` and `Symbol`s are converted into a cooked string. As a consumer of the save-analysis data this shouldn't affect you much. Example json output of `#[test]` annotation: ``` "attributes": [ { "value": { "name": { "variant": "Str", "fields": [ "test", "Cooked" ] }, "kind": "Literal", "span": { "file_name": "test.rs", "byte_start": 2, "byte_end": 6, "line_start": 1, "line_end": 1, "column_start": 3, "column_end": 7 } }, "span": { "file_name": "test.rs", "byte_start": 0, "byte_end": 7, "line_start": 1, "line_end": 1, "column_start": 1, "column_end": 8 } } ] ```
Export attributes in save-analysis data Since this is my first pull-request to rust, I would like to get some feedback about obvious errors in this implementation. I would like to change the save-analysis data to include arbitrary attribute data. A use-case I have in mind for this is identifying functions with `#[test]` annotations such that tools like rls can offer a test-runner feature. I described my idea here [rls#173](rust-lang/rls#173). My changes contain: 1. track a vector of attributes in the various `*Data` types in `data.rs` and `external_data.rs` 2. implement lowering for `Attribute` and `MetaItem` 3. adjust `JsonDumper` to print the attributes In the lowering of `Attribute` I remove the distinction between `MetaItem` and `NestedMetaItem`. I did this because this distinction is somewhat confusing. For example, `NestedMetaItemKind::Literal` has two identical spans, because both `NestedMetaItem` and `Lit` are defined as `Spanned<_>`. My model is strictly more general, as it allows an `LitKind` instead of a `Symbol` for `MetaItem` and `Symbol`s are converted into a cooked string. As a consumer of the save-analysis data this shouldn't affect you much. Example json output of `#[test]` annotation: ``` "attributes": [ { "value": { "name": { "variant": "Str", "fields": [ "test", "Cooked" ] }, "kind": "Literal", "span": { "file_name": "test.rs", "byte_start": 2, "byte_end": 6, "line_start": 1, "line_end": 1, "column_start": 3, "column_end": 7 } }, "span": { "file_name": "test.rs", "byte_start": 0, "byte_end": 7, "line_start": 1, "line_end": 1, "column_start": 1, "column_end": 8 } } ] ```
Export attributes in save-analysis data Since this is my first pull-request to rust, I would like to get some feedback about obvious errors in this implementation. I would like to change the save-analysis data to include arbitrary attribute data. A use-case I have in mind for this is identifying functions with `#[test]` annotations such that tools like rls can offer a test-runner feature. I described my idea here [rls#173](rust-lang/rls#173). My changes contain: 1. track a vector of attributes in the various `*Data` types in `data.rs` and `external_data.rs` 2. implement lowering for `Attribute` and `MetaItem` 3. adjust `JsonDumper` to print the attributes In the lowering of `Attribute` I remove the distinction between `MetaItem` and `NestedMetaItem`. I did this because this distinction is somewhat confusing. For example, `NestedMetaItemKind::Literal` has two identical spans, because both `NestedMetaItem` and `Lit` are defined as `Spanned<_>`. My model is strictly more general, as it allows an `LitKind` instead of a `Symbol` for `MetaItem` and `Symbol`s are converted into a cooked string. As a consumer of the save-analysis data this shouldn't affect you much. Example json output of `#[test]` annotation: ``` "attributes": [ { "value": { "name": { "variant": "Str", "fields": [ "test", "Cooked" ] }, "kind": "Literal", "span": { "file_name": "test.rs", "byte_start": 2, "byte_end": 6, "line_start": 1, "line_end": 1, "column_start": 3, "column_end": 7 } }, "span": { "file_name": "test.rs", "byte_start": 0, "byte_end": 7, "line_start": 1, "line_end": 1, "column_start": 1, "column_end": 8 } } ] ```
Export attributes in save-analysis data Since this is my first pull-request to rust, I would like to get some feedback about obvious errors in this implementation. I would like to change the save-analysis data to include arbitrary attribute data. A use-case I have in mind for this is identifying functions with `#[test]` annotations such that tools like rls can offer a test-runner feature. I described my idea here [rls#173](rust-lang/rls#173). My changes contain: 1. track a vector of attributes in the various `*Data` types in `data.rs` and `external_data.rs` 2. implement lowering for `Attribute` and `MetaItem` 3. adjust `JsonDumper` to print the attributes In the lowering of `Attribute` I remove the distinction between `MetaItem` and `NestedMetaItem`. I did this because this distinction is somewhat confusing. For example, `NestedMetaItemKind::Literal` has two identical spans, because both `NestedMetaItem` and `Lit` are defined as `Spanned<_>`. My model is strictly more general, as it allows an `LitKind` instead of a `Symbol` for `MetaItem` and `Symbol`s are converted into a cooked string. As a consumer of the save-analysis data this shouldn't affect you much. Example json output of `#[test]` annotation: ``` "attributes": [ { "value": { "name": { "variant": "Str", "fields": [ "test", "Cooked" ] }, "kind": "Literal", "span": { "file_name": "test.rs", "byte_start": 2, "byte_end": 6, "line_start": 1, "line_end": 1, "column_start": 3, "column_end": 7 } }, "span": { "file_name": "test.rs", "byte_start": 0, "byte_end": 7, "line_start": 1, "line_end": 1, "column_start": 1, "column_end": 8 } } ] ```
Export attributes in save-analysis data Since this is my first pull-request to rust, I would like to get some feedback about obvious errors in this implementation. I would like to change the save-analysis data to include arbitrary attribute data. A use-case I have in mind for this is identifying functions with `#[test]` annotations such that tools like rls can offer a test-runner feature. I described my idea here [rls#173](rust-lang/rls#173). My changes contain: 1. track a vector of attributes in the various `*Data` types in `data.rs` and `external_data.rs` 2. implement lowering for `Attribute` and `MetaItem` 3. adjust `JsonDumper` to print the attributes In the lowering of `Attribute` I remove the distinction between `MetaItem` and `NestedMetaItem`. I did this because this distinction is somewhat confusing. For example, `NestedMetaItemKind::Literal` has two identical spans, because both `NestedMetaItem` and `Lit` are defined as `Spanned<_>`. My model is strictly more general, as it allows an `LitKind` instead of a `Symbol` for `MetaItem` and `Symbol`s are converted into a cooked string. As a consumer of the save-analysis data this shouldn't affect you much. Example json output of `#[test]` annotation: ``` "attributes": [ { "value": { "name": { "variant": "Str", "fields": [ "test", "Cooked" ] }, "kind": "Literal", "span": { "file_name": "test.rs", "byte_start": 2, "byte_end": 6, "line_start": 1, "line_end": 1, "column_start": 3, "column_end": 7 } }, "span": { "file_name": "test.rs", "byte_start": 0, "byte_end": 7, "line_start": 1, "line_end": 1, "column_start": 1, "column_end": 8 } } ] ```
Export attributes in save-analysis data Since this is my first pull-request to rust, I would like to get some feedback about obvious errors in this implementation. I would like to change the save-analysis data to include arbitrary attribute data. A use-case I have in mind for this is identifying functions with `#[test]` annotations such that tools like rls can offer a test-runner feature. I described my idea here [rls#173](rust-lang/rls#173). My changes contain: 1. track a vector of attributes in the various `*Data` types in `data.rs` and `external_data.rs` 2. implement lowering for `Attribute` and `MetaItem` 3. adjust `JsonDumper` to print the attributes In the lowering of `Attribute` I remove the distinction between `MetaItem` and `NestedMetaItem`. I did this because this distinction is somewhat confusing. For example, `NestedMetaItemKind::Literal` has two identical spans, because both `NestedMetaItem` and `Lit` are defined as `Spanned<_>`. My model is strictly more general, as it allows an `LitKind` instead of a `Symbol` for `MetaItem` and `Symbol`s are converted into a cooked string. As a consumer of the save-analysis data this shouldn't affect you much. Example json output of `#[test]` annotation: ``` "attributes": [ { "value": { "name": { "variant": "Str", "fields": [ "test", "Cooked" ] }, "kind": "Literal", "span": { "file_name": "test.rs", "byte_start": 2, "byte_end": 6, "line_start": 1, "line_end": 1, "column_start": 3, "column_end": 7 } }, "span": { "file_name": "test.rs", "byte_start": 0, "byte_end": 7, "line_start": 1, "line_end": 1, "column_start": 1, "column_end": 8 } } ] ```
Export attributes in save-analysis data Since this is my first pull-request to rust, I would like to get some feedback about obvious errors in this implementation. I would like to change the save-analysis data to include arbitrary attribute data. A use-case I have in mind for this is identifying functions with `#[test]` annotations such that tools like rls can offer a test-runner feature. I described my idea here [rls#173](rust-lang/rls#173). My changes contain: 1. track a vector of attributes in the various `*Data` types in `data.rs` and `external_data.rs` 2. implement lowering for `Attribute` and `MetaItem` 3. adjust `JsonDumper` to print the attributes In the lowering of `Attribute` I remove the distinction between `MetaItem` and `NestedMetaItem`. I did this because this distinction is somewhat confusing. For example, `NestedMetaItemKind::Literal` has two identical spans, because both `NestedMetaItem` and `Lit` are defined as `Spanned<_>`. My model is strictly more general, as it allows an `LitKind` instead of a `Symbol` for `MetaItem` and `Symbol`s are converted into a cooked string. As a consumer of the save-analysis data this shouldn't affect you much. Example json output of `#[test]` annotation: ``` "attributes": [ { "value": { "name": { "variant": "Str", "fields": [ "test", "Cooked" ] }, "kind": "Literal", "span": { "file_name": "test.rs", "byte_start": 2, "byte_end": 6, "line_start": 1, "line_end": 1, "column_start": 3, "column_end": 7 } }, "span": { "file_name": "test.rs", "byte_start": 0, "byte_end": 7, "line_start": 1, "line_end": 1, "column_start": 1, "column_end": 8 } } ] ```
|
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. |
I am prototyping a way to use the code lens feature to run tests individually.
#[test]annotation? Unfortunately there is nothing similar in the save-analysis data.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
Condvarmight work. TheCondvarallows 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.increment_and_geton the counter, stores the value in a variable, sayc, and waits on theCondvarincrement_and_geton the counter, stores both the counter value, saysa-c, and the save-analysis data, and notifies all threads waiting on theCondvarcwithsa-c. Ifsa-c<cwait again otherwise the data can be used.The text was updated successfully, but these errors were encountered: