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.
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.
Serialize span hygiene data
Fixes#68686Fixes#70963
This PR serializies global hygiene data into both the incremental compilation cache and the crate metadata. This allows hygiene information to be preserved across compilation sessions (both incremental and cross-crate).
When serializing a `SyntaxContext`, we simply write out the raw id from the current compilation session. Whenever we deserialize a `SyntaxContext`, we 'remap' the id to a fresh id in our current compilation session, and load the associated `SyntaxContextData`.
As a result, some 'upstream' `SyntaxContextData` will end up getting duplicated in 'downstream' crates. This only happens when we actually need to use an 'upstream' `SyntaxContext`, which occurs when we deserialize a `Span` that requires it.
We serialize an `ExpnData` into the metadata of the crate which generated it. An `ExpnId` is serialized as a reference into the crate which 'owns' the corresponding `ExpnData`, which avoids duplication in downstream crates.
I've included a macros 2.0 test which requires hygiene serialization to compile successfully.
TODO:
- [x] <strike>Determine how many additional `DefId`s we end up creating for `ExpnId`s - this may be significant for `libcore`, which uses macros heavily. Alternatively, we could try to compute a `DefPathHash` without making a corresponding `DefId` - however, this might significantly complicate the implementation.</strike> (We no longer create `DefId`s)
- [x] Investigate the overhead of duplicating `SyntaxContextData` in crate metadata.
- [x] Investigate how `resolve_crate_root` behaves with deserialized hygiene data - the current logic may be wrong.
- [x] Add additional tests. The effects of this PR are usually only noticeable when working with headache-inducing macro expansions (e.g. macros expanding to macros), so there are lots of corner cases to test.
- [x] Determine what to do about this:
4774f9b523/src/librustc_resolve/build_reduced_graph.rs (L892)
- [x] Determine if we need to do anything here - I think the fact that `src/test/ui/hygiene/cross_crate_hygiene.rs` passes means that this is working.
3d5d0f898c/src/librustc_resolve/imports.rs (L1389-L1392)
A raw SyntaxContext id is implicitly dependent on the target platform,
since libstd and libcore have platform-dependent #[cfg]s which affect
which macros are invoked. As a result, we must strip out any
SyntaxContext ids from test output to ensure that the captured stdout is
not platform-dependent.
Remove trait LengthAtMost32
This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit.
I talked to @burrbull, he suggested me to finish his PR.
Normalize bounds fully when checking defaulted types
When checking that the default type for `<T as X>::Y` is valid in this example:
```
trait X { type Y: PartialEq<<Self as X>::Y> }
impl X for T { default type Y = S; }
```
We will have to prove the bound `S: PartialEq<<T as X>::Y>`. In this case
we want `<T as X>::Y` to normalize to `S`. This is valid because we are
checking the default value specifically here. Add `<T as X>::Y = S` to the
ParamEnv for normalization _of the bound we are checking_ only.
Fixes#73818.
---
I noticed that adding this to the env for bounds checking didn't break any tests. Not sure if this is because we can't rely on it to prove anything, or because of missing test coverage.
r? @matthewjasper, @nikomatsakis
Fix panic message when `RangeFrom` index is out of bounds
Before, the `Range` method was called with `end = slice.len()`. Unfortunately, because `Range::index` first checks the order of the indices (start has to be smaller than end), an out of bounds index leads to `core::slice::slice_index_order_fail` being called. This prints the message 'slice index starts at 27 but ends at 10', which is worse than 'index 27 out of range for slice of length 10'. This is not only useful to normal users reading panic messages, but also for people inspecting assembly and being confused by `slice_index_order_fail` calls.
You can see the produced assembly [here](https://rust.godbolt.org/z/GzMGWf) and try on Playground [here](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=aada5996b2f3848075a6d02cf4055743). (By the way. this is only about which panic function is called; I'm pretty sure it does not improve anything about performance).
Optimize away BitAnd and BitOr when possible
This PR lets `const_prop` optimize away `a | true == true` , `a & false == false` and `a * 0 = 0`. While I was writing this I've realized that constant propagation misses a lot of opportunities. For example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=2a4b45e772f214210a36749b27223bb0
Constant propagation doesn't seem to... propagate constants, additionally the way constant propagation is currently setup makes it tricky to add cases like `a | false == a`.
I tried to organize `eval_rvalue_with_identities` to make the pattern of the optimizations easier to see but it still obscurs what should be a simple peephole optmization.
cc @oli-obk
correctly deal with unsorted generic parameters
We now stop sorting generic params and instead correctly handle unsorted params in the rest of the compiler.
We still restrict const params to come after type params though, so this PR does not change anything which
is visible to users.
This might slightly influence perf, so let's prevent any unintentional rollups. @bors rollup=never
r? @varkor
Fix ICE while building MIR with type errors
See https://github.com/rust-lang/rust/issues/74047#issuecomment-663290913 for background. Replacing a binding with `PatKind::Wild` (introduced in #51789 and later refactored in #67439) caused an ICE downstream while building MIR.
I noticed that taking this code out no longer triggers the ICEs it was added to prevent. I'm not sure what else changed, or if this change is _correct_, but it does seem to be passing ui tests at least.
r? @oli-obk
cc @estebank
Fixes#74047.
Internally unify rustc_deprecated and deprecated
This PR intentionally tries to be "featureless" in that the behavior is not altered for either attribute, though it more clearly exposes cases where that is the case in the code.
