Declarative macros: no error about duplicate trait items

[RalfJung]

I tried this code on the latest nightly:

#![feature(decl_macro)]

trait Trait {
    type T;
}

macro trait_impl {
    () => {
        type T = ();
    }
}

impl Trait for i32 {
    trait_impl!();
    type T = ();
}

I expected to see this happen: an error about type T being defined twice in the same impl. (This is what happens with macro_rules! trait_impl.)

Instead, this happened: the code just compiles. The same also works when considering a function rather than a type.

[jonas-schievink]

They're seperate items because of hygiene though, right?

[petrochenkov]

They're seperate items because of hygiene though, right?

Exactly.

This is still a bug though, because the trait has a single item, but the impl has two.

[RalfJung]

The names both still "work" for the instance though (in the sense that having one is enough to satisfy the check that the impl covers each item of the trait).

When both are present, it silently uses one of them, and I do not know which...

[cjgillot]

What should be the correct diagnostic here?
I see two possible:

1. report the macro output as not being in the trait;
2. report the a conflict between the two names in the impl.

[RalfJung]

The following code should work fine I think:

#![feature(decl_macro)]

trait Trait {
    type T;
}

macro trait_impl {
    () => {
        type T = ();
    }
}

impl Trait for i32 {
    trait_impl!();
}

I believe that means only the 2nd error makes sense?

[cjgillot]

What about without the trait: should we err? That would be inconsistent with plain items.

#![feature(decl_macro)]

macro trait_impl {
    () => {
        fn foo() {}
    }
}

struct Type;

impl Type {
    trait_impl!();
    fn foo() {}
}

[RalfJung]

What do you mean? This errors after "inlining" the macro, right?

[cjgillot]

trait_impl!();
fn foo() {}

does not error. This is by design, the main difference with macro_rules.

Hence the question: should inherent impls follow the "plain function" behaviour, or the trait impl behaviour?

[RalfJung]

Ah, so functions inside trait_impl can call the foo declared inside but are 'isolated' from the outside? That makes sense in terms of hygiene, I guess.

It would be nice to be able to have macros partially implement a trait though. (We do that in rustc's const-eval.) Conceptually I feel like the names there really refer to the trait, they are not newly declared names but 'resolve' to existing names. Arguably inside the macro it doesn't know which trait to resolve them to so a strict hygiene would entirely forbid this, but also then there'd be no way to around around this, right?