When we hash the inputs to a MetaData node, we have to hash them in a
consistent order. We achieve this by sorting the stringfied `DefPath`
entries. Also, micro-optimie by cache more results across the saving
process.
The reads will occur naturally as the HIR/MIR is fetched from the
tracked tables, and this winds up adding reads to the hir of foreign
def-ids somehow.
The biggest problem, actually, is krate numbers being removed entirely,
which can lead to array-index-out-of-bounds errors.
cc #35123 -- not a complete fix, since really we ought to "map" the old
crate numbers to the new ones, not just detect changes.
The way we do HIR inlining introduces reads of the "Hir" into the graph,
but this Hir in fact belongs to other crates, so when we try to load
later, we ICE because the Hir nodes in question don't belond to the
crate (and we haven't done inlining yet). This pass rewrites those HIR
nodes to the metadata from which the inlined HIR was loaded.
Switch to MIR-based translation by default.
This patch makes `-Z orbit` default to "on", which means that by default, functions will be translated from Rust to LLVM IR through the upcoming MIR backend, instead of the antiquated AST backend.
This switch is made possible by the recently merged #33622, #33905 and smaller fixes.
If you experience any issues, please file a report for each of them. You can switch to the old backend to work around problems by either setting `RUSTFLAGS="-Zorbit=off"` or by annotating specific functions with `#[rustc_no_mir]` (which requires `#![feature(rustc_attrs)]` at the crate-level).
I would like this PR to get into nightly soon so that we can get early feedback in this release cycle and focus on correctness fixes and performance improvements, with the potential for removing the old backend implementation before beta branches off.
cc @rust-lang/compiler
implement `From<Vec<char>>` and `From<&'a [char]>` for `String`
Though there are ways to convert a slice or vec of chars into a string,
it would be nice to be able to just do `String::from(&['a', 'b', 'c'])`,
so this PR implements `From<Vec<char>>` and `From<&'a [char]>` for
String.
rustc_trans: apply the debug location for the MIR Assert panic call.
Helps `libcore` build with MIR trans and debuginfo; libcore has the body of `panic`, which resulted in:
```
inlinable function call in a function with debug info must have a !dbg location
call void @_ZN4core9panicking5panic17h585bd70cda921012E({ %str_slice, %str_slice, i32 }* @panic_loc12745)
LLVM ERROR: Broken function found, compilation aborted!
```
tcp-stress-test: Pull out thread count as a constant
This PR factors out the number of concurrent threads used in `tcp-stress-test.rs` to a constant at the top of the file.
We at @NixOS had to lower our thread count as the chrooted-builds don't allow that many threads.
This change will make it easier to lower/increase the count in the future (I actually forgot to change the second `1000` when I was working on this). Another benefit is the removal of magic numbers in the test suite.
This is related to https://github.com/rust-lang/rust/issues/35107
Move caching of inlined HIR into CrateStore
So far we've had separate HIR-inlining caches for each codegen unit and the caching for things inlined during constant evaluation had some holes. Consequently, things would be inlined multiple times if they were used from different codegen units, etc, leading to
- wasted memory,
- multiple `NodeId`s per `DefId` and,
- for things inlined during constant evaluation, no way to map a `NodeId` back to it's original `DefId`.
This PR moves all caching into the CrateStore, solving all of the above problems. It also fixes some bugs in the inlining code, like cyclic in the parent-chains in the HIR map and some `NodeId`'s being translated to more or less random values. There are assertions in place now that should prevent this kind of thing in the future.
This PR based on top of #35090, which contains some necessary fixes.
Use "x86-64" as the target CPU for NetBSD and Bitrig on amd64.
Using "generic" disables a number of features that are present on all
x86_64 cpus, the "x86-64" target cpu is the common denominator for that
arch.
Refs #20777
