Open Veetaha opened 2 years ago
The heuristic seems to still be there, but it might be that we changed it by accident so that the heuristic only looks at the expansion results of the attribute macros(which sounds very likely to have happened). You should be able to test that by adding your proc-macro to the ignore setting or momentarily turn off attribute expansion.
On a side note, does the attribute not emit any #[test]
annotated functions? If it does it should still show runnable lenses for those
@Veykril
What is weird, is that I do have the proc macro trix_test::test
disabled and it does produce an output with #[tokio::test]
annotated function.
trix_test
is a member of my Rust workspace, it reexports the proc macro from trix-test-macros
crate.
And I have the following in my config:
{
"rust-analyzer.procMacro.ignored": {
"async-recursion": ["async_recursion"],
"async-trait": ["async_trait"],
"trix-test-macros": ["test"],
"tracing-attributes": ["instrument"],
}
}
It may not be related, but could it be that proc macro ignoring is broken?
Even though I have tracing-attributes::instrument
disabled according to that config, I see that adding that proc macro influences the code highlighting and not in a good way:
When I comment it out, highlighting works normally...
It still influencing highlighting here is kind off expected, what the ignore option does is merely replacing the expander with an identity proc-macro which means we still lover doc comments to their attribute form causing us to lose highlighting there nevertheless(though losing highlighting here is obviously a bug). Not sure why the self
token loses its semantic information though, so thats also a bug.
So turns out this is also the reason why ignoring a proc-macro will lose the test runnables heuristic, since we still expand it into the function itself again so we probably need to walk up the attribute expansions if there are no runnable annotations yet and check if one of the expanding attributes matches the heuristic. Or try changing how the ignore
options works after all(replacing the expander with a dummy was a very simple way to achieve it).
It still seems odd that we can't figure out the text functions in your expanded attribute though unless it does work and you just usually have it ignored.
I am also seeing the behavior reported in https://github.com/rust-lang/rust-analyzer/issues/14197 but #[tokio::test]
itself isn't getting the Debug Test codelens.
The only test that gets a lens on my machine is a #[test]
one
VSCode Version: 1.79.2 (Universal) rust-analyzer version: 0.3.1566-standalone (4a2ceeff0 2023-06-25)
https://rust-analyzer.github.io/thisweek/2023/07/03/changelog-188.html suggests that at least my issue might be recently fixed:
And it is:
It seems like the underscore breaks it.
longnamefoobar::test
works, but longname_foobar::test
doesn't.
In Rustup we use rustup_macros::integration_test
and I'm pretty sure we're not getting the lens either:
/// Custom wrapper macro around `#[test]` and `#[tokio::test]`.
///
/// Calls `rustup::test::before_test()` before the test body, and
/// `rustup::test::after_test()` after, even in the event of an unwinding panic.
/// For async functions calls the async variants of these functions.
#[proc_macro_attribute]
pub fn integration_test(
args: proc_macro::TokenStream,
input: proc_macro::TokenStream,
) -> proc_macro::TokenStream { ... }
I'm not quite sure whether it's related to @ChristianBeilschmidt's observation in https://github.com/rust-lang/rust-analyzer/issues/11396#issuecomment-1684035633 though.
https://github.com/rust-lang/rust-analyzer/issues/15166 would be absolutely nice in the long run if it's feasible.
This regression has been there for quite some time, but I decided to report it only today, sorry... I remember that at some point this worked and rust-analyzer showed codelens on top of a proc macro attribute that contains
test
in its signature.E.g. the following code showed this codelens:
just like it shows it when I switch the proc macro to
tokio::test
I even remember reviewing a PR that initially added a heuristic that searches for a substring "test" in the proc macro name to gate the addition of that codelens, but that was a long time ago and I assume this heuristic either gone broken or was changed [un]intentionally.
I suggest we fix this and return that codelens back.
Meta
rust-analyzer version:
rustc version: