Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tool_attributes feature stops working when rust_2018_preview feature is enabled #51277

Closed
flip1995 opened this issue Jun 1, 2018 · 8 comments · Fixed by #52841
Closed

tool_attributes feature stops working when rust_2018_preview feature is enabled #51277

flip1995 opened this issue Jun 1, 2018 · 8 comments · Fixed by #52841
Assignees

Comments

@flip1995
Copy link
Member

flip1995 commented Jun 1, 2018

If both features tool_attributes and rust_2018_preview are enabled, scoped attributes lead to the error message

error[E0658]: paths of length greater than one in macro invocations are currently unstable (see issue #38356)
 --> src/main.rs:4:3
  |
4 | #[rustfmt::skip]
  |   ^^^^^^^^^^^^^
  |
  = help: add #![feature(proc_macro_path_invoc)] to the crate attributes to enable

I think this can be fixed by doing this #47773 (review) right. I would like to try and fix this, but I need some pointers where to start.

This needs to be fixed, so clippy can use the new scoped attributes instead of the old cfg_attrs (rust-lang/rust-clippy#2823).

I tried this code:

#![feature(tool_attributes)]
#![feature(rust_2018_preview)]

#[rustfmt::skip]
fn main() {
    //code not to format
}

Playground
This should compile without errors, but gives the error above

Meta

rustc 1.28.0-nightly (5d0631a64 2018-05-30)
binary: rustc
commit-hash: 5d0631a6438cf30cac236b7176371663e35c8d07
commit-date: 2018-05-30
host: x86_64-unknown-linux-gnu
release: 1.28.0-nightly
LLVM version: 6.0
@oli-obk
Copy link
Contributor

oli-obk commented Jun 1, 2018

cc @petrochenkov

@mati865
Copy link
Contributor

mati865 commented Jun 6, 2018

For what it's worth tool attributes work within the crate so one can use #[clippy::whatever] but external attributes like #[rustfmt::skip] trigger the error.

@nrc
Copy link
Member

nrc commented Jul 2, 2018

I would like to try and fix this, but I need some pointers where to start.

@petrochenkov are you able to provide some mentoring instructions here please?

@nrc
Copy link
Member

nrc commented Jul 17, 2018

ping @petrochenkov are you likely to be able to look at this or provide mentoring instructions? Sorry, I know you have a lot on your plate right now, but this is a blocker bug for Rustfmt

@petrochenkov
Copy link
Contributor

@nrc
Yes, this weekend.
This is at the top of my work queue right now.

@nrc
Copy link
Member

nrc commented Jul 17, 2018

Thanks @petrochenkov !

@petrochenkov
Copy link
Contributor

I wasn't able to finish this during the weekend, but it's still mostly done, I'll open a PR soon.

@petrochenkov
Copy link
Contributor

Fixed in #52841

Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Aug 1, 2018
resolve: Implement prelude search for macro paths, implement tool attributes

When identifier is macro path is resolved in scopes (i.e. the first path segment - `foo` in `foo::mac!()` or `foo!()`), scopes are searched in the same order as for non-macro paths - items in modules, extern prelude, tool prelude (see later), standard library prelude, language prelude, but with some extra shadowing restrictions (names from globs and macro expansions cannot shadow names from outer scopes). See the comment in `fn resolve_lexical_macro_path_segment` for more details.

"Tool prelude" currently contains two "tool modules" `rustfmt` and `clippy`, and is searched immediately after extern prelude.
This makes the [possible long-term solution](https://github.com/rust-lang/rfcs/blob/master/text/2103-tool-attributes.md#long-term-solution) for tool attributes exactly equivalent to the existing extern prelude scheme, except that `--extern=my_crate` making crate names available in scope is replaced with something like `--tool=my_tool` making tool names available in scope.

The `tool_attributes` feature is still unstable and `#![feature(tool_attributes)]` now implicitly enables `#![feature(use_extern_macros)]`. `use_extern_macros` is a prerequisite for `tool_attributes`, so their stabilization will happen in the same order.
If `use_extern_macros` is not enabled, then tool attributes are treated as custom attributes (this is temporary, anyway).

Fixes rust-lang#52576
Fixes rust-lang#52512
Fixes rust-lang#51277
cc rust-lang#52269
bors added a commit that referenced this issue Aug 2, 2018
resolve: Implement prelude search for macro paths, implement tool attributes

When identifier is macro path is resolved in scopes (i.e. the first path segment - `foo` in `foo::mac!()` or `foo!()`), scopes are searched in the same order as for non-macro paths - items in modules, extern prelude, tool prelude (see later), standard library prelude, language prelude, but with some extra shadowing restrictions (names from globs and macro expansions cannot shadow names from outer scopes). See the comment in `fn resolve_lexical_macro_path_segment` for more details.

"Tool prelude" currently contains two "tool modules" `rustfmt` and `clippy`, and is searched immediately after extern prelude.
This makes the [possible long-term solution](https://github.com/rust-lang/rfcs/blob/master/text/2103-tool-attributes.md#long-term-solution) for tool attributes exactly equivalent to the existing extern prelude scheme, except that `--extern=my_crate` making crate names available in scope is replaced with something like `--tool=my_tool` making tool names available in scope.

The `tool_attributes` feature is still unstable and `#![feature(tool_attributes)]` now implicitly enables `#![feature(use_extern_macros)]`. `use_extern_macros` is a prerequisite for `tool_attributes`, so their stabilization will happen in the same order.
If `use_extern_macros` is not enabled, then tool attributes are treated as custom attributes (this is temporary, anyway).

Fixes #52576
Fixes #52512
Fixes #51277
cc #52269
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Aug 22, 2018
Stabilize a few secondary macro features

- `tool_attributes` - closes rust-lang#44690
- `proc_macro_path_invoc` - this feature was created due to issues with tool attributes (rust-lang#51277), those issues are now fixed (rust-lang#52841)
- partially `proc_macro_gen` - this feature was created due to issue rust-lang#50504, the issue is now fixed (rust-lang#51952), so proc macros can generate modules. They still can't generate `macro_rules` items though due to unclear hygiene interactions.
bors added a commit that referenced this issue Aug 23, 2018
Stabilize a few secondary macro features

- `tool_attributes` - closes #44690
- `proc_macro_path_invoc` - this feature was created due to issues with tool attributes (#51277), those issues are now fixed (#52841)
- partially `proc_macro_gen` - this feature was created due to issue #50504, the issue is now fixed (#51952), so proc macros can generate modules. They still can't generate `macro_rules` items though due to unclear hygiene interactions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants