| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Replace push loops with extend() where possible
Or set the vector capacity where I couldn't do it.
According to my [simple benchmark](https://gist.github.com/ljedrz/568e97621b749849684c1da71c27dceb) `extend`ing a vector can be over **10 times** faster than `push`ing to it in a loop:
10 elements (6.1 times faster):
```
test bench_extension ... bench: 75 ns/iter (+/- 23)
test bench_push_loop ... bench: 458 ns/iter (+/- 142)
```
100 elements (11.12 times faster):
```
test bench_extension ... bench: 87 ns/iter (+/- 26)
test bench_push_loop ... bench: 968 ns/iter (+/- 3,528)
```
1000 elements (11.04 times faster):
```
test bench_extension ... bench: 311 ns/iter (+/- 9)
test bench_push_loop ... bench: 3,436 ns/iter (+/- 233)
```
Seems like a good idea to use `extend` as much as possible.
|
|
|
|
Prefer to_string() to format!()
Simple benchmarks suggest in some cases it can be faster by even 37%:
```
test converting_f64_long ... bench: 339 ns/iter (+/- 199)
test converting_f64_short ... bench: 136 ns/iter (+/- 34)
test converting_i32_long ... bench: 87 ns/iter (+/- 16)
test converting_i32_short ... bench: 87 ns/iter (+/- 49)
test converting_str ... bench: 54 ns/iter (+/- 15)
test formatting_f64_long ... bench: 349 ns/iter (+/- 176)
test formatting_f64_short ... bench: 145 ns/iter (+/- 14)
test formatting_i32_long ... bench: 98 ns/iter (+/- 14)
test formatting_i32_short ... bench: 93 ns/iter (+/- 15)
test formatting_str ... bench: 86 ns/iter (+/- 23)
```
|
|
Add the -Zcrate-attr=foo unstable rustc option
This PR adds a new unstable option to `rustc`: `-Zcrate-attr=foo`. The option can be used to inject crate-level attributes from the CLI, and it's meant to be used by tools like Crater that needs to add their own attributes to a crate without changing the source code.
The exact reason I need this is to implement "edition runs" in Crater: we need to add the preview feature flag to every crate, and editing the crates' source code on the fly might produce unexpected results, while a compiler flag is more reliable.
cc https://github.com/rust-lang-nursery/crater/issues/282 @Mark-Simulacrum
|
|
Remove unused "-Zenable_nonzeroing_move_hints" flag
Removing a dead option which seems to be a remnant of the old drop-flag system.
|
|
|
|
|
|
Add `-Z borrowck=migrate`
This adds `-Z borrowck=migrate`, which represents the way we want to migrate to NLL under Rust versions to come. It also hooks this new mode into `--edition 2018`, which means we're officially turning NLL on in the 2018 edition.
The basic idea of `-Z borrowck=migrate` that there are cases where NLL is fixing old soundness bugs in the borrow-checker, but in order to avoid just breaking code by immediately rejecting the programs that hit those soundness bugs, we instead use the following strategy:
If your code is accepted by NLL, then we accept it.
If your code is rejected by both NLL and the old AST-borrowck, then we reject it.
If your code is rejected by NLL but accepted by the old AST-borrowck, then we emit the new NLL errors as **warnings**.
These warnings will be turned into hard errors in the future, and they say so in these diagnostics.
Fix #46908
|
|
|
|
|
|
|
|
|
|
Even if that is just happening because of `abort_if_errors`
|
|
This reverts commit 2c5cd9ce53d2d25041db0cb02b40ba460ffa8908.
|
|
|
|
Disable LLVM verification by default
Currently -Z no-verify only controls IR verification prior to LLVM codegen, while verification is performed unconditionally both before and after linking with (Thin)LTO.
Also wondering what the sentiment is on disabling verification by default (and e.g. only enabling it on ALT builds with assertions). This does not seem terribly useful outside of rustc development and it does seem to show up in profiles (at something like 3%).
**EDIT:** A table showing the various configurations and what is enabled when.
| Configuration | Dynamic verification performed | LLVM static assertions compiled in |
| --- | --- | --- |
| alt builds | | yes |
| nightly builds | | no |
| stable builds | | no |
| CI builds | | |
| dev builds in a checkout | | |
|
|
Fix rustdoc run failures by shutting down definitely some lints
Fixes #51661.
cc @oli-obk @arielb1 @eddyb
|
|
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
|
|
fix typo in stable `--edition` error message
(diff is self-explanatory)
|
|
|
|
instead of embedding the bitcode into the regular object file.
|
|
enable Atomic*.{load,store} for ARMv6-M / MSP430
closes #45085
as proposed in https://github.com/rust-lang/rust/issues/45085#issuecomment-384825434
this commit adds an `atomic_cas` target option and extends the `#[cfg(target_has_atomic)]`
attribute to enable a subset of the `Atomic*` API on architectures that don't support atomic CAS
natively, like MSP430 and ARMv6-M.
r? @alexcrichton
|
|
rustc: Update tracking issue for wasm_import_module
It's now https://github.com/rust-lang/rust/issues/52090
|
|
|
|
[cross-lang-lto] Allow the linker to choose the LTO-plugin (which is useful when using LLD)
This PR allows for not specifying an LTO-linker plugin but still let `rustc` invoke the linker with the correct plugin arguments. This is useful when using LLD which does not need the `-plugin` argument. Since LLD is the best linker for this scenario anyway, this change should improve ergonomics quite a bit.
r? @alexcrichton
|
|
Add command line lint manipulation in rustdoc
Fixes #50082.
r? @QuietMisdreavus
|
|
|
|
closes #45085
this commit adds an `atomic_cas` target option and an unstable `#[cfg(target_has_atomic_cas)]`
attribute to enable a subset of the `Atomic*` API on architectures that don't support atomic CAS
natively, like MSP430 and ARMv6-M.
|
|
|
|
|
|
|
|
|
|
This disables IR verification by default.
|
|
|
|
Rebase of #50783 has accidentally revived the flag (which should be
renamed to `-Z codegen-time-graph` by #50615).
|
|
|
|
|
|
Also, turn on ReadForMatch emission by default (when using NLL).
|
|
Now, if you pass `-Z disable-ast-check-for-mutation-in-guard`, then we
will just allow you to mutably-borrow and assign in guards of `match`
arms.
This is wildly unsound with AST-borrowck. It is also unsound with
MIR-borrowck without further adjustments, which come in later in the
commit series on this Pull Request.
See also rust-lang/rust#24535 and rust-lang/rfcs#1006.
|
|
|
|
Codegen issues commonly only manifest under specific circumstances,
e.g. if multiple codegen units are used and ThinLTO is enabled.
However, these configuration are threaded, making the use of LLVM
debugging facilities hard, as output is interleaved.
This patch adds a -Z no-parallel-llvm flag, which allows disabling
parallelization of codegen and linking, while otherwise preserving
behavior with regard to codegen units and LTO.
|
|
|
|
stabilize opt-level={s,z}
closes #35784
closes #47651
### Rationale
Since the lastest LLVM upgrade rustc / LLVM does more agressive loop unrolling. This results in increased binary size of embedded / no_std programs: a hundreds of bytes increase, or about a 7x increase, in the case of the smallest Cortex-M binary cf. #49260.
As we are shooting for embedded Rust on stable it would be great to also provide a way to optimize for size (which is pretty important for embedded applications that target resource constrained devices) on stable.
Also this has been baking in nightly for a long time.
r? @alexcrichton which team has to sign off this?
|
|
This used to be disabled due to LLVM bugs in the handling of
noalias information in conjunction with unwinding. However,
according to #31681 all known LLVM bugs have been fixed by
LLVM 6.0, so it's probably time to reenable this optimization.
Noalias annotations will not be emitted by default if either
-C panic=abort (as previously) or LLVM >= 6.0 (new).
-Z mutable-noalias=no is left as an escape-hatch to allow
debugging problems suspected to stem from this change.
|
|
|
|
|
|
|
|
|
|
Add some groundwork for cross-language LTO.
Implements part of #49879:
- Adds a `-Z cross-lang-lto` flag to rustc
- Makes sure that bitcode is embedded in object files if the flag is set.
This should already allow for using cross language LTO for staticlibs (where one has to invoke the linker manually anyway). However, `rustc` will not try to enable LTO for its own linker invocations yet.
r? @alexcrichton
|
