proc_macro/bridge: use the cross-thread executor for nested proc-macros
While working on some other changes in the bridge, I noticed that when
running a nested proc-macro (which is currently only possible using
the unstable `TokenStream::expand_expr`), any symbols held by the
proc-macro client would be invalidated, as the same thread would be used
for the nested macro by default, and the interner doesn't handle nested
use.
After discussing with `@eddyb,` we decided the best approach might be to
force the use of the cross-thread executor for nested invocations, as it
will never re-use thread-local storage, avoiding the issue. This
shouldn't impact performance, as expand_expr is still unstable, and
infrequently used.
This was chosen rather than making the client symbol interner handle
nested invocations, as that would require replacing the internal
interner `Vec` with a `BTreeMap` (as valid symbol id ranges could now be
disjoint), and the symbol interner is known to be fairly perf-sensitive.
This patch adds checks to the execution strategy to use the cross-thread
executor when doing nested invocations. An alternative implementation
strategy could be to track this information in the `ExtCtxt`, however a
thread-local in the `proc_macro` crate was chosen to add an assertion so
that `rust-analyzer` is aware of the issue if it implements
`expand_expr` in the future.
r? `@eddyb`
Make `const_eval_select` a real intrinsic
This fixes issues where `track_caller` functions do not have nice panic
messages anymore when there is a call to the function, and uses the
MIR system to replace the call instead of dispatching via lang items.
Fixes#100696.
While working on some other changes in the bridge, I noticed that when
running a nested proc-macro (which is currently only possible using
the unstable `TokenStream::expand_expr`), any symbols held by the
proc-macro client would be invalidated, as the same thread would be used
for the nested macro by default, and the interner doesn't handle nested
use.
After discussing with @eddyb, we decided the best approach might be to
force the use of the cross-thread executor for nested invocations, as it
will never re-use thread-local storage, avoiding the issue. This
shouldn't impact performance, as expand_expr is still unstable, and
infrequently used.
This was chosen rather than making the client symbol interner handle
nested invocations, as that would require replacing the internal
interner `Vec` with a `BTreeMap` (as valid symbol id ranges could now be
disjoint), and the symbol interner is known to be fairly perf-sensitive.
This patch adds checks to the execution strategy to use the cross-thread
executor when doing nested invocations. An alternative implementation
strategy could be to track this information in the `ExtCtxt`, however a
thread-local in the `proc_macro` crate was chosen to add an assertion so
that `rust-analyzer` is aware of the issue if it implements
`expand_expr` in the future.
r? @eddyb
rustdoc: remove redundant mobile-sized `.source nav:not(.sidebar).sub`
It's redundant because there's already a selector `.source nav.sub` with exactly the same margin-left at [line 796].
[line 796]: 84f0c3f79a/src/librustdoc/html/static/css/rustdoc.css (L796)
This selector was added in 1e98fb1027, along with an identical desktop selector, but that desktop selector was removed in 6a5f8b1aef as part of a larger simplification.
Fix internal doc link
The doc link from `DedupSortedIter` to `BTreeMap::bulk_build_from_sorted_iter` was broken when building internal documentation,
This prevented me from building internal documentation locally:
```
R:\Rust\rust> $env:RUSTDOCFLAGS="--document-private-items"
R:\Rust\rust> x doc library/std --open --stage 0
Building rustbuild
Compiling bootstrap v0.0.0 (R:\Rust\rust\src\bootstrap)
Finished dev [unoptimized] target(s) in 3.15s
Documenting stage0 std (x86_64-pc-windows-msvc)
Documenting core v0.0.0 (R:\Rust\rust\library\core)
Finished release [optimized] target(s) in 36.42s
Checking core v0.0.0 (R:\Rust\rust\library\core)
Checking rustc-std-workspace-core v1.99.0 (R:\Rust\rust\library\rustc-std-workspace-core)
Checking compiler_builtins v0.1.79
Documenting alloc v0.0.0 (R:\Rust\rust\library\alloc)
error: unresolved link to `BTreeMap::bulk_build_from_sorted_iter`
--> library\alloc\src\collections\btree\dedup_sorted_iter.rs:6:15
|
6 | /// Used by [`BTreeMap::bulk_build_from_sorted_iter`].
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no item named `BTreeMap` in scope
|
= note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings`
error: could not document `alloc`
```
safe transmute: use `Assume` struct to provide analysis options
This task was left as a TODO in #92268; resolving it brings [`BikeshedIntrinsicFrom`](https://doc.rust-lang.org/nightly/core/mem/trait.BikeshedIntrinsicFrom.html) more in line with the API defined in [MCP411](https://github.com/rust-lang/compiler-team/issues/411).
**Before:**
```rust
pub unsafe trait BikeshedIntrinsicFrom<
Src,
Context,
const ASSUME_ALIGNMENT: bool,
const ASSUME_LIFETIMES: bool,
const ASSUME_VALIDITY: bool,
const ASSUME_VISIBILITY: bool,
> where
Src: ?Sized,
{}
```
**After:**
```rust
pub unsafe trait BikeshedIntrinsicFrom<Src, Context, const ASSUME: Assume = { Assume::NOTHING }>
where
Src: ?Sized,
{}
```
`Assume::visibility` has also been renamed to `Assume::safety`, as library safety invariants are what's actually being assumed; visibility is just the mechanism by which it is currently checked (and that may change).
r? `@oli-obk`
---
Related:
- https://github.com/rust-lang/compiler-team/issues/411
- https://github.com/rust-lang/rust/issues/99571
It's redundant because there's already a selector `.source nav.sub` with
exactly the same margin-left at line 796.
This selector was added in 1e98fb1027, along
with an identical desktop selector, but that desktop selector was removed in
6a5f8b1aef as part of a larger simplification.
rustdoc: remove `.impl-items { flex-basis }` CSS, not in flex container
Added in 34bd2b845b
For this to actually do anything, [according to MDN] (and Firefox Dev Tools), it must be a "flex item", which only happens if its a direct child of a node with `display: flex` on it. It seems like it could not have worked at the time when this rule was added, because the only items in `rustdoc.css` with `display: flex` active were:
* `#help`
This should not contain anything like this.
* `.impl-items h4, h4.impl, h3.impl`
These are all headers, so they shouldn't contain `.impl-items` either.
* `.content .impl-items .method, .content .impl-items > .type, .impl-items > .associatedconstant`
Associated constants and methods definitely shouldn't contain a list of impl items, and the `.type` class seems to refer to type aliases, which, when shown inside of an impl, only show a link to the aliased type.
[according to MDN]: https://developer.mozilla.org/en-US/docs/Web/CSS/flex-basis
Nowadays, `display: flex` is a lot more prolific, but `.impl-items` still seems to only be used in plain block parents:
* If it's not a trait impl, then it's nested below a `<div>` with an id but no class, added in a5216cf67d. This will be `display: block`, probably. For example, [vec deref]
* Inherent impls also get a `<div>` tag, for example [vec impl], and they are also wrapped by their own non-flexbox `<details>` tag.
* If it's a tait implementation, then it's also nested below a `<details>` container, like [deref cstring].
[vec impl]: https://doc.rust-lang.org/1.63.0/std/vec/struct.Vec.html#impl
[vec deref]: https://doc.rust-lang.org/1.63.0/std/vec/struct.Vec.html#deref-methods-%5BT%5D
[deref cstring]: https://doc.rust-lang.org/1.63.0/std/ops/trait.Deref.html#impl-Deref
Also, this would imply that trait items ought to take up as much space as possible, pushing everything else to the edge of the screen. If this is nested directly below the `.rustdoc` container, which has a row basis, that would be bad.
Added in 34bd2b845b
For this to actually do anything, [according to MDN] (and Firefox Dev Tools),
it must be a "flex item", which only happens if its a direct child of a node
with `display: flex` on it. It seems like it could not have worked at the time
when this rule was added, because the only items in `rustdoc.css` with
`display: flex` active were:
* `#help`
This should not contain anything like this.
* `.impl-items h4, h4.impl, h3.impl`
These are all headers, so they shouldn't contain `.impl-items` either.
* `.content .impl-items .method, .content .impl-items > .type, .impl-items > .associatedconstant`
Associated constants and methods definitely shouldn't contain a list of impl
items, and the `.type` class seems to refer to type aliases, which, when
shown inside of an impl, only show a link to the aliased type.
[according to MDN]: https://developer.mozilla.org/en-US/docs/Web/CSS/flex-basis
Nowadays, `display: flex` is a lot more prolific, but `.impl-items` still
seems to only be used in plain block parents:
* If it's not a trait impl, then it's nested below a `<div>` with an id but no
class, added in a5216cf67d. This will be
`display: block`, probably. For example, [vec deref]
* Inherent impls also get a `<div>` tag, for example [vec impl], and they are
also wrapped by their own non-flexbox `<details>` tag.
* If it's a tait implementation, then it's also nested below a `<details>`
container, like [deref cstring].
[vec impl]: https://doc.rust-lang.org/1.63.0/std/vec/struct.Vec.html#impl
[vec deref]: https://doc.rust-lang.org/1.63.0/std/vec/struct.Vec.html#deref-methods-%5BT%5D
[deref cstring]: https://doc.rust-lang.org/1.63.0/std/ops/trait.Deref.html#impl-Deref
Also, this would imply that trait items ought to take up as much space as
possible, pushing everything else to the edge of the screen. If this is nested
directly below the `.rustdoc` container, which has a row basis, that would
be bad.
ffx component run should provide a collection
In the future,`ffx component run` will not default to the using the `/core/ffx-laboratory` collection. Updated the run commands to include this.
Add warning against unexpected --cfg with --check-cfg
This PR adds a warning when an unexpected `--cfg` is specified but not in the specified list of `--check-cfg`.
This is the follow-up PR I mentioned in https://github.com/rust-lang/rust/pull/99519.
r? `@petrochenkov`
Cleanup css theme
Follow-up of https://github.com/rust-lang/rust/pull/100494.
The change for the border color of the search input in the dark mode was actually a weird case: the search input border was unique, it didn't share the same variable with other items with borders. This weird case being unique to the dark theme, I removed it, hence the modification in the GUI test.
Live demo is [here](https://rustdoc.crud.net/imperio/cleanup-css-theme/std/index.html).
cc `@jsha`
r? `@notriddle`
Fix unsupported syntax in .manifest file
Fuchsia .manifest files do not support a `#` comment syntax. Because of this, if you copy and paste the current example code for this file, and then remove the line you don't need, you still see an error. To make this a bit easier to follow, split this into two code blocks, one for rustc, and one for cargo.
[drop tracking] Use parent expression for scope, not parent node
Previously we were just using the parent node as the scope for a temporary value, but it turns out this is too narrow. For example, in an expression like
Foo {
b: &42,
a: async { 0 }.await,
}
the scope for the &42 was set to the ExprField node for `b: &42`, when we actually want to use the Foo struct expression.
We fix this by recursively searching through parent nodes until we find a Node::Expr. It may be that we don't find one, and if so that's okay, we will just fall back on the enclosing temporary scope which is always sufficient.
Helps with #97331
r? ``@jyn514``
Revert "Remove deferred sized checks"
cc: https://github.com/rust-lang/rust/pull/100652#issuecomment-1225798572
I'm okay with reverting this for now, and I will look into the diagnostic regressions.
This reverts commit 33212bf7f5.
r? `@pnkfelix`
----
EDIT: This _also_ fixes#101066, a regression in method selection logic/coercion(?) due to the early registering of a `Sized` bound.
Support `#[unix_sigpipe = "inherit|sig_dfl"]` on `fn main()` to prevent ignoring `SIGPIPE`
When enabled, programs don't have to explicitly handle `ErrorKind::BrokenPipe` any longer. Currently, the program
```rust
fn main() { loop { println!("hello world"); } }
```
will print an error if used with a short-lived pipe, e.g.
% ./main | head -n 1
hello world
thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', library/std/src/io/stdio.rs:1016:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
by enabling `#[unix_sigpipe = "sig_dfl"]` like this
```rust
#![feature(unix_sigpipe)]
#[unix_sigpipe = "sig_dfl"]
fn main() { loop { println!("hello world"); } }
```
there is no error, because `SIGPIPE` will not be ignored and thus the program will be killed appropriately:
% ./main | head -n 1
hello world
The current libstd behaviour of ignoring `SIGPIPE` before `fn main()` can be explicitly requested by using `#[unix_sigpipe = "sig_ign"]`.
With `#[unix_sigpipe = "inherit"]`, no change at all is made to `SIGPIPE`, which typically means the behaviour will be the same as `#[unix_sigpipe = "sig_dfl"]`.
See https://github.com/rust-lang/rust/issues/62569 and referenced issues for discussions regarding the `SIGPIPE` problem itself
See the [this](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Proposal.3A.20First.20step.20towards.20solving.20the.20SIGPIPE.20problem) Zulip topic for more discussions, including about this PR.
Tracking issue: https://github.com/rust-lang/rust/issues/97889
