| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Remove not used option
`mir_stats` has not been used since 2b32cb90c72d90c722d56324ca0ea9f748ebf4e1.
|
|
(compiler front-ends).
|
|
`mir_stats` has not been used since 2b32cb90c72d90c722d56324ca0ea9f748ebf4e1.
|
|
Fix self profiler ICE on Windows
Fixes #51648
|
|
Cleanup from lexical MIR borrowck removal
Lexical MIR borrowck was removed months ago now, and `EndRegion`s are no longer used for MIRI verification.
* Remove `rustc::mir::StatementKind::EndRegion` and the `-Zemit_end_regions` flag
* Use `RegionVid` instead of `Region` in BorrowSet
* Rewrite drop generation to create fewer goto terminators.
r? @nikomatsakis
|
|
rustc_target: separate out an individual alignment quantity type from Align.
Before this PR, `rustc_target::abi::Align` combined "power-of-two alignment quantity" semantics, with a distinction between ABI (required) and preferred alignment (by having two quantities).
After this PR, `Align` is only *one* such quantity, and a new `AbiAndPrefAlign` type is introduced to hold the pair of ABI and preferred `Align` quantities.
`Align` is used everywhere one quantity is necessary/sufficient, simplifying some of the code in codegen/miri, while `AbiAndPrefAlign` only in layout computation (to propagate preferred alignment).
r? @oli-obk cc @nagisa @RalfJung @nikomatsakis
|
|
Related to #51648
|
|
Fix error message for `-C panic=xxx`.
Fixes rust-lang/cargo#6334
|
|
|
|
|
|
|
|
|
|
|
|
Since lexical MIR borrow check is gone, and validation no longer uses
these, they can be removed.
|
|
fix various typos in doc comments
|
|
|
|
|
|
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
|
|
Clarify error message for -C opt-level
The new levels s and z are not mentioned as possible values.
|
|
-C remark: fix incorrect warning about requiring "--debuginfo" instead of "-C debuginfo=n"
Previously suggested "--debuginfo" does not actually work.
|
|
Don't print opt fuel messages to stdout because it breaks Rustbuild
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.
|
|
"-C debuginfo=n"
|
|
on 2018 edition
|
|
The new levels s and z are not mentioned as possible values.
|
|
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.
|
|
Also "rename" -Zmir-emit-validate to -Zmir-emit-retag, which is just a boolean (yes or no).
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit e90985acdec9928da9f6d157cfeb64f0ee98bffe.
|
|
* 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.
|
|
pnkfelix:issue-15287-kill-zflag-disabling-ast-check, r=alexcrichton
Remove `-Z disable_ast_check_for_mutation_in_guard`
One should use `#![feature(bind_by_move_pattern_guards)]` over `-Z disable_ast_check_for_mutation_in_guard`
cc #15287
|
|
rust: Add a `-C default-linker-libraries` option
This commit adds a new codegen option for the compiler which disables
rustc's passing of `-nodefaultlibs` by default on relevant platforms.
Sometimes Rust is linked with C code which fails to link with
`-nodefaultlibs` and is unnecessarily onerous to get linking correctly
with `-nodefaultlibs`.
An example of this is that when you compile C code with sanitizers and
then pass `-fsanitize=address` to the linker, it's incompatible with
`-nodefaultlibs` also being passed to the linker.
In these situations it's easiest to turn off Rust's default passing of
`-nodefaultlibs`, which was more ideological to start with than
anything! Preserving the default is somewhat important but having this
be opt-in shouldn't cause any breakage.
Closes #54237
|
|
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)!
|
|
This commit adds a new codegen option for the compiler which disables
rustc's passing of `-nodefaultlibs` by default on relevant platforms.
Sometimes Rust is linked with C code which fails to link with
`-nodefaultlibs` and is unnecessarily onerous to get linking correctly
with `-nodefaultlibs`.
An example of this is that when you compile C code with sanitizers and
then pass `-fsanitize=address` to the linker, it's incompatible with
`-nodefaultlibs` also being passed to the linker.
In these situations it's easiest to turn off Rust's default passing of
`-nodefaultlibs`, which was more ideological to start with than
anything! Preserving the default is somewhat important but having this
be opt-in shouldn't cause any breakage.
Closes #54237
|
|
|
|
disable_ast_check_for_mutation_in_guard`
|
|
|
|
|
|
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
|
