Extra allocations are a significant cost of NLL, and the most common
ones come from within `Canonicalizer`. In particular, `canonical_var()`
contains this code:
indices
.entry(kind)
.or_insert_with(|| {
let cvar1 = variables.push(info);
let cvar2 = var_values.push(kind);
assert_eq!(cvar1, cvar2);
cvar1
})
.clone()
`variables` and `var_values` are `Vec`s. `indices` is a `HashMap` used
to track what elements have been inserted into `var_values`. If `kind`
hasn't been seen before, `indices`, `variables` and `var_values` all get
a new element. (The number of elements in each container is always the
same.) This results in lots of allocations.
In practice, most of the time these containers only end up holding a few
elements. This PR changes them to avoid heap allocations in the common
case, by changing the `Vec`s to `SmallVec`s and only using `indices`
once enough elements are present. (When the number of elements is small,
a direct linear search of `var_values` is as good or better than a
hashmap lookup.)
The changes to `variables` are straightforward and contained within
`Canonicalizer`. The changes to `indices` are more complex but also
contained within `Canonicalizer`. The changes to `var_values` are more
intrusive because they require defining a new type
`SmallCanonicalVarValues` -- which is to `CanonicalVarValues` as
`SmallVec` is to `Vec -- and passing stack-allocated values of that type
in from outside.
All this speeds up a number of NLL "check" builds, the best by 2%.
Don't suggest `let` bindings if they don't help with borrows
@oli-obk I have added a condition to address #52049, right now, this is on WIP because I think code change is also required on `error_reporting.rs`. Plus I need to check if any test cases fail.
I will ping you again if everything passes
r? @oli-obk
clarify why we're suggesting removing semicolon after braced items
Previously (issue #46186, pull-request #46258), a suggestion was added
to remove the semicolon after we fail to parse an item, but issue #51603
complains that it's still insufficiently obvious why. Let's add a note.
Resolves#51603.
Mostly fix metadata_only backend and extract some code out of rustc_codegen_llvm
Removes dependency on the `ar` crate and removes the `llvm.enabled` config option in favour of setting `rust.codegen-backends` to `[]`.
When doing linker-plugin based LTO, write LLVM bitcode obj-files instead of embedding the bitcode into the regular object file.
This PR makes the compiler emit LLVM bitcode object files instead of regular object files with the IR embed when compiling for linker-plugin-based LTO. The reasoning for switching the strategy is this:
- Embedding bitcode in a section of the object file actually makes us save bitcode twice in rlibs and Rust dylibs, once for linker-based LTO and once for rustc-based LTO. That's a waste of space.
- When compiling for plugin-based LTO, one usually has no use for the machine code also present in the object file. Generating it is a waste of time.
- When compiling for plugin-based LTO, `rustc` will skip running ThinLTO because the linker will do that anyway. This has the side effect of then generating poorly optimized machine code, which makes it even less useful (and may lead to users not knowing why their code is slow instead of getting an error).
- Not having machine code available makes it impossible for the linker to silently fall back to not inlining stuff across language boundaries.
- This is what Clang does and according to [the documentation](https://llvm.org/docs/BitCodeFormat.html#native-object-file-wrapper-format) is the better supported option.
- The current behavior (minus the runtime performance problems) is still available via `-Z embed-bitcode` (we might want to do this for `libstd` at some point).
r? @alexcrichton
NLL Liveness: Skip regionless types when visiting free regions
The tuple-stress benchmark exercises the liveness constraint generation code for types which do not have regions
Closes#52027
ARM: expose the "mclass" target feature
This let us differentiate, in conditional compilation context, between ARM Cortex-M targets, like
the `thumbv*` targets, and other ARM targets, like the ARM Cortex-A Linux targets.
r? @alexcrichton
cc @gnzlbg
cc rust-lang-nursery/stdsimd#437
Deprecate `std::env::home_dir` and fix incorrect documentation
Compare `std::env::home_dir`s claim:
> Returns the value of the 'HOME' environment variable if it is set and not equal to the empty string.
... with its actual behavior:
```
std::env::set_var("HOME", "");
println!("{:?}", std::env::var_os("HOME")); // Some("")
println!("{:?}", std::env::home_dir()); // Some("")
```
The implementation is incorrect in two cases:
- `$HOME` is set, but empty.
- An entry for the user exists in `/etc/passwd`, but it's `pw_dir` is empty.
In both cases Rust considers an empty string to be a valid home directory. This contradicts the documentation, and is wrong in general.
