Remove `TypeAndMut` from `ty::RawPtr` variant, make it take `Ty` and `Mutability`
Pretty much mechanically converting `ty::RawPtr(ty::TypeAndMut { ty, mutbl })` to `ty::RawPtr(ty, mutbl)` and its fallout.
r? lcnr
cc rust-lang/types-team#124
"Handle" calls to upstream monomorphizations in compiler_builtins
This is pretty cooked, but I think it works.
compiler-builtins has a long-standing problem that at link time, its rlib cannot contain any calls to `core`. And yet, in codegen we _love_ inserting calls to symbols in `core`, generally from various panic entrypoints.
I intend this PR to attack that problem as completely as possible. When we generate a function call, we now check if we are generating a function call from `compiler_builtins` and whether the callee is a function which was not lowered in the current crate, meaning we will have to link to it.
If those conditions are met, actually generating the call is asking for a linker error. So we don't. If the callee diverges, we lower to an abort with the same behavior as `core::intrinsics::abort`. If the callee does not diverge, we produce an error. This means that compiler-builtins can contain panics, but they'll SIGILL instead of panicking. I made non-diverging calls a compile error because I'm guessing that they'd mostly get into compiler-builtins by someone making a mistake while working on the crate, and compile errors are better than linker errors. We could turn such calls into aborts as well if that's preferred.
Suggest `RUST_MIN_STACK` workaround on overflow
For some Rust crates, like p384, we can't do a whole lot about it even if the stack overflow is reported like in rust-lang/rust#122357 because the problem may be inside LLVM or another codegen backend. We can, however, suggest people set a new `RUST_MIN_STACK` value while handling the SIGSEGV, as that stack-setting will carry forward into the dylib.
As a bonus, this also leads to cleaning up the stack-setting code a bit.
coverage: Clean up marker statements that aren't needed later
Some of the marker statements used by coverage are added during MIR building for use by the InstrumentCoverage pass (during analysis), and are not needed afterwards.
```@rustbot``` label +A-code-coverage
interpret/allocation: fix aliasing issue in interpreter and refactor getters a bit
That new raw getter will be needed to let Miri pass pointers to natively executed FFI code ("extern-so" mode).
While doing that I realized our get_bytes_mut are named less scary than get_bytes_unchecked so I rectified that. Also I realized `mem_copy_repeatedly` would break if we called it for multiple overlapping copies so I made sure this does not happen.
And I realized that we are actually [violating Stacked Borrows in the interpreter](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/I.20think.20Miri.20violates.20Stacked.20Borrows.20.F0.9F.99.88).^^ That was introduced in https://github.com/rust-lang/rust/pull/87777.
r? ```@oli-obk```
Gracefully handle `AnonConst` in `diagnostic_hir_wf_check()`
Instead of running the WF check on the `AnonConst` itself we run it on the `ty` of the generic param of which the `AnonConst` is the default value.
Fixes#122199
Experimental feature postfix match
This has a basic experimental implementation for the RFC postfix match (rust-lang/rfcs#3295, #121618). [Liaison is](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Postfix.20Match.20Liaison/near/423301844) ```@scottmcm``` with the lang team's [experimental feature gate process](https://github.com/rust-lang/lang-team/blob/master/src/how_to/experiment.md).
This feature has had an RFC for a while, and there has been discussion on it for a while. It would probably be valuable to see it out in the field rather than continue discussing it. This feature also allows to see how popular postfix expressions like this are for the postfix macros RFC, as those will take more time to implement.
It is entirely implemented in the parser, so it should be relatively easy to remove if needed.
This PR is split in to 5 commits to ease review.
1. The implementation of the feature & gating.
2. Add a MatchKind field, fix uses, fix pretty.
3. Basic rustfmt impl, as rustfmt crashes upon seeing this syntax without a fix.
4. Add new MatchSource to HIR for Clippy & other HIR consumers
Some of the marker statements used by coverage are added during MIR building
for use by the InstrumentCoverage pass (during analysis), and are not needed
afterwards.
CFI: Skip non-passed arguments
Rust will occasionally rely on fn((), X) -> Y being compatible with fn(X) -> Y, since () is a non-passed argument. Relax CFI by choosing not to encode non-passed arguments.
This PR was split off from #121962 as part of fixing the larger vtable compatibility issues.
r? `@workingjubilee`
This makes it easier to read the trait definition for newcomers:
Sorted from least “complex” to most “complex” followed by trivial “plumbing”
and grouped by area.
* Move `allow_infer` above all `*_infer` methods
* It's the least complex method of those
* Allows the `*_infer` to be placed right next to each other
* Move `probe_ty_param_bounds` further down right next to `lower_assoc_ty` and `probe_adt`
* It's more complex than the `infer` methods, it should come “later”
* Now all required lowering functions are grouped together
* Move the “plumbing” function `set_tainted_by_errors` further down
below any actual lowering methods.
* Provided method should come last
Most of the tracing calls didn't fully leverage the power of `tracing`.
For example, several of them used to hard-code method names / tracing spans
as well as variable names. Use `#[instrument]` and `?var` / `%var` (etc.) instead.
In my opinion, this is the proper way to migrate them from the old
AstConv nomenclature to the new HIR ty lowering one.
Several (doc) comments were super outdated or didn't provide enough context.
Some doc comments shoved everything in a single paragraph without respecting
the fact that the first paragraph should be a single sentence because rustdoc
treats these as item descriptions / synopses on module pages.
Remove SpecOptionPartialEq
With the recent LLVM bump, the specialization for Option::partial_eq on types with niches is no longer necessary. I kept the manual implementation as it still gives us better codegen than the derive (will look at this seperately).
Also implemented PartialOrd/Ord by hand as it _somewhat_ improves codegen for #49892: https://godbolt.org/z/vx5Y6oW4Y
Rollup of 11 pull requests
Successful merges:
- #121881 (std::net: adding acceptfilter feature for netbsd/freebsd.)
- #122817 (Doc Guarantee: BTree(Set|Map): `IntoIter` Iterate in Sorted by key Order)
- #122826 (Add tests for shortcomings of associated type bounds)
- #122829 (Implement `FusedIterator` for `gen` block)
- #122831 (make failure logs less verbose)
- #122837 (add test for #122549)
- #122838 (Avoid noop rewrite of issues.txt)
- #122841 (add 2 more tests for issues fixed by #122749)
- #122843 (Add a never type option to make diverging blocks `()`)
- #122844 (add test for ice "cannot relate region: LUB(ReErased, ReError)")
- #122845 (Clippy subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
Add a never type option to make diverging blocks `()`
More experiments for ~~the blood god~~ T-lang!
Usage example:
```rust
#![allow(internal_features)]
#![feature(never_type, rustc_attrs)]
#![rustc_never_type_options(diverging_block_default = "unit")]
fn main() {
let _: u8 = { //~ error: expected `u8`, found `()`
return;
};
}
```
r? compiler-errors
I'm not sure how I feel about parsing the attribute every time we create `FnCtxt`. There must be a better way to do this, right?
Add tests for shortcomings of associated type bounds
Adds the test in https://github.com/rust-lang/rust/pull/122791#issuecomment-2011433015
Turns out that #121123 is what breaks `tests/ui/associated-type-bounds/cant-see-copy-bound-from-child-rigid.rs` (passes on nightly), but given that associated type bounds haven't landed anywhere yet, I'm happy with breaking it.
This is unrelated to #122791, which just needed that original commit e6b64c6194 stacked on top of it so that it wouldn't have tests failing.
r? lcnr
Doc Guarantee: BTree(Set|Map): `IntoIter` Iterate in Sorted by key Order
This Doc-only PR adds text to the IntoIterator implementation and IntoIter type for both BTreeMap and BTreeSet that states that the returned items will be in sorted-by-key order, this is a guarantee that is made by the iter() and iter_mut() methods of BTreeMap/Set and BTreeMap respectively, but not on into_iter methods or types.
I don't know how the IntoIter iteration would not be sorted by key, and I would like to rely on that behavior for my prefix_array crate.
The text appended to IntoIter documentation is based on each types respective iter() method documentation, as is the text used in the IntoIterator documentation; they are slightly inconsistent between Set/Map, but they are consistent within their own types documentation.
