Derive common traits for panic::Location.
Now that `#[track_caller]` is on track to stabilize, one of the roughest edges of working with it is the fact that you can't do much with `Location` except turn it back into a `(&str, u32, u32)`. Which makes sense because the type was defined around the panic machinery originally passing around that tuple (it has the same layout as Location even).
This PR derives common traits for the type in accordance with the [API guidelines](https://rust-lang.github.io/api-guidelines/interoperability.html#types-eagerly-implement-common-traits-c-common-traits) (those apply to core, right?).
There's a risk here, e.g. if we ever change the representation of `Location` in a way that makes it harder to implement `Ord`, we might not be able to make that change in a backwards-compatible way. I don't think there's any other compatibility hazard here, as the only changes we currently imagine for the type are to add end fields.
cc @rust-lang/libs
More ensure stack to avoid segfault with increased `recursion_limit`
Fixes#74711
I do not add the test here since the limit value depends on the machine and it's hard to test the output.
r? @oli-obk
rustbuild: fix bad usage of UNIX exec() in rustc wrapper
exec never returns, it replaces the current process. so anything after it is unreachable. that's not how exec_cmd() is used in the surrounding code
We use `--on-fail env` on Debian. `env` always returns exit code 0. This means that the `rustc` bootstrap wrapper always returns exit code 0 even when it fails. However, the crossbeam-utils build process (due to autocfg) relies on `rustc` returning error exit codes when detecting CPU features, and ends up writing `cargo:rustc-cfg=has_atomic_u128` even when it's not detected, because the `rustc` wrapper is always giving exit code 0.
(This separately is causing our builds to try to compile rustc 40+ times, due to #74801.)
Forbid generic parameters in anon consts inside of type defaults
Emit a resolution error for `struct Foo<T, U = [u8; std::mem::size_of::<T>()]>`.
We are unable to support this with the way `ty::Generics` is currently used,
so let's just forbid it entirely for now.
Fixes some ICE on stable, e.g.
```rust
struct Foo<T, U = [u8; std::mem::size_of::<*mut T>()]>(T, U);
```
r? @varkor @eddyb
Miri: replace canonical_alloc_id mechanism by extern_static_alloc_id
We only have to call `extern_static_alloc_id` when a `Pointer` is "imported" from the `tcx` to the machine, not on each access. Also drop the old hook for TLS handling, it is not needed any more.
The Miri side of this is at https://github.com/rust-lang/miri/pull/1489.
Fixes https://github.com/rust-lang/rust/issues/71194
r? @oli-obk
Rollup of 6 pull requests
Successful merges:
- #74088 (Avoid writes without any data in `Write::write_all_vectored`)
- #74598 (Fix sync_once_cell_does_not_leak_partially_constructed_boxes)
- #74750 (Clean up some uses of logging in ui tests)
- #74783 (python codes cleanup)
- #74790 (Don't italicize comments in ayu theme)
- #74799 (Fixed typo in `closure`)
Failed merges:
r? @ghost
Clean up some uses of logging in ui tests
The removed test can't possibly trigger anything today as we don't have logging in libstd.
The `exec-env` flag was mistakenly used for adding env vars to rustc invocations both in test and in the test suite and there were some accidental renames from RUST_LOG to RUSTC_LOG that I reverted.
Fix sync_once_cell_does_not_leak_partially_constructed_boxes
Spinning multiple threads in this test causes a deadlock in
SGX where thread scheduling is not preemptive.
cc @jethrogb @AdrianCX
Avoid writes without any data in `Write::write_all_vectored`
Previously, when non-empty sequence of empty IoSlices have been provided
to `Write::write_all_vectored`, the buffers would be written as is with
`Write::write_vectored` and subsequently the return value `Ok(0)` would
be misinterpreted as an error.
Avoid writes without any data by advancing the buffers first. This
matches the documented behaviour of `Write::write_all_vectored`
and is analogous to what happens in `Write::write_all`.
Pull out some duplicated code into a new function
I debated pulling the actual struct_span_err calls into the new method, but I felt like having to pass in multiple arguments for it and wiring up string formatting outweighed the benefits.
Viewing the diff with whitespace ignored is recommended.
proc_macro: Add API for tracked access to environment variables
Continuation of https://github.com/rust-lang/rust/pull/71858.
`proc_macro::tracked_env::var` is similar to regular `env::var` called from a proc macro, except that it also adds the accessed variable to depinfo.
