Don't reduce E0161 to a warning in NLL migrate mode
This error has been on stable for a while, and allowing such code cause the compile to later ICE (since we can't codegen it). Errors `box UNSIZED EXPR` with unsized locals because it's not compatible with the current evaluation order (create the box before evaluating the expressions).
cc #53469 (fixes the ICE in this case)
cc @qnighy
Fix issue #52475: Make loop detector only consider reachable memory
As [suggested](https://github.com/rust-lang/rust/pull/51702#discussion_r197585664) by @oli-obk `alloc_id`s should be ignored by traversing all `Allocation`s in interpreter memory at a given moment in time, beginning by `ByRef` locals in the stack.
- [x] Generalize the implementation of `Hash` for `EvalSnapshot` to traverse `Allocation`s
- [x] Generalize the implementation of `PartialEq` for `EvalSnapshot` to traverse `Allocation`s
- [x] Commit regression tests
Fixes#52626
Fixes https://github.com/rust-lang/rust/issues/52849
That is, opting to ignore stable `#![feature(..)]`, under my theory
that a reviewer would prefer as much stuff to be bucketed under "ah
another `#![allow(..)]` here." as possible.
that is, I suspect it should be retired because it is testing behavior
(namely a `#[repr(C)] struct Empty;`) that, if I understand correctly,
is undefined.
See also rust-lang/rust#53859.
rustc_typeck: turn `where Type:,` into a WF(Type) predicate, instead of ignoring it.
Fixes#53696, assuming crater doesn't catch anyone using this syntax already.
Allowing an empty list of bounds in the grammar was done for the benefit of macro authors, most of which would *probably* be using it for bounds on type parameters, which are always WF.
r? @nikomatsakis cc @petrochenkov
fix `is_non_exhaustive` confusion between structs and enums
Structs and enums can both be non-exhaustive, with a very different
meaning. This PR splits `is_non_exhaustive` to 2 separate functions - 1
for structs, and another for enums, and fixes the places that got the
usage confused.
Fixes#53549.
r? @eddyb
rustbuild: Tweak LLVM distribution layout
This commit tweaks the layout of a few components that we distribute to
hopefully fix across all platforms the recent issues with LLD being unable to
find the LLVM shared object. In #53245 we switched to building LLVM as a dynamic
library, which means that LLVM tools by default link to LLVM dynamically rather
than statically. This in turn means that the tools, at runtime, need to find the
LLVM shared library.
LLVM's shared library is currently distributed as part of the rustc component.
This library is located, however, at `$sysroot/lib`. The LLVM tools we ship are
in two locations:
* LLD is shipped at `$sysroot/lib/rustlib/$host/bin/rust-lld`
* Other LLVM tools are shipped at `$sysroot/bin`
Each LLVM tool has an embedded rpath directive indicating where it will search
for dynamic libraries. This currently points to `../lib` and is presumably
inserted by LLVM's build system. Unfortunately, though, this directive is only
correct for the LLVM tools at `$sysroot/bin`, not LLD!
This commit is targeted at fixing this situation by making two changes:
* LLVM tools other than LLD are moved in the distribution to
`$sysroot/lib/rustlib/$host/bin`. This moves them next to LLD and should
position them for...
* The LLVM shared object is moved to `$sysroot/lib/rustlib/$host/lib`
Together this means that all tools should natively be able to find the shared
object and the shared object should be installed all the time for the various
tools. Overall this should...
Closes#53813
Added in #52149 the discussion in #53514 is showing how we may not want to
actually add this attribute to the atomic types. While we continue to
debate #53514 this commit reverts the addition of the `transparent` attribute.
This should be a more conservative route which leaves us the ability to tweak
this in the future but in the meantime allows us to continue discussion as well.
