[MIR] Deaggregate structs to enable further optimizations
Currently, we generate MIR like:
```
tmp0 = ...;
tmp1 = ...;
tmp3 = Foo { a: ..., b: ... };
```
This PR implements "deaggregation," i.e.:
```
tmp3.0 = ...
tmp3.1 = ...
```
Currently, the code only deaggregates structs, not enums. My understanding is that we do not have MIR to set the discriminant of an enum.
Properly enforce the "patterns aren't allowed in foreign functions" rule
Cases like `arg @ PATTERN` or `mut arg` were missing.
Apply the same rule to function pointer types.
Closes https://github.com/rust-lang/rust/issues/35203
[breaking-change], no breakage in sane code is expected though
r? @nikomatsakis
This is somewhat related to https://github.com/rust-lang/rfcs/pull/1685 (cc @matklad).
The goal is to eventually support full pattern syntax where it makes sense (function body may present) and to support *only* the following forms - `TYPE`, `ident: TYPE`, `_: TYPE` - where patterns don't make sense (function body doesn't present), i.e. in foreign functions and function pointer types.
Support removed LLVM intrinsics by invoking its AutoUpgrade mechanism.
Turns out that LLVM sometimes renames platform intrinsics or replaces them with first-class instructions.
For example, signed minimum became `select (icmp SLT, a, b), a, b` where `a` and `b` are vectors.
This is blocking the Servo rustup ([relevant failure](http://build.servo.org/builders/windows-dev/builds/226/steps/compile/logs/stdio)), as they're using a few such intrinsics.
The fix in this PR is to invoke LLVM's own `AutoUpgrade` mechanism to do the replacements.
Add -mrelax-relocations=no hacks to fix musl build
* this is just a start, dunno if it will work, but I'll just push it out to get feedback (my rust is still building 😢)
* I don't know much about rustbuild, so i just added that flag in there. it's a total hack, don't judge me
* I suspect the places in the musl .mk files are sufficient (but we may also need it present when building std), I'm not sure, needs more testing.
core: fix `cargo build` for targets with "max-atomic-width": 0
This crate was failing to compile due to dead_code/unused_imports
warnings. This commits disables these two lints for these targets.
---
r? @alexcrichton
cc @Amanieu is `cfg(target_has_atomic = "8")` the right `cfg` to use? I think that all targets that support some form of atomics will at a minimum support byte level atomics.
FWIW, the only thing that's left in `sync::atomic` for these targets is `Ordering` and the `fence` function.
rustc_trans: don't lose the cross-crate DefId, MIR trans needs it.
We might have been missing out on some issues because MIR trans was never being used cross-crate.
cc @rust-lang/compiler
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.
