Rewrite `Parser::collect_tokens`
The previous implementation did not work when called on an opening
delimiter, or when called re-entrantly from the same `TokenCursor` stack
depth.
I'm not sure how to test this apart from https://github.com/rust-lang/rust/pull/72287
Remove `macro_defs` map
We now store the `DefId` directly in `ExpnKind::Macro`. This will allow
us to serialize `ExpnData` in PR #72121 without needing to manage a side
table.
Recursively expand `TokenKind::Interpolated` in `probably_equal_for_proc_macro`
Fixes#68430
When comparing the captured and re-parsed `TokenStream` for a `TokenKind::Interpolated`, we currently treat any nested `TokenKind::Interpolated` tokens as unequal. If a `TokenKind::Interpolated` token shows up in the captured `TokenStream` due to a `macro_rules!` expansion, we will throw away the captured `TokenStream`, losing span information.
This PR recursively invokes `nt_to_tokenstream` on nested `TokenKind::Interpolated` tokens, effectively flattening the stream into a sequence of non-interpolated tokens. This allows it to compare equal with the re-parsed stream, allowing us to keep the original captured `TokenStream` (with span information).
This requires all of the `probably_equal_for_proc_macro` methods to be moved from `librustc_ast` to `librustc_parse` so that they can call `nt_to_tokenstream`.
Remove ReScope
`ReScope` is unnecessary now that AST borrowck is gone and we're erasing the results of region inference in function bodies. This removes about as much of the old regionck code as possible without having to enable NLL fully.
cc #68261
r? @nikomatsakis
fix discriminant type in generator transform
The generator transform assumed that the discriminant type is always `isize`, which is not correct, leading to [ICEs in Miri](https://github.com/rust-lang/rust/pull/72419/files#r429543536) when some extra sanity checking got enabled.
r? @jonas-schievink @eddyb
Add missing ASM arena declarations to librustc_middle
Fixes#72386
These types also need to get allocated on the `librustc_middle` arena
when we deserialize MIR.
@Amanieu: If we end up using your approach in https://github.com/rust-lang/rust/pull/72392 instead, feel free to copy the test I added over to your PR.
Unblock font loading in rustdoc.css
rustdoc's font loading defaults to "auto", so browsers may block render.
But rustdoc's case prefers a faster TTI for scrolling, this means the
strictest font-display in use should be "swap". rustdoc's fonts do provide
notable legibility improvements but first-time users will have little trouble
reading without. This means "optional" is preferred.
The one exception is Source Serif Pro: it's a big difference for body text, so
"fallback" is preferred over "optional" to cause a (tiny) block.
This follows up on (but does not resolve) #20962, taking PageSpeed Insight's rec fairly directly. Supporting reading material: https://drafts.csswg.org/css-fonts-4/#font-display-desc
Revert MSYS2 CI workaround
MSYS2 has made workaround for critical packages so older installers like one used by chocolatey can work again.
Fixes https://github.com/rust-lang/rust/issues/72333
Impl Ord for proc_macro::LineColumn
```rust
impl Ord for LineColumn {...}
impl PartialOrd for LineColumn {...}
```
for https://doc.rust-lang.org/nightly/proc_macro/struct.LineColumn.html.
The ordering is the natural one you would get by writing one line after another, where we compare line first, then compare columns within the same line.
Replace obligation construction with deref_steps()
1. Use `probe()` to avoid unwanted binding committing during `deref_steps()`.
2. Fixes#59819 again by using `deref_steps()`, make the code cleaner. And if we want to suggest multiple dereferences (like: `consider dereferencing the borrow: "****a"`) in the future, this change will make it easier to achieve.
Rollup of 7 pull requests
Successful merges:
- #71289 (Allow using `Self::` in doc)
- #72375 (Improve E0599 explanation)
- #72385 (Add some teams to prioritization exclude_labels)
- #72395 (Allow rust-highfive to label issues it creates.)
- #72453 (Add flag to open docs: x.py doc --open)
- #72459 (Add core::future::IntoFuture)
- #72461 (Clean up E0600 explanation)
Failed merges:
r? @ghost
Use `once_cell` crate instead of custom data structure
Internally, we use the [`Once`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/sync/struct.Once.html) type for shared data that is initialized exactly once and only read from afterwards. `Once` uses a `parking_lot::Mutex` when the parallel compiler is enabled and a `RefCell` when it is not. This PR switches to the [`once_cell`](https://crates.io/crates/once_cell) crate, which also uses a `parking_lot::Mutex` for its `sync` version (because we enable the `parking_lot` feature) but has zero overhead for its `unsync` one.
This PR adds `once_cell` to the list of whitelisted dependencies. I think this is acceptable because it is already used in `rustc_driver`, is owned by a well-known community member (cc @matklad), and has a stable release. cc @rust-lang/compiler
`once_cell` has a slightly more minimal API than `Once`, which allows for initialization to be either optimistic (evaluate the initializer and then synchronize) or pessimistic (synchronize and then evaluate the initializer). `once_cell`'s `get_or_init` is always pessimistic. The optimistic version is only used once in the current `master`.
r? @Mark-Simulacrum
Otherwise inserting it to the `Binder` used by `trait_ref` would cause
problems. This is just to be extra carefult: we aren't going to
start recommending that the user start using HKTs anytime soon.
`mk_obligation_for_def_id` is only correct if the trait and self type do
not have any substitutions. Use a different method,
`mk_trait_obligation_with_new_self_ty` that is more clear about what is
happening.
Add core::future::IntoFuture
This patch reintroduces the `core::future::IntoFuture` trait. However unlike earlier PRs this patch does not integrate it into the `async/.await` lowering since that lead to performance regressions. By introducing the trait separately from the integration, the integration PR can be more narrowly scoped, and people can start trying out the `IntoFuture` trait today. Thanks heaps!
cc/ @rust-lang/wg-async-foundations
## References
- Original PR adding `IntoFuture` https://github.com/rust-lang/rust/pull/65244
- Open issue to re-land `IntoFuture` (assigned to me) https://github.com/rust-lang/rust/issues/67982
- Tracking issue for `IntoFuture` https://github.com/rust-lang/rust/issues/67644
Esteban Küber