-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Rollup of 5 pull requests #65053
Rollup of 5 pull requests #65053
Conversation
This fixes some test differences and also avoids overflow in issue-38591.rs.
- The attribute is behind a feature gate. - Error if both #[naked] and #[track_caller] are applied to the same function. - Error if #[track_caller] is applied to a non-function item. - Error if ABI is not "rust" - Error if #[track_caller] is applied to a trait function. Error codes and descriptions are pending.
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
proc_macro API: Expose `macro_rules` hygiene Proc macros do not have direct access to our oldest and most stable hygiene kind - `macro_rules` hygiene. To emulate it macro authors have to go through two steps - first generate a temporary `macro_rules` item (using a derive, at least until rust-lang#64035 is merged), then generate a macro call to that item. Popular crates like [proc_macro_hack](https://crates.io/crates/proc-macro-hack) use this trick to generate hygienic identifiers from proc macros. I'd say that these workarounds with nested macro definitions have more chances to hit some corner cases in our hygiene system, in which we don't have full confidence. So, let's provide a direct access to `macro_rules` hygiene instead. This PR does that by adding a new method `Span::mixed_site` (bikeshedding is welcome) in addition to existing `Span::call_site` (stable) and `Span::def_site` (unstable). Identifiers with this span resolve at def-site in for local variables, labels and `$crate`, and resolve at call-site for everything else, i.e. exactly like identifiers produced by `macro_rules`. This API addition opens the way to stabilizing proc macros in expression positions (rust-lang#54727), for which use of call-site hygiene or workarounds with temporary items would be quite unfortunate. (`macro_rules` expanded in expression position, on the other hand, are stable since 1.0 and widely used.) r? @dtolnay @alexcrichton
…atsakis Fix most remaining Polonius test differences This fixes most of the Polonius test differences and also avoids overflow in issue-38591.rs. r? @nikomatsakis
Avoid ICE on ReFree region on where clause Fix rust-lang#64855.
…rn-inference, r=cramertj extract expected return type for async fn generators Fixes rust-lang#60424 cc @Centril, I know you've been eager to see this fixed. r? @cramertj
`#[track_caller]` feature gate (RFC 2091) RFC text: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md Tracking issue: rust-lang#47809 I started with @ayosec's commit to add the feature gate with tests and rebased it onto current master. I fixed up some tidy lints and added a test.
@bors r+ p=5 rollup=never |
📌 Commit 18ce550 has been approved by |
Rollup of 5 pull requests Successful merges: - #64690 (proc_macro API: Expose `macro_rules` hygiene) - #64749 (Fix most remaining Polonius test differences) - #64938 (Avoid ICE on ReFree region on where clause) - #64999 (extract expected return type for async fn generators) - #65037 (`#[track_caller]` feature gate (RFC 2091)) Failed merges: r? @ghost
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
💔 Test failed - checks-azure |
Successful merges:
macro_rules
hygiene #64690 (proc_macro API: Exposemacro_rules
hygiene)#[track_caller]
feature gate (RFC 2091 1/N) #65037 (#[track_caller]
feature gate (RFC 2091))Failed merges:
r? @ghost