rust-lang / rust-analyzer

A Rust compiler front-end for IDEs
https://rust-analyzer.github.io/
Apache License 2.0
14.18k stars 1.58k forks source link

Custom proc macro for test functions no longer provide "Run Test" codelens #11396

Open Veetaha opened 2 years ago

Veetaha commented 2 years ago

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:

image

just like it shows it when I switch the proc macro to tokio::test

image

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:

rust-analyzer version: 34138379b 2022-02-02 nightly

rustc version:

$ rustc --version --verbose
rustc 1.58.0 (02072b482 2022-01-11)
binary: rustc
commit-hash: 02072b482a8b5357f7fb5e5637444ae30e423c40
commit-date: 2022-01-11
host: x86_64-unknown-linux-gnu
release: 1.58.0
LLVM version: 13.0.0
Veykril commented 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

Veetaha commented 2 years ago

@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:

image

When I comment it out, highlighting works normally...

image
Veykril commented 2 years ago

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.

chamons commented 1 year ago

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)

chamons commented 1 year ago

https://rust-analyzer.github.io/thisweek/2023/07/03/changelog-188.html suggests that at least my issue might be recently fixed:

image

And it is:

image

ChristianBeilschmidt commented 1 year ago

It seems like the underscore breaks it.

longnamefoobar::test works, but longname_foobar::test doesn't.

rami3l commented 6 months ago

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 { ... }

https://github.com/rust-lang/rustup/blob/0c501d55c54031a992395078d535b6d2574dc693/rustup-macros/src/lib.rs#L7-L40

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.