-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 11 pull requests #65072
Rollup of 11 pull requests #65072
Conversation
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com> Co-Authored-By: Ralf Jung <post@ralfj.de>
Some comment refinements inspired by review feedback.
Update: review feedback Update: placate tidy
…elf` (Without this commit, you still get an error (a very similar one, at that), but it complains about use of forward declaration, which is confusing since people do not necessarily think of `Self` as being declared at all.) Update: incorporate review feedback.
Update: incorporate review feedback.
…oats Stabilize todo macro The `todo!` macro is just another name for `unimplemented!`. Tracking issue: rust-lang#59277 This PR needs a FCP to merge. r? @withoutboats
Deprecate `#![plugin]` & `#[plugin_registrar]` This PR deprecates `#![plugin]` and `#[plugin_registrar]`. ~A removal deadline is set: 1.44.0. This will be in 9 months from now and should give everyone who is still relying on the feature ample time to rid themselves of this dependency.~ cc rust-lang#29597 r? @Mark-Simulacrum
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
… r=centril add regression test for rust-lang#60218 Fixes rust-lang#60218
…ure-doctests, r=QuietMisdreavus Prevent rustdoc feature doctests Part of rust-lang#61351 cc @ollie27
…pe-param-default, r=alexreg Disallow Self in type param defaults of ADTs Fix rust-lang#61631 (also includes a drive-by fix to a typo in some related diagnostic output.)
Replace mentions of IRC with Discord Revival of rust-lang#61531 closes rust-lang#61524 what was the outcome of this? rust-lang#61531 (comment) should this be changed in this PR as well? rust-lang#61531 (comment)
…arking-rust-abi-unwind-issue-64655, r=alexcrichton Always mark rust and rust-call abi's as unwind PR rust-lang#63909 identified a bug that had been injected by PR rust-lang#55982. As discussed on rust-lang#64655 (comment) , we started marking extern items as nounwind, *even* extern items that said they were using "Rust" or "rust-call" ABI. This is a more targeted variant of PR rust-lang#63909 that fixes the above bug. Fix rust-lang#64655 ---- I personally suspect we will want PR rust-lang#63909 to land in the long-term But: * it is not certain that PR rust-lang#63909 *will* land, * more importantly, PR rust-lang#63909 almost certainly will not be backported to beta/stable. The identified bug was more severe than I think anyone realized (apart from perhaps @gnzlbg, as noted [here](rust-lang#63909 (comment))). Thus, I was motivated to write this PR, which fixes *just* the issue with extern rust/rust-call functions, and deliberately avoids injecting further deviation from current behavior (you can see further notes on this in the comments of the code added here).
…-E0556, r=petrochenkov Add long error explanation for E0556 Part of rust-lang#61137
…s, r=oli-obk Make visit projection iterative r? @oli-obk /cc @nikomatsakis
typo: fix typo in E0392 See rust-lang#64931. --- Cc: @Centril @estebank
@bors r+ p=11 rollup=never |
📌 Commit a705d43 has been approved by |
⌛ Testing commit a705d43 with merge 089418e178608341a187bdfa3437e14ec4e7d995... |
💔 Test failed - checks-azure |
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 |
Successful merges:
#![plugin]
&#[plugin_registrar]
#64675 (Deprecate#![plugin]
&#[plugin_registrar]
)macro_rules
hygiene #64690 (proc_macro API: Exposemacro_rules
hygiene)Failed merges:
r? @ghost