Run Doctest inside trait implementations in modules fails for some types

[kangalio]

When you have a trait implementation for a type inside a module (i.e. not crate root), for some types the Run Doctest lens at the top of doctests for trait methods fails to run any test.

It seems that affected types are primitive types (str, u32, char...) and types with non-alphanumerical characters in them (&T, (T, T), [T; N]...).

Curiously enough, the issue only seems to encounter within modules; when the trait implementation is moved to the crate root, Run Doctest does its job just fine regardless of the type used (as far as I could tell).

Example:

mod hi {
    pub trait Trait {
        fn foo();
    }
    
    impl Trait for char {
        /// ```rust
        /// assert_eq!(1 + 1, 2);
        /// ```
        fn foo() {}
    }
}

The issue seems to be that the type name is, for some reason, dropped from the path passed to --package.

[Veykril]

Yep, we are only handling adt's here currently https://github.com/rust-analyzer/rust-analyzer/blob/904bdff2241a54c6aebe0f6fd39e6560550a66b0/crates/ide/src/runnables.rs#L302

[darrow-olykos]

@Veykril

Just ran into this bug as well, would you be able to leave any sort of mental breadcrumbs for me if I wanted to take a stab at resolving? https://github.com/rust-analyzer/rust-analyzer/blob/master/crates/ide/src/runnables.rs#L391

What do I need to understand about this function and this adt type to start to try to fix?

[Veykril]

ADT = Abstract-Data Type, meaning struct, enum and union types.

What we need at that location is the name of the type so that we can emit it for the runnable command, hence why we check if the type is an ADT, since then we can fetch the name of it.
This fails for primitive types since those are not ADTs, so we need an extra if branch here that checks for whether the type is a primitive type. I think there should be a similar function defined like the as_adt for these. Then we just need to fetch the name of the primitive there.

[darrow-olykos]

@Veykril Hm, I think I see.
I could add a local helper fn like this:

fn get_name(type: Type) -> Option<Name> {
    if let Some(adt) = ty.as_adt() {
        adt.name(db)
    } else if let Some(builtin) = ty.as_builtin() {
        builtin.name()
    }
    else {
        None
    }
}

And I could update this function to look like:

    let name = ty.get_name()?;

In place of
if let Some(adt) = ty.as_adt() {

Do you think this helper function belongs better in the Type within hir crate instead?

[Veykril]

I don't think a helper function is useful right now. Most code will probably have to handle special cases anyways if similar functionality is required.

[darrow-olykos]

Mkay, I could do something like

                let maybe_name = match ty.as_adt() {
                    Some(adt) => Some(adt.name(db)),
                    None => match ty.as_builtin() {
                        Some(builtin) => Some(builtin.name()),
                        None => None,
                    },
                };
                
                if let Some(name) = maybe_name {
                     // ...
              

Question, why do I see adt.name(db) taking in db if the HasName trait's name method only has &self?
Just kidding. Updating rust fixed vscode intellisense/code navigation, i see the correct hir::Adt method where name's arg is a HirDatabase :)

(Cloned the repo for the first time-- Seemed to be getting errors when trying to run cargo test before modifying anything, I'm going to read your contributing docs now)

Edit: Upgraded to rust 1.59.0, cargo test is OK now.

[darrow-olykos]

Are there any docs in this repo that explain how to open a vscode project that uses a local rust-analyzer repo rather than an officially installed rust-analyzer extension? @Veykril

[Veykril]

running cargo xtask install --server in the rust-analyzer workspace will build and install the rust-analyzer server into your cargo binaries, which if they are in your PATH can be then executed in VSCode by setting the rust-analyzer.server.path configuration to rust-analyzer.

[darrow-olykos]

Ok so if I do the following:

1. run cargo xtask install --server in my rust-analyzer workspace
2. add "analyzer.server.path": "rust-analyzer"
3. ensure cargo binaries are in PATH

Then will any workspace I open up with vscode be using my local rust-analyzer instead of official extension? (Tried this, and it appears not?)

Do I need to use "Run Extension (Debug build)" after the above 1-3?
(Tried this before doing Step 1 and 2, and, although it SEEMS like a new window is opened (Extension Development Host) where it (might be) using my local rust-analyzer, I can't seem to trigger any breakpoints or see any println! output so not positive that's actually running the extension from local rust-analyzer repo either.

Trying "Run Extension (Debug build)" again now that I did step 1, 2, and 3

@Veykril

[Veykril]

Just with your 3 steps running a new VSCode instance should run the self-build server. Running the debug steps shouldnt be necessary. Though using one of the debug server tasks should also work(without the need of the steps I described before, that was just my workflow for these).

[Veykril]

Otherwise the only relevant doc I can point you to is https://github.com/rust-analyzer/rust-analyzer/tree/master/docs/dev#launching-rust-analyzer