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

WIP: Minver guard #5

Closed
wants to merge 3 commits into from
Closed

Conversation

mathstuf
Copy link

@mathstuf mathstuf commented May 9, 2019


Work-in-progress for a sanity check before the fiddly bits of error details and impls, tests, and documentation updates get done.

The new `minver` feature can cause an error if the condition is a
tautology.
This allows crates to declare the minimum supported version in their
code. Further use of `#[rustc]` attributes will then error if a
tautology is discovered.

Missing:

  - [ ] documentation updates
  - [ ] error impls/messages
  - [ ] test cases

Fixes: dtolnay#4
@@ -194,6 +195,11 @@ pub fn all(args: TokenStream, input: TokenStream) -> TokenStream {
cfg("all", args, input)
}

#[proc_macro_attribute]
pub fn minver(args: TokenStream, input: TokenStream) -> TokenStream {
cfg("minver", args, input)
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally, this would be only usable as a global #![attr] at the crate level. Is it possible to restrict that?

pub type ExprResult<T> = std::result::Result<T, ExprError>;

lazy_static! {
static ref MINVER: RwLock<Option<Bound>> = RwLock::new(None);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like you are planning to rely on invocation order and sharing data through a static in the proc macro's process. Be aware that the compiler makes no guarantee about what order macro invocations run in or whether different macro calls all run in the same process, so I don't plan to accept an implementation like this.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought that might be a problem, but documentation seems to be thin. Is there a place to store stateful information like this? I assume so since I'm not sure how/where clippy would store warning state information, but maybe that's a plugin thing and not available to proc macros?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know of an established place to store information across proc macro calls without putting it in the generated code. Clippy is not implemented as a proc macro.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, if it does go into the generated code, how would a proc macro access it anyways? Maybe this isn't possible with a proc macro today?

Copy link
Owner

@dtolnay dtolnay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am closing the PR because it looks like this approach hit a dead end. Thanks anyway! Someone will need to come up with a new strategy that makes it possible to implement this.

@dtolnay dtolnay closed this Jul 7, 2019
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 this pull request may close these issues.

None yet

2 participants