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
Update rustfmt and rls
Closes#74080, #74081.
rls changes:
- deps: update racer and cargo
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)
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.
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).
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.
Document the where keyword
Partial fix of #34601 (and last PR for it 🎉).
This documents the `where` keyword.
@rustbot modify labels: T-doc,C-enhancement
Document the ref keyword
Partial fix for #34601.
This documents the `ref` keyword with two examples, one failing to compile because the `ref` keyword is missing, and the same example fixed with the keyword inserted in the correct place.
It also explains (very *very* rapidly) the differences between `&` and `ref`.
I put a link to the best place I could find in the Reference but there may be something better that I didn't find.
Miri: use extern fn to expose interpreter operations to program; fix leak checker on Windows
This PR realizes an idea that @oli-obk has been suggesting for a while: to use Miri-specific `extern` functions to provide some extra capabilities to the program. Initially, we have two of these methods, which libstd itself needs:
* `miri_start_panic`, which replaces the intrinsic of the same name (mostly for consistency, to avoid having multiple mechanisms for Miri-specific functionality).
* `miri_static_root`, which adds an allocation to a list of static "roots" that Miri considers as not having leaked (including all memory reachable through them). This is needed for https://github.com/rust-lang/miri/issues/1302.
We use `extern` functions instead of intrinsics for this so that user code can more easily call these Miri hoolks -- e.g. `miri_static_root` should be useful for https://github.com/rust-lang/miri/issues/1318.
The Miri side of this is at https://github.com/rust-lang/miri/pull/1485.
r? @oli-obk
Rollup of 8 pull requests
Successful merges:
- #72954 (revise RwLock for HermitCore)
- #74367 (Rearrange the pipeline of `pow` to gain efficiency)
- #74491 (Optimize away BitAnd and BitOr when possible)
- #74639 (Downgrade glibc to 2.11.1 for ppc, ppc64 and s390x)
- #74661 (Refactor `region_name`: add `RegionNameHighlight`)
- #74692 (delay_span_bug instead of silent ignore)
- #74698 (fixed error reporting for mismatched traits)
- #74715 (Add a system for creating diffs across multiple mir optimizations.)
Failed merges:
r? @ghost
Refactor `region_name`: add `RegionNameHighlight`
This PR does not change any diagnostics itself, rather it enables further code changes, but I would like to get approval for the refactoring first before making use of it.
In `rustc_mir::borrow_check::diagnostics::region_name`, there is code that allows for, when giving a synthesized name like `'1` to an anonymous lifetime, pointing at e.g. the exact '`&`' that introduces the lifetime.
This PR decouples that code from the specific case of arguments, adding a new enum `RegionNameHighlight`, enabling future changes to use it in other places.
This allows:
* We could change the other `AnonRegionFrom*` variants to use `RegionNameHighlight` to precisely point at where lifetimes are introduced in other locations when they have type annotations, e.g. a closure return `|...| -> &i32`.
* Because of how async functions are lowered this affects async functions as well, see #74072
* for #74597, we could add a second, optional `RegionNameHighlight` to the `AnonRegionFromArgument` variant that highlights a lifetime in the return type of a function when, due to elision, this is the same as the argument lifetime.
* in https://github.com/rust-lang/rust/issues/74497#issuecomment-6606229707 I noticed that a diagnostic was trying to introduce a lifetime `'2` in the opaque type `impl std::future::Future`. The code for the case of arguments has [code to handle cases like this](bbebe7351f/src/librustc_mir/borrow_check/diagnostics/region_name.rs (L365)) but not the others. This refactoring would allow the same code path to handle this.
* It might be appropriate to add another variant of `RegionNameHighlight` to say something like `lifetime '1 appears in the opaque type impl std::future::Future`.
These are quite a few changes so I thought I would make sure the refactoring is OK before I start making changes that rely on it. :)
Downgrade glibc to 2.11.1 for ppc, ppc64 and s390x
As discussed in #73782
I've tested these changes on rust 1.43.0 for all the specified archs and used the resulting binaries to bootstrap building rust 1.43.1.
I've also shortly tested these changes on master on ppc64.
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
revise RwLock for HermitCore
- current version is derived from the wasm implementation
- increasing the readability of `Condvar`
- simplify the interface to the libos
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
Yuki Okushi