Stop turning transmutes into discriminant reads in mir-opt
Partially reverts #109612, as after #109993 these aren't actually equivalent any more, and I'm no longer confident this was ever an improvement in the first place.
Having this "simplification" meant that similar-looking code actually did somewhat different things. For example,
```rust
pub unsafe fn demo1(x: std::cmp::Ordering) -> u8 {
std::mem::transmute(x)
}
pub unsafe fn demo2(x: std::cmp::Ordering) -> i8 {
std::mem::transmute(x)
}
```
in nightly today is generating <https://rust.godbolt.org/z/dPK58zW18>
```llvm
define noundef i8 `@_ZN7example5demo117h341ef313673d2ee6E(i8` noundef %x) unnamed_addr #0 {
%0 = icmp uge i8 %x, -1
%1 = icmp ule i8 %x, 1
%2 = or i1 %0, %1
call void `@llvm.assume(i1` %2)
ret i8 %x
}
define noundef i8 `@_ZN7example5demo217h5ad29f361a3f5700E(i8` noundef %0) unnamed_addr #0 {
%x = alloca i8, align 1
store i8 %0, ptr %x, align 1
%1 = load i8, ptr %x, align 1, !range !2, !noundef !3
ret i8 %1
}
```
Which feels too different when the original code is essentially identical.
---
Aside: that example is different *after* optimizations too:
```llvm
define noundef i8 `@_ZN7example5demo117h341ef313673d2ee6E(i8` noundef returned %x) unnamed_addr #0 {
%0 = add i8 %x, 1
%1 = icmp ult i8 %0, 3
tail call void `@llvm.assume(i1` %1)
ret i8 %x
}
define noundef i8 `@_ZN7example5demo217h5ad29f361a3f5700E(i8` noundef returned %0) unnamed_addr #1 {
ret i8 %0
}
```
so turning the `Transmute` into a `Discriminant` was arguably just making things worse, so leaving it alone instead -- and thus having less code in rustc -- seems clearly better.
Add a conversion from `&mut T` to `&mut UnsafeCell<T>`
Provides a safe way of downgrading an exclusive reference into an alias-able `&UnsafeCell<T>` reference.
ACP: https://github.com/rust-lang/libs-team/issues/198.
debug format `Const`'s less verbosely
Not user visible change only visible to people debugging const generics.
Currently debug output for `ty::Const` is super verbose (even for `-Zverbose` lol), things like printing infer vars as `Infer(Var(?0c))` instead of just `?0c`, bound vars and placeholders not using `^0_1` or `!0_1` syntax respectively. With these changes its imo better but not perfect:
`Const { ty: usize, kind: ^0_1 }`
is still a lot for not much information. not entirely sure what to do about that so not dealing with it yet.
Need to do formatting for `ConstKind::Expr` at some point too since rn it sucks (doesn't even print anything with `Display`) not gonna do that in this PR either.
r? `@compiler-errors`
Update cargo
8 commits in 13413c64ff88dd6c2824e9eb9374fc5f10895d28..09276c703a473ab33daaeb94917232e80eefd628
2023-05-10 13:46:18 +0000 to 2023-05-16 21:43:35 +0000
- docs: Clarify that crates.io doesn't link to docs.rs right away. (rust-lang/cargo#12146)
- docs(ref): Clarify MSRV is generally minor (rust-lang/cargo#12122)
- Fix `check_for_file_and_add`'s check for conflict file (rust-lang/cargo#12135)
- Fixes: Incorrect document link (rust-lang/cargo#12143)
- doc: intra-doc links and doc comments for build script (rust-lang/cargo#12133)
- Add Cargo team charter. (rust-lang/cargo#12010)
- Remove useless drop of copy type (rust-lang/cargo#12136)
- Fix dep/feat syntax with hidden implicit optional dependencies (rust-lang/cargo#12130)
r? ghost
Rollup of 7 pull requests
Successful merges:
- #107680 (Hide repr attribute from doc of types without guaranteed repr)
- #111488 (Use error term in projection if missing associated item in new solver)
- #111533 (Handle error body in generator layout)
- #111573 (Erase `ReError` properly)
- #111592 (Change Vec examples to not assert exact capacity except where it is guaranteed)
- #111610 (fix(diagnostic): wrap parens for ref impl trait param)
- #111642 ([rustdoc] Only keep impl blocks from bodies)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
[rustdoc] Only keep impl blocks from bodies
Fixes https://github.com/rust-lang/rust/issues/111415.
The problem was that we kept everything inside bodies whereas only impl blocks are actually accessible from outside bodies.
r? `@notriddle`
fix(diagnostic): wrap parens for ref impl trait param
Fixes https://github.com/rust-lang/rust/issues/99597
When parameters are an `impl_trait` which it needed to add trait, and it is a reference, add parentheses to the type of the parameter in the suggestion
Change Vec examples to not assert exact capacity except where it is guaranteed
It was [brought up on discord](https://discord.com/channels/273534239310479360/818964227783262209/1107633959329878077) that the `Vec::into_boxed_slice` example contradicted the `Vec::with_capacity` docs in that the returned `Vec` might have _more_ capacity than requested.
So, to reduce confusion change all the `assert_eq!(vec.capacity(), _)` to `assert!(vec.capacity() >= _)`, except in 4 examples that have guaranteed capacities: `Vec::from_raw_parts`, `Vec::from_raw_parts_in`, `Vec::<()>::with_capacity`,`Vec::<(), _>::with_capacity_in`.
Erase `ReError` properly
Fixes#111341
Since we check whether a type has free regions before erasing (to short circuit unnecesary folding), we need to consider `ReError` as a free region, or else we'll skip it when erasing a type that only mentions `ReError`.
cc `@nnethercote`
Handle error body in generator layout
Fixes#111468
I feel like making this query return `Option<GeneratorLayout>` might be better but had some issues with that approach
Use error term in projection if missing associated item in new solver
We were previously delaying a bug but not bailing, leading to an ICE in the `tcx.type_of(assoc_def.item.def_id)` call below.
Hide repr attribute from doc of types without guaranteed repr
Rustdoc has an undesirable behavior of blindly copying `repr` into the documentation of structs and enums, even when there is no particular repr that the type guarantees to its users. This is a source of confusion for standard library users who assume the fact that a repr is documented means it must be something the standard library promises they can rely on (in transmutes, or FFI).
Some issues on the topic of rustdoc's incorrect handling of `repr`:
- https://github.com/rust-lang/rust/issues/66401
- https://github.com/rust-lang/rust/issues/90435
In places, the standard library currently works around this confusing rustdoc behavior by just omitting `repr(transparent)` altogether even where it should be required if equivalent code were being written outside of the standard library. See #61969.
IMO that is even more confusing, even for standard library maintainers — see https://github.com/rust-lang/rust/pull/105018#discussion_r1058400997. It's also not something that works for other reprs like `C` or `u8` which cannot just be omitted even in standard library code.
This PR tries a different approach for some types that are being currently incorrectly documented with a repr.
> **Warning**
> This PR does not imply that every type that still has a `repr` attribute in its docs after this PR is now public for users to rely on. This PR only tries to reduce harm from this longstanding rustdoc issue.
