Cannot call static methods on type aliases, "module wasn't actually a module!"

[bstrie]

Compile this:

pub mod foo {
    pub mod bar {
        pub mod baz {
            struct Qux;

            impl Qux {
                pub fn new() {}
            }
        }
    }
}

fn main() {
    type Ham = foo::bar::baz::Qux;
    let Foo = foo::bar::baz::Qux::new();  // works fine
    let Bar = Ham::new();  // oops!
}

$ rustc ty.rs
!!! (resolving module in lexical scope) module wasn't actually a module!
ty.rs:16:14: 16:22 error: unresolved name
ty.rs:16     let Bar = Ham::new();
                       ^~~~~~~~
ty.rs:16:14: 16:22 error: use of undeclared module `Ham`
ty.rs:16     let Bar = Ham::new();
                       ^~~~~~~~
!!! (resolving module in lexical scope) module wasn't actually a module!
ty.rs:16:14: 16:22 error: unresolved name `Ham::new`.
ty.rs:16     let Bar = Ham::new();
                       ^~~~~~~~
error: aborting due to 3 previous errors
task 'rustc' failed at 'explicit failure', /root/catacombs/scrap/rust/src/libsyntax/diagnostic.rs:102
task '<main>' failed at 'explicit failure', /root/catacombs/scrap/rust/src/librustc/lib.rs:392

I can't imagine that this is intentional, as it greatly limits the utility of type aliases.

[emberian]

cc @pcwalton @alexcrichton

[jdm]

#4508 seems related.

[alexcrichton]

The problem here is calling a static method through a typedef. The error messages getting printed is another unrelated bug (but easy to fix). To the best of my knowledge, this has never worked, and I was under the impression that was intentional.

@pcwalton, is it intended to be able to call methods through a typedef?

[nmsmith]

I've noticed this issue as well. It's definitely inconvenient that this doesn't work. Also, it took me a while to realise the error message was complete rubbish.

[nmsmith]

Exhibit A:

use std::sync::mpmc_bounded_queue;

mod work;

void main() {
    let work_queue = mpmc_bounded_queue::Queue::<work::Work>::with_capacity(8);
}

This badly needs a typedef - Queue is not descriptive enough, but mpmc_bounded_queue::Queue is far too verbose!

[zslayton]

cc me

[huonw]

This now prints sane error messages:

11047.rs:16:15: 16:23 error: unresolved name
11047.rs:16     let Bar = Ham::new();  // oops!
                          ^~~~~~~~
11047.rs:16:15: 16:23 error: use of undeclared module `Ham`
11047.rs:16     let Bar = Ham::new();  // oops!
                          ^~~~~~~~
11047.rs:16:15: 16:23 error: unresolved name `Ham::new`.
11047.rs:16     let Bar = Ham::new();  // oops!
                          ^~~~~~~~
error: aborting due to 3 previous errors

[matthieu-m]

I accidentally triggered this and indeed the diagnosis is better.

Unfortunately, it also means that aliases are second-class citizens and seriously hampers their usefulness...

[ben0x539]

@huonw That doesn't really seem like a reasonable error message to me. Coming from other languages where there's something like functions in a type, that types sort of incidentally also create a module of the same name into which subsequent impls then inject methods is pretty unintuitive, that in contrast type aliases then don't do that, even more so.

(Also surprised that #3884 wasn't linked in here yet.)

[huonw]

@ben0x539 I meant to say saner error messages, since it no longer has the "lexical" error junk.

[gavinb]

I keep bumping into #19130 and this issue, and keep referring to the docs assuming it's a mistake.

It would seem that one of the most common reasons to use a type alias would be for generics, however due to this issue, the type feature is of rather limited use.

The official docs on type alias only show an example of a tuple type alias, and no mention is made of traits or generic types. The Rust by Example docs on type alias only alias ordinal types, but it does mention aliasing generic types in passing at the end.

It seems very natural to want to write:

type StringVec = Vec<String>;
// ...
let mut sv = StringVec::new();

but you get the rather ambiguous error:

error: failed to resolve. Use of undeclared type or module `StringVec`

when the type declaration is right there, and then have to write this instead, which rather defeats the purpose:

type StringVec = Vec<String>;
// ...
let mut sv: StringVec = Vec::new();

Anyway, I guess this is a big +1 for this issue.

[vadimcn]

@pcwalton, @alexcrichton, @pnkfelix : Was this bug ever triaged? I think this should be considered for 1.0 nomination.

[alexcrichton]

I'll renominate to make sure we see this. My personal recommendation though is that if the only bug is generating more errors than we should then this isn't a 1.0 issue.

[pnkfelix]

This is a nice-to-have, not a 1.0 blocker. Marking as P-high.

[LukasKalbertodt]

I would agree that type aliases are pretty useless when you can't use them as first class types. If I can do Foo::stuff() I want to be able to do type Bar = Foo; Bar::stuff().
I think it's important.

[matthieu-m]

@LukasKalbertodt I believe we all agree on this; however 1.0 does not mean "finished" but "backward compatible" and calling static methods on type aliases is not necessary for backward compatibility since all programs without will continue to compile once it is implemented (the converse would not be true). Therefore, while I personally value this improvement, I understand that it is not necessary for 1.0.

[arielb1]

This seems to work on 1.3+.

[gavinb]

Verified this works on 1.3. I created a test for this issue. https://github.com/rust-lang/rust/pull/28703/files