Option::expect, Result::unwrap, unwrap_err, expect
These methods are marked inline, but insert a big chunk of formatting
code, as well as other error path related code, such as deallocating
a std::io::Error if you have one.
We can explicitly separate out that code path into a function that is
never inline, since the panicking case should always be rare.
This is a fix for #30741. It simplifies dep-graph tracking for trait matching. I was experimenting with having a greater resolution here, but decided to pare back to just have one dep node for "trait resolutions on trait `Foo`", which means that adding an impl to the trait `Foo` will invalidate all fns that had to do any trait matching at all on `Foo`. This seems like a reasonable starting place.
Independently, I realized I had neglected to record a dependency from trans on typeck -- this is obviously needed, since trans consumes a bunch of data structures that typeck produces (but which are not currently individually tracked) -- and because trans assumes that typeck has been done. Eventually those are going to go away and be replaced with MIR, which will be tracked, so this edge would presumably be derived automatically then, but it's an obvious enough thing to want for now.
r? @arielb1
cc @michaelwoerister -- this might indirectly fix the problem you observed with the trans cache, though it'd be nice to try and craft an independent test case for that.
This fixes#27254.
On a 64-bit Linux machine, for example, `configure --libdir=/usr/local/lib64` was creating both `x86_64-unknown-linux-gnu/stage0/lib/rustlib` and `x86_64-unknown-linux-gnu/stage0/lib64/rustlib`. Crates from the stage0 snapshot, like `libcore`, are extracted to `x86_64-unknown-linux-gnu/stage0/lib/rustlib`, but the stage0 compiler was attempting to find them in `x86_64-unknown-linux-gnu/stage0/lib64/rustlib`, which has the highest priority on a 64-bit system.
The issue can be fixed by creating only `x86_64-unknown-linux-gnu/stage0/lib/rustlib`, since this is the only rustlib directory needed for stage0 anyways.
This PR for #29789 uses `rustc::repr::mir::Constant` in `ExprKind::Repeat`, which seems to fit quite nicely. Is there a reason for not re-using that type?
Tuple and unit variants from other crates weren't put into type namespace.
Now variant namespacing is aligned with struct namespacing and is not affected by the variant's crate of origin (struct -> type, tuple/unit -> type/value).
Additionally, struct variants from other crates are put into value namespace (struct variants from local crate were already in it). This is not a necessity, but a future proofing measure.
This fix can result in some new shadowing errors in cross-crate scenarios, crater reports [three regressions](https://github.com/rust-lang/rust/pull/30882#issuecomment-172369883).
[breaking-change]
Use raw pointers to avoid aliasing in str::split_at_mut
Introduce private function from_raw_parts_mut for str to factor out the logic.
We want to use raw pointers here instead of duplicating a &mut str, to
be on safer ground w.r.t rust aliasing rules.
This has already been fixed for slices in PR #27358, issue #27357
was the major use-case, and to update the dep-graph. Other kinds of
predicates are now excluded from the cache because there is no easy way
to make a good dep-graph node for them, and because they are not
believed to be that useful. :)
Fixes#30741. (However, the test still gives wrong result for trans,
for an independent reason which is fixed in the next commit.)
