2017-12-07 04:30:40 +00:00
|
|
|
// Copyright 2017 The Rust Project Developers. See the COPYRIGHT
|
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
|
|
|
// ignore-pretty pretty-printing is unhygienic
|
|
|
|
|
|
|
|
// aux-build:my_crate.rs
|
|
|
|
// aux-build:unhygienic_example.rs
|
|
|
|
|
rustc: Tweak custom attribute capabilities
This commit starts to lay some groundwork for the stabilization of custom
attribute invocations and general procedural macros. It applies a number of
changes discussed on [internals] as well as a [recent issue][issue], namely:
* The path used to specify a custom attribute must be of length one and cannot
be a global path. This'll help future-proof us against any ambiguities and
give us more time to settle the precise syntax. In the meantime though a bare
identifier can be used and imported to invoke a custom attribute macro. A new
feature gate, `proc_macro_path_invoc`, was added to gate multi-segment paths
and absolute paths.
* The set of items which can be annotated by a custom procedural attribute has
been restricted. Statements, expressions, and modules are disallowed behind
two new feature gates: `proc_macro_expr` and `proc_macro_mod`.
* The input to procedural macro attributes has been restricted and adjusted.
Today an invocation like `#[foo(bar)]` will receive `(bar)` as the input token
stream, but after this PR it will only receive `bar` (the delimiters were
removed). Invocations like `#[foo]` are still allowed and will be invoked in
the same way as `#[foo()]`. This is a **breaking change** for all nightly
users as the syntax coming in to procedural macros will be tweaked slightly.
* Procedural macros (`foo!()` style) can only be expanded to item-like items by
default. A separate feature gate, `proc_macro_non_items`, is required to
expand to items like expressions, statements, etc.
Closes #50038
[internals]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252
[issue]: https://github.com/rust-lang/rust/issues/50038
2018-04-20 14:50:39 +00:00
|
|
|
#![feature(decl_macro, proc_macro_path_invoc)]
|
2017-12-07 04:30:40 +00:00
|
|
|
|
|
|
|
extern crate unhygienic_example;
|
|
|
|
extern crate my_crate; // (b)
|
|
|
|
|
|
|
|
// Hygienic version of `unhygienic_macro`.
|
|
|
|
pub macro hygienic_macro() {
|
|
|
|
fn g() {} // (c)
|
|
|
|
::unhygienic_example::unhygienic_macro!();
|
|
|
|
// ^ Even though we invoke an unhygienic macro, `hygienic_macro` remains hygienic.
|
|
|
|
// In the above expansion:
|
|
|
|
// (1) `my_crate` always resolves to (b) regardless of invocation site.
|
|
|
|
// (2) The defined function `f` is only usable inside this macro definition.
|
|
|
|
// (3) `g` always resolves to (c) regardless of invocation site.
|
|
|
|
// (4) `$crate::g` remains hygienic and continues to resolve to (a).
|
|
|
|
|
|
|
|
f();
|
|
|
|
}
|
|
|
|
|
|
|
|
#[allow(unused)]
|
|
|
|
fn test_hygienic_macro() {
|
|
|
|
hygienic_macro!();
|
|
|
|
|
|
|
|
fn f() {} // (d) no conflict
|
|
|
|
f(); // resolves to (d)
|
|
|
|
}
|
|
|
|
|
|
|
|
fn main() {}
|