`FileSearch::search()` traverses one or more directories. For each
directory it generates a `Vec<PathBuf>` containing one element per file
in that directory.
In some benchmarks this occurs enough that the allocations done for the
`PathBuf`s are significant, and in practice a small number of
directories are being traversed over and over again. For example, when
compiling the `tokio-webpush-simple` benchmark, two directories are
traversed 58 times each. Each of these directories have more than 100
files.
This commit changes things so that all the `Vec<PathBuf>`s that will be
needed by a `Session` are precomputed when that `Session` is created;
they are stored in `SearchPath`. `FileSearch` gets a reference to the
necessary `SearchPath`s. This reduces instruction counts on several
benchmarks by 1--5%.
The commit also removes the barely-used `visited_dirs` hash in
`for_each_lib_searchPath`. It only detects if `tlib_path` is the same as
one of the previously seen paths, which is unlikely.
Instead of maybe storing its own sysroot and maybe deferring to the one
in `Session::opts`, just clone the latter when necessary so one is
always directly available. This removes the need for the getter.
This commit cleans up allocator injection logic found in the compiler
around selecting the global allocator. It turns out that now that
jemalloc is gone the compiler never actually injects anything! This
means that basically everything around loading crates here and there can
be easily pruned.
This also removes the `exe_allocation_crate` option from custom target
specs as it's no longer used by the compiler anywhere.
resolve: Filter away macro prelude in modules with `#[no_implicit_prelude]` on 2018 edition
This is a tiny thing.
For historical reasons macro prelude (macros from `#[macro_use] extern crate ...`, including `extern crate std`) is still available in modules with `#[no_implicit_prelude]`.
This PR provides proper isolation and removes those names from scope.
`#[no_implicit_prelude]` modules still have built-in types (`u8`), built-in attributes (`#[inline]`) and built-in macros (`env!("PATH")`) in scope. We can introduce some `#[no_implicit_prelude_at_all]` to remove those as well, but that's a separate issue.
The change is done only on 2018 edition for backward compatibility.
I'm pretty sure this can be done on 2015 as well because `#[no_implicit_prelude]` is rarely used, but I don't want to go through the crater/deprecation process right now, maybe later.
cc https://github.com/rust-lang/rust/issues/53977
r? @ghost
Rustbuild passes `--message-format json` to the compiler invocations
which causes JSON to be emitted on stdout. Printing optimization fuel
messages to stdout breaks the json and causes Rustbuild to fail.
Work around this by emitting optimization fuel related messages on
stderr instead.
Improve verify_llvm_ir config option
LLVM IR verification has been disabled by default in #51230. However, the implementation doesn't quite match what was discussed in the discussion. This patch implements two changes:
* Make `verify_llvm_ir` influence the behavior of the compiled rustc binary, rather than just the rustc build system. That is, if `verify_llvm_ir=true`, even manual invocations of the built rustc will verify LLVM IR.
* Enable verification of LLVM IR in CI, for non-deploy and deploy-alt builds. This is similar to how LLVM assertions are handled.
resolve: Scale back hard-coded extern prelude additions on 2015 edition
https://github.com/rust-lang/rust/pull/54404 stabilized `feature(extern_prelude)` on 2015 edition, including the hard-coded parts not passed with `--extern`.
First of all, I'd want to confirm that this is intended stabilization, rather than a part of the "extended beta" scheme that's going to be reverted before releasing stable.
(EDIT: to clarify - this is a question, I'm \*asking\* for confirmation, rather than give it.)
Second, on 2015 edition extern prelude is not so fundamentally tied to imports and is a mere convenience, so this PR scales them back to the uncontroversial subset.
The "uncontroversial subset" means that if libcore is injected it brings `core` into prelude, if libstd is injected it brings `std` and `core` into prelude.
On 2015 edition this can be implemented through the library prelude (rather than hard-coding in the compiler) right now, I'll do it in a follow-up PR.
UPDATE: The change is done for both 2015 and 2018 editions now as discussed below.
Closes https://github.com/rust-lang/rust/issues/53166
* Make it influence the behavior of the compiled rustc, rather than
just the rustc build system. That is, if verify_llvm_ir=true,
even manual invocations of the built rustc will verify LLVM IR.
* Enable verification of LLVM IR in CI, for non-deploy and
deploy-alt builds. This is similar to how LLVM assertions are
handled.
Disable the PLT where possible to improve performance
for indirect calls into shared libraries.
This optimization is enabled by default where possible.
- Add the `NonLazyBind` attribute to `rustllvm`:
This attribute informs LLVM to skip PLT calls in codegen.
- Disable PLT unconditionally:
Apply the `NonLazyBind` attribute on every function.
- Only enable no-plt when full relro is enabled:
Ensures we only enable it when we have linker support.
- Add `-Z plt` as a compiler option
Avoid hardcoding and special-casing the `std` crate name in the item
path logic by moving the prelude crate name logic into the `Session`
type so it can be reused in the item path logic and resolve module.
Don't lint non-extern-prelude extern crate's in Rust 2018.
Fixes#54381 by silencing the lint telling users to remove `extern crate` when `use` doesn't work.
r? @alexcrichton cc @petrochenkov @nikomatsakis @Centril
This seemed like a good way to kick the tires on the
elided-lifetimes-in-paths lint (#52069)—seems to work! This was also
pretty tedious—it sure would be nice if `cargo fix` worked on this
codebase (#53896)!
incr.comp.: Allow for more fine-grained testing of CGU reuse and use it to test incremental ThinLTO.
This adds some tests specifically targeted at incremental ThinLTO, plus the infrastructure for tracking the kind of cache hit/miss we had for a given CGU. @alexcrichton, let me know if you can think of any more tests to add. ThinLTO works rather reliably for small functions, so we should be able to test it in a robust way.
I think after this lands it might time for a "Help us test incremental ThinLTO" post on irlo.
r? @alexcrichton
Remove usages of span_suggestion without Applicability
Use `Applicability::Unspecified` for all of them instead.
Shall deprecations for the non-`_with_applicability` functions be added?
Shall clippy be addressed somehow?
r? @estebank
This is mainly intended for `rustc` developers who want to see a
diagnostic in its original context in the control flow. Two uses
cases for that are:
* `-Z treat-err-as-bug` which then allows extraction of a stack-trace to the origin of the error
(a case that is so important that we make that flag imply this one, effectively).
* `RUST_LOG=... rustc`, in which case it is often useful to see the logging statements that
occurred immediately prior to the point where the diagnostic was signalled.
Drive-by: Added some documentation pointing future devs at
HandlerFlags, and documented the fields of `HandlerFlags` itself.
Allow for opting out of ThinLTO and clean up LTO related cli flag handling.
It turns out that there currently is no way to explicitly disable ThinLTO (except for the nightly-only `-Zthinlto` flag). This PR extends `-C lto` to take `yes` and `no` in addition to `thin` and `fat`. It should be backwards compatible.
It also cleans up how LTO mode selection is handled.
Note that merging the PR in the current state would make the new values for `-C lto` available on the stable channel. I think that would be fine but maybe some team should vote on it.
Use FxHash{Map,Set} instead of the default Hash{Map,Set} everywhere in rustc.
Most of the compiler uses the `Fx` hasher but some places ended up with the default one.
This fixes a regression from #53031 where specifying `-C target-cpu=native` is
printing a lot of warnings from LLVM about `native` being an unknown CPU. It
turns out that `native` is indeed an unknown CPU and we have to perform a
mapping to an actual CPU name, but this mapping is only performed in one
location rather than all locations we inform LLVM about the target CPU.
This commit centralizes the mapping of `native` to LLVM's value of the native
CPU, ensuring that all locations we inform LLVM about the `target-cpu` it's
never `native`.
Closes#53322
try to infer linker flavor from linker name and vice versa
This is a second take on PR #50359 that implements the logic proposed in https://github.com/rust-lang/rust/pull/50359#pullrequestreview-116663121
With this change it would become possible to link `thumb*` binaries using GNU's LD on stable as `-C linker=arm-none-eabi-ld` would be enough to change both the linker and the linker flavor from their default values of `arm-none-eabi-gcc` and `gcc`.
To link `thumb*` binaries using rustc's LLD on stable `-Z linker-flavor` would need to be stabilized as `-C linker=rust-lld -Z linker-flavor=ld.lld` are both required to change the linker and the linker flavor, but this PR doesn't propose that. We would probably need some sort of stability guarantee around `rust-lld`'s name and availability to make linking with rustc's LLD truly stable.
With this change it would also be possible to link `thumb*` binaries using a system installed LLD on stable using the `-C linker=ld.lld` flag (provided that `ld.lld` is a symlink to the system installed LLD).
r? @alexcrichton
