Auto merge of #74831 - Manishearth:rollup-ugw4pt4, r=Manishearth
Rollup of 4 pull requests
Successful merges:
- #73858 (Make more primitive integer methods const)
- #74487 (Forbid generic parameters in anon consts inside of type defaults)
- #74803 (rustbuild: fix bad usage of UNIX exec() in rustc wrapper)
- #74822 (More ensure stack to avoid segfault with increased `recursion_limit`)
Rollup merge of #74803 - infinity0:fix-exec, r=nagisa
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.)
Rollup merge of #74487 - lcnr:const-in-ty-default, r=varkor
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);
```
Rollup merge of #73858 - tspiteri:const-methods, r=oli-obk
Make more primitive integer methods const
Now that #72437 has been merged and `const_if_match` is stable, these methods can be stabilized const. The methods are grouped in commits according to feature names:
Auto merge of #74775 - RalfJung:miri-alloc-ids, r=oli-obk
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.
Auto merge of #74817 - JohnTitor:rollup-0fchdye, r=JohnTitor
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`)
Rollup merge of #74750 - oli-obk:logging_and_test_cleanups, r=JohnTitor
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.
Rollup merge of #74088 - tmiasko:write-all-vectored-empty, r=KodrAus
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`.
Auto merge of #74737 - smmalis37:astconv-factor, r=davidtwco
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.
Auto merge of #72121 - Aaron1011:final-hygiene-rebase, r=petrochenkov
Serialize span hygiene data
Fixes #68686
Fixes #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:
Aaron Hill [Mon, 27 Jul 2020 00:00:35 +0000 (20:00 -0400)]
Normalize the test output of hygiene-related tests
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.
Tomasz Miąsko [Mon, 6 Jul 2020 00:00:00 +0000 (00:00 +0000)]
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`.
Auto merge of #74670 - tmandry:issue-73818, r=matthewjasper
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.
rustfmt changes:
- preparation for potential rustfmt 1.4.19 (#4283)
- chore: backport 8157a3f0afe978d3e953420577f8344db7e905bf
- deps: bump rustc-ap to v669
- deps: bump rustc-ap-* to v668
- deps: bump rustc-ap* to v666
- Use correct span for match arms with the leading pipe and attributes (#3975)
Changes:
- preparation for potential rustfmt 1.4.19 (#4283)
- chore: backport 8157a3f0afe978d3e953420577f8344db7e905bf
- deps: bump rustc-ap to v669
- deps: bump rustc-ap-* to v668
- deps: bump rustc-ap* to v666
- Use correct span for match arms with the leading pipe and attributes (#3975)
Philippe Nadon [Wed, 22 Jul 2020 15:08:59 +0000 (09:08 -0600)]
Miri: rename "undef" to "uninit"
renamed Allocation::check_defined_and_ptr to Allocation::check_init_and_ptr
renamed Allocation::check_defined_and_ptr to Allocation::check_init_and_ptr
in src/librustc_middle/mir/interpret/allocation.rs
renamed Allocation::is_defined and Allocation::check_defined, fixed documentation
renamed Allocation::is_defined and Allocation::check_defined to is_init and check_init respectively.
Fixed documentation so it correctly refers to "initialization" instead of "defined"-ness
renamed Allocation::mark_definedness
renamed Allocation::mark_definedness to Allocation::mark_init
Renamed new_state parameter in Allocation::mark_init
Renamed new_state to is_init, as the latter is more descriptive.
renamed functions in AllocationDefinedness
renamed AllocationDefinedness::all_bytes_undef and AllocationDefinedness::mark_compressed_undef_range to no_bytes_init and mark_compressed_init_range respectively.
renamed AllocationDefinedness to InitMaskCompressed
renamed Immediate::to_scalar_or_undef
renamed to to_scalar_or_uninit
fixed comment references to "undef"
Changed comments referring to "undef" and "definedness" to "initialization" and "initialization state" in src/librustc_mir/interpret/memory.rs and src/librustc_middle/mir/interpret/allocation.rs
changed references to "undef" in comments and a variable
Changed some comments referring to "undef" to use "uninitialized" instead. Also changed a variable from "undef_end" to "uninit_end".
All changes were made within src/librustc_middle/mir/interpret/allocation.rs.
Changed more comments referring to undef
Changed comments to use "uninitialized" instead of "undef" in src/librustc_middle/mir/interpret/allocation.rs.
Auto merge of #74510 - LukasKalbertodt:fix-range-from-index-panic, r=hanna-kruppe
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).
Fixed coverage map issues; better aligned with LLVM APIs
Found some problems with the coverage map encoding when testing with
more than one counter per function.
While debugging, I realized some better ways to structure the Rust
implementation of the coverage mapping generator. I refactored somewhat,
resulting in less code overall, expanded coverage of LLVM Coverage Map
capabilities, and much closer alignment with LLVM data structures, APIs,
and naming.
This should be easier to follow and easier to maintain.