confusing error message with concat_idents!() use in type position

[heycam]

I tried to use concat_idents! to construct the name of a type in a macro. I discovered this wasn't possible, but the error message for it doesn't seem right.

cam@zoo /tmp $ cat m.rs
#![feature(concat_idents)]
#![feature(type_macros)]
pub enum YZ { }
macro_rules! test {
    ($x:ident, $y:ident) => (
        pub struct $x {
            pub ptr: *mut concat_idents!($y, Z),
        }
    )
}
test!(X, Y);
cam@zoo /tmp $ multirust run nightly rustc m.rs
m.rs:7:27: 7:40 error: non-expression macro in expression position: concat_idents
m.rs:7             pub ptr: *mut concat_idents!($y, Z),
                                 ^~~~~~~~~~~~~
error: aborting due to previous error
cam@zoo /tmp $ multirust run nightly rustc --version
rustc 1.10.0-nightly (cd6a40017 2016-05-16)

Maybe the "non-expression" and "expression" need to be swapped around?

CC @nrc

[nrc]

The error message comes from here:

rust/src/libsyntax/ext/expand.rs

Line 261 in 44b3cd8

&format!("non-expression macro in expression position: {}",

And seems to be because parse_thunk failed, so I think it's just a generic error message. I guess it used to be accurate but isn't any more?

[jseyfried]

I think this error should be non-type macro in type position: concat_idents to be consistent with other errors like non-pattern macro in pattern position (playpen example).

We could also avoid the error in this case by supporting concat_ident! in type and pattern positions as well as in expression positions. @nrc do you think this would be a good idea?

[nrc]

Presumably the message is accurate some times, so we'd have to check if the problem is with expression position or type position.

I think the problem with concat_idents is that the implementation returns an Expr AST node. It would have to know the context it is being expanded into in order to return a type or an expression or whatever. I don't think that is possible under the current system. I'd rather spend time working towards a nice solution than piling more hacks onto the existing one.

[jseyfried]

Presumably the message is accurate some times, so we'd have to check if the problem is with expression position or type position.

Agreed -- I meant the error in this specific case.