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

deprecated proc_macro trigger warning on build library #65189

Closed
la10736 opened this issue Oct 7, 2019 · 3 comments · Fixed by #65666
Closed

deprecated proc_macro trigger warning on build library #65189

la10736 opened this issue Oct 7, 2019 · 3 comments · Fixed by #65666
Assignees
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-bug Category: This is a bug. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@la10736
Copy link
Contributor

la10736 commented Oct 7, 2019

Use deprecated attribute on a procedural macro function doesn't work like expected: it triggers a warning message also when library is building and not just in call place.

I know that the deprecate attribute support is not landed in stable but this warning is present in all channels (stable, beta and nightly).

  stable-x86_64-unknown-linux-gnu unchanged - rustc 1.38.0 (625451e37 2019-09-23)
    beta-x86_64-unknown-linux-gnu unchanged - rustc 1.39.0-beta.5 (fa5c2f3e5 2019-10-02)
   nightly-x86_64-unknown-linux-gnu updated - rustc 1.40.0-nightly (421bd77f4 2019-10-06)

Compiling lib simple by cargo +beta build raise follow warning:

   Compiling deprecete_proc_macro v0.1.0 (/home/michele/temp/ppp/deprecete_proc_macro)
warning: use of deprecated item 'deprecable_fn'
 --> src/lib.rs:6:1
  |
6 | pub fn deprecable_fn(input: proc_macro::TokenStream) -> proc_macro::TokenStream { input }
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(deprecated)]` on by default

warning: use of deprecated item 'deprecable_derive'
  --> src/lib.rs:10:1
   |
10 | pub fn deprecable_derive(input: proc_macro::TokenStream) -> proc_macro::TokenStream { input }
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

warning: use of deprecated item 'deprecable_attr'
  --> src/lib.rs:14:1
   |
14 | pub fn deprecable_attr(_args: proc_macro::TokenStream, input: proc_macro::TokenStream) -> proc_macro::TokenStream { input }
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    Finished dev [unoptimized + debuginfo] target(s) in 0.70s

Sadly this issue make deprecated attribute not usable at all for procedural macro.

Follow the code to reproduce this issue:

Cargo.toml

[package]
name = "deprecete_proc_macro"
version = "0.1.0"
authors = ["me <[email protected]>"]
edition = "2018"

[lib]
proc_macro=true

src/lib.rs

extern crate proc_macro;

#[deprecated]
#[proc_macro]
pub fn deprecable_fn(input: proc_macro::TokenStream) -> proc_macro::TokenStream { input }

#[deprecated]
#[proc_macro_derive(Deprecable)]
pub fn deprecable_derive(input: proc_macro::TokenStream) -> proc_macro::TokenStream { input }

#[deprecated]
#[proc_macro_attribute]
pub fn deprecable_attr(_args: proc_macro::TokenStream, input: proc_macro::TokenStream) -> proc_macro::TokenStream { input }

This issue has been assigned to @XiangQingW via this comment.

@petrochenkov
Copy link
Contributor

The most likely reason is that deprecable_fn and friends are used from the proc macro harness automatically generated for proc macro crates.

So either

  • the harness should generate #[allow(deprecated)] (there are precedents for this, e.g. test harness generates #[allow(dead_code)]), or
  • deprecated should not be reported from "externally generated code", which usually includes macros from other crates, but also code generated by the compiler.

@petrochenkov
Copy link
Contributor

Adding #[allow(deprecated)] should be a very simple fix - the static item referring to the proc macro definition functions is generated in fn mk_decls in libsyntax_ext/proc_macro_harness.rs.

@jonas-schievink jonas-schievink added A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 7, 2019
@petrochenkov petrochenkov added E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. labels Oct 7, 2019
@XiangQingW
Copy link
Contributor

@rustbot claim

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-bug Category: This is a bug. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
5 participants