Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Swap to Proc Macro Error 2 RUSTSEC-2024-0370 #350
Swap to Proc Macro Error 2 RUSTSEC-2024-0370 #350
Changes from 4 commits
c8b5f54
489e0df
58cfbab
ec3c48b
26d28c0
f32150b
27a37de
36970c2
ba4e374
e7668f2
342bf45
c2402e9
77bc98e
030cf45
60e7d51
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can the name be more clear somehow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nightly_features?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure, I don't even know what this does in proc-macro-error2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the nightly feature in proc-macro-error2 its just a different implementation for emitting diagnostics and aborting. The main difference between the two appear to be that warnings are emitted in nightly while ignored in non-nightly builds. Tagging @HigherOrderLogic since they requested this.
I also think its fine if the feature isn't included since Validator might not want to use these extra warnings anyway. Might be a good idea to move this to a different PR for another discussion.
If you want to look at the code its here: https://github.com/GnomedDev/proc-macro-error-2/tree/master/src/imp
The delegate.rs is the nightly version and fallback.rs is the non nightly version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's as @pvichivanives said, this feature enables emitting warning when using nightly compiler, otherwise ignored.
So to match the function, I think this feature can be renamed to
nightly-warnning
, ornightly-proc-macro
, or even the longernightly-proc-macro-error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've written this in #351, but I'd like to point it out here too:
proc-macro-error2
fundamentally does not do the same thing asproc-macro-error
, which is to avoid the need to have the user switch on a separate crate feature to get better proc macro diagnostics on nightly. The entire point ofproc-macro-error
is that both sets of error reporting functionality (viacompiler_error!
or via the nightly proc macro diagnostics API) are available to proc macro authors already, but instead of the library author having to decide (or add a feature), whether the nightly APIs can be used is detected at build time viabuild.rs
. Usingproc-macro-error2
still provides a shim around#[cfg(nightly_macro_diagnostics)]
so there's a single API for the macro code no matter the compiler version, but doesn't do the auto-detection.If this is fine for you @Keats, then this might not be a concern for this PR, but you should make sure that this is actually what you want. In particular, I've linked a different crate in the issue above (
proc-macro2-diagnostics
) that's a similar kind of drop-in replacement but which does do the build-time compiler detection. To me, this would definitely be preferable because IMO the point of usingproc-macro-error
is to automatically give good error messages where possible. At minimum, if you decide to go forwards with this PR andproc-macro-error2
, the feature should receive some documentation in the crate docs. Otherwise, no one's gonna know what it does or turn it on, because most even nitghtly users will probably not know what aproc-macro-error2
is or what it does and that they could be getting much better error messages (which again is why I think it would be better if they didn't have to know at all).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly I don't really care which version gets used. The least disturbance the better though. If someone took proc-macro-error and just bumped syn without any other changes it would be fine. But I agree that needing a feature for some nightly stuff is not great
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy to swap over the pr/close this pr if you would want to make one @domenicquirl. Am slightly concerned though that
proc-macro2-diagnostics
has 1 commit in the last 12 months, being a version bump which hasn't been released yet (last release was around 1year ago). Also SergioBenitez/version_check#23 <- for this as a rust team dev pointed out they would prefer people didn't automatically detect nightly.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't be too worried about that, Sergio has been active in the issues over there as recent as a month ago. It's just a small crate that doesn't need lots of updating.
Aside from that, point taken on nightly detection in general. It's maybe worth pointing out that there's also a PR to
proc-macro2-diagnostics
that tries to put their nightly detection (the detection itself, not the usage of the nightly APIs) behind a feature flag.Personally, I don't use
validator
in a nightly context, which means I don't get nice diagnostics either way, so I probably won't push for a specific alternative solution as long as thesyn
version gets bumped with the switch. Just wanted to make sure that the change in behaviour is known, and as I said above I think you should add a section to the top-level crate docs that explains that this feature exists and what it does. Otherwise I'm pretty sure most people will miss it or see it and have a hard time figuring out what it does.