rust/tests/ui/proc-macro/attr-on-trait.rs

//@ run-pass
//@ aux-build:attr-on-trait.rs

extern crate attr_on_trait;

use attr_on_trait::foo;

trait Foo {
    #[foo]
    fn foo() {}
}

impl Foo for i32 {
    fn foo(&self) {}
}

fn main() {
    3i32.foo();
}
[AUTO-GENERATED] Migrate ui tests from `//` to `//@` directives 2024-02-16 20:02:50 +00:00			`//@ run-pass`
			`//@ aux-build:attr-on-trait.rs`
rustc: Fix proc_macro expansions on trait methods This commit fixes procedural macro attributes being attached to trait methods, ensuring that they get resolved and expanded as other procedural macro attributes. The bug here was that `current_module` on the resolver was accidentally set to be a trait when it's otherwise only ever expecting a `mod`/block module. The actual fix here came from @jseyfried, I'm just helping to land it in the compiler! Closes #42493 2017-08-25 20:33:15 +00:00
			`extern crate attr_on_trait;`

rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros, custom derives, with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature, such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR, once landed, will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252 2018-07-03 22:36:31 +00:00			`use attr_on_trait::foo;`

rustc: Fix proc_macro expansions on trait methods This commit fixes procedural macro attributes being attached to trait methods, ensuring that they get resolved and expanded as other procedural macro attributes. The bug here was that `current_module` on the resolver was accidentally set to be a trait when it's otherwise only ever expecting a `mod`/block module. The actual fix here came from @jseyfried, I'm just helping to land it in the compiler! Closes #42493 2017-08-25 20:33:15 +00:00			`trait Foo {`
rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros, custom derives, with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature, such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR, once landed, will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252 2018-07-03 22:36:31 +00:00			`#[foo]`
rustc: Fix proc_macro expansions on trait methods This commit fixes procedural macro attributes being attached to trait methods, ensuring that they get resolved and expanded as other procedural macro attributes. The bug here was that `current_module` on the resolver was accidentally set to be a trait when it's otherwise only ever expecting a `mod`/block module. The actual fix here came from @jseyfried, I'm just helping to land it in the compiler! Closes #42493 2017-08-25 20:33:15 +00:00			`fn foo() {}`
			`}`

			`impl Foo for i32 {`
			`fn foo(&self) {}`
			`}`

			`fn main() {`
			`3i32.foo();`
			`}`