-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Don't consider macro-expansions in stability analysis? #15703
Comments
I definitely agree with this approach: we should be able to annotate a macro with a stability level, and that's what should count for its users. Do we have a way of telling what part of an AST was generated via macro expansion by the time we get to linting? |
Mostly; there's the |
Hm, this seems slightly subtle, since the contents of a macro would then never be checked for stability. This differs to a conventional function, e.g. given (Of course, macros and phasing are both feature gated so you have to opt-in to instability to use non-standard macros anyway.) |
@huon Good point. Also, it looks tricky with the current infrastructure to even lint on the macro invocation -- the backtrace of macro expansion does not appear to link to the def_id of the macro (or give any other way of getting at the macro's stability). Nevertheless, I think we should bail out of the lint when we hit the results of expansion; those should be checked, if anywhere, at the site of macro definition. One other question: do syntax extensions also produce the span information you mentioned above? I ask because @brson's original problematic cases are written syntax extensions. If not, is there some other way of telling that an expansion happened? |
@aturon Sounds good to me. Thanks! |
This small patch causes the stability lint to bail out when traversing any AST produced via a macro expansion. Ultimately, we would like to lint the contents of the macro at the place where the macro is defined, but regardless we should not be linting it at the use site. Closes rust-lang#15703
cc #15728 |
This small patch causes the stability lint to bail out when traversing any AST produced via a macro expansion. Ultimately, we would like to lint the contents of the macro at the place where the macro is defined, but regardless we should not be linting it at the use site. Closes #15703
The expansion of
fail!
andprintln!
both currently cause code to fail the stability check because they expand to reveal unstable implementation details. A seemingly reasonable solution to this would be to just not run the analysis on any code that has been macro-expanded.cc @aturon
The text was updated successfully, but these errors were encountered: