summary refs log tree commit diff
path: root/compiler/rustc_session/src
AgeCommit message (Collapse)AuthorLines
2020-12-22Revert "Promote missing_fragment_specifier to hard error"Wesley Wiser-0/+2
This reverts commit 02eae432e7476a0686633a8c2b7cb1d5aab1bd2c.
2020-12-17Rollup merge of #80073 - kulikjak:add-target-alias-support, r=varkorYuki Okushi-1/+1
Add support for target aliases Closes #68214, see that for more info. `@varkor`
2020-12-16cg_llvm: split dwarf filename and comp dirDavid Wood-1/+12
llvm-dwp concatenates `DW_AT_comp_dir` with `DW_AT_GNU_dwo_name` (only when `DW_AT_comp_dir` exists), which can result in it failing to find the DWARF object files. In earlier testing, `DW_AT_comp_dir` wasn't present in the final object and the current directory was the output directory. When running tests through compiletest, the working directory of the compilation is different from output directory and that resulted in `DW_AT_comp_dir` being in the object file (and set to the current working directory, rather than the output directory), and `DW_AT_GNU_dwo_name` being set to the full path (rather than just the filename), so llvm-dwp was failing. This commit changes the compilation directory provided to LLVM to match the output directory, where DWARF objects are output; and ensures that only the filename is used for `DW_AT_GNU_dwo_name`. Signed-off-by: David Wood <david@davidtw.co>
2020-12-16cg_llvm: implement split dwarf supportDavid Wood-1/+27
This commit implements Split DWARF support, wiring up the flag (added in earlier commits) to the modified FFI wrapper (also from earlier commits). Signed-off-by: David Wood <david@davidtw.co>
2020-12-16session: add `split-dwarf` flagDavid Wood-0/+36
This commit adds a flag for Split DWARF, which enables debuginfo to be split into multiple files. Signed-off-by: David Wood <david@davidtw.co>
2020-12-16Add support for target aliasesJakub Kulik-1/+1
2020-12-15Rollup merge of #79958 - richkadel:llvm-coverage-counters-2.2.0, r=tmandryGuillaume Gomez-7/+34
Fixes reported bugs in Rust Coverage Fixes: #79569 Fixes: #79566 Fixes: #79565 For the first issue (#79569), I got hit a `debug_assert!()` before encountering the reported error message (because I have `debug = true` enabled in my config.toml). The assertion showed me that some `SwitchInt`s can have more than one target pointing to the same `BasicBlock`. I had thought that was invalid, but since it seems to be possible, I'm allowing this now. I added a new test for this. ---- In the last two cases above, both tests (intentionally) fail to compile, but the `InstrumentCoverage` pass is invoked anyway. The MIR starts with an `Unreachable` `BasicBlock`, which I hadn't encountered before. (I had assumed the `InstrumentCoverage` pass would only be invoked with MIRs from successful compilations.) I don't have test infrastructure set up to test coverage on files that fail to compile, so I didn't add a new test. r? `@tmandry` FYI: `@wesleywiser`
2020-12-14Convenience funcs for `some_option.unwrap_or(...)`Rich Kadel-21/+14
This ensures consistent handling of default values for options that are None if not specified on the command line.
2020-12-14Improve warnings on incompatible options involving -Zinstrument-coverageRich Kadel-8/+42
Adds checks for: * `no_core` attribute * explicitly-enabled `legacy` symbol mangling * mir_opt_level > 1 (which enables inlining) I removed code from the `Inline` MIR pass that forcibly disabled inlining if `-Zinstrument-coverage` was set. The default `mir_opt_level` does not enable inlining anyway. But if the level is explicitly set and is greater than 1, I issue a warning. The new warnings show up in tests, which is much better for diagnosing potential option conflicts in these cases.
2020-12-11fix clippy::{needless_bool, manual_unwrap_or}Matthias Krüger-4/+1
2020-12-07Dogfood 'str_split_once() with `compiler/`Eric Arellano-62/+55
2020-12-03Combination of commitsRich Kadel-29/+2
Fixes multiple issue with counters, with simplification Includes a change to the implicit else span in ast_lowering, so coverage of the implicit else no longer spans the `then` block. Adds coverage for unused closures and async function bodies. Fixes: #78542 Adding unreachable regions for known MIR missing from coverage map Cleaned up PR commits, and removed link-dead-code requirement and tests Coverage no longer depends on Issue #76038 (`-C link-dead-code` is no longer needed or enforced, so MSVC can use the same tests as Linux and MacOS now) Restrict adding unreachable regions to covered files Improved the code that adds coverage for uncalled functions (with MIR but not-codegenned) to avoid generating coverage in files not already included in the files with covered functions. Resolved last known issue requiring --emit llvm-ir workaround Fixed bugs in how unreachable code spans were added.
2020-12-03Auto merge of #79586 - jyn514:crate-name, r=davidtwcobors-1/+1
Fix `unknown-crate` when using -Z self-profile with rustdoc ... by removing a duplicate `crate_name` field in `interface::Config`, making it clear that rustdoc should be passing it to `config::Options` instead. Unblocks https://github.com/rust-lang/rustc-perf/issues/797.
2020-12-01Rollup merge of #79508 - jryans:check-dsymutil-result, r=nagisaGuillaume Gomez-1/+1
Warn if `dsymutil` returns an error code This checks the error code returned by `dsymutil` and warns if it failed. It also provides the stdout and stderr logs from `dsymutil`, similar to the native linker step. I tried to think of ways to test this change, but so far I haven't found a good way, as you'd likely need to inject some nonsensical args into `dsymutil` to induce failure, which feels too artificial to me. Also, https://github.com/rust-lang/rust/issues/79361 suggests Rust is on the verge of disabling `dsymutil` by default, so perhaps it's okay for this change to be untested. In any case, I'm happy to add a test if someone sees a good approach. Fixes https://github.com/rust-lang/rust/issues/78770
2020-12-01Fix `unknown-crate` when using self-profile with rustdocJoshua Nelson-1/+1
... by removing a duplicate `crate_name` field in `interface::Config`, making it clear that rustdoc should be passing it to `config::Options` instead.
2020-11-29Add -Z normalize-docs and enable it for compiler docsJoshua Nelson-0/+2
2020-11-28Derive `Debug` for `DebugInfo`J. Ryan Stinnett-1/+1
This was useful during testing of `dsymutil` code paths.
2020-11-24TRACK '-Z polonius' flagCamelid-1/+1
2020-11-24Rollup merge of #79367 - Dirbaio:trap-unreachable, r=jonas-schievinkJonas Schievink-0/+2
Allow disabling TrapUnreachable via -Ztrap-unreachable=no Currently this is only possible by defining a custom target, which is quite unwieldy. This is useful for embedded targets where small code size is desired. For example, on my project (thumbv7em-none-eabi) this yields a 0.6% code size reduction: 132892 bytes -> 132122 bytes (770 bytes down).
2020-11-24Allow disabling TrapUnreachable via -Ztrap-unreachable=noDario Nieuwenhuis-0/+2
This is useful for embedded targets where small code size is desired. For example, on my project (thumbv7em-none-eabi) this yields a 0.6% code size reduction.
2020-11-23Allow using `-Z fewer-names=no` to retain value namesTomasz Miąsko-7/+10
Change `-Z fewer-names` into an optional boolean flag and allow using it to either discard value names when true or retain them when false, regardless of other settings.
2020-11-15Rollup merge of #79005 - petrochenkov:noinjected, r=davidtwcoJonas Schievink-3/+1
cleanup: Remove `ParseSess::injected_crate_name` Its only remaining use is in pretty-printing where the necessary information can be easily re-computed.
2020-11-15Rollup merge of #77802 - jyn514:bootstrap-specific, r=nikomatsakisJonas Schievink-9/+18
Allow making `RUSTC_BOOTSTRAP` conditional on the crate name Motivation: This came up in the [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Require.20users.20to.20confirm.20they.20know.20RUSTC_.E2.80.A6.20compiler-team.23350/near/208403962) for https://github.com/rust-lang/compiler-team/issues/350. See also https://github.com/rust-lang/cargo/pull/6608#issuecomment-458546258; this implements https://github.com/rust-lang/cargo/issues/6627. The goal is for this to eventually allow prohibiting setting `RUSTC_BOOTSTRAP` in build.rs (https://github.com/rust-lang/cargo/issues/7088). ## User-facing changes - `RUSTC_BOOTSTRAP=1` still works; there is no current plan to remove this. - Things like `RUSTC_BOOTSTRAP=0` no longer activate nightly features. In practice this shouldn't be a big deal, since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway. - `RUSTC_BOOTSTRAP=x` will enable nightly features only for crate `x`. - `RUSTC_BOOTSTRAP=x,y` will enable nightly features only for crates `x` and `y`. ## Implementation changes The main change is that `UnstableOptions::from_environment` now requires an (optional) crate name. If the crate name is unknown (`None`), then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name`, not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how. Other major changes: - Added `Session::is_nightly_build()`, which uses the `crate_name` of the session - Added `nightly_options::match_is_nightly_build`, a convenience method for looking up `--crate-name` from CLI arguments. `Session::is_nightly_build()`should be preferred where possible, since it will take into account `#![crate_name]` (I think). - Added `unstable_features` to `rustdoc::RenderOptions` I'm not sure whether this counts as T-compiler or T-lang; _technically_ RUSTC_BOOTSTRAP is an implementation detail, but it's been used so much it seems like this counts as a language change too. r? `@joshtriplett` cc `@Mark-Simulacrum` `@hsivonen`
2020-11-13cleanup: Remove `ParseSess::injected_crate_name`Vadim Petrochenkov-3/+1
2020-11-11Rollup merge of #78873 - tmiasko:inline-opts, r=oli-obkJonas Schievink-0/+4
Add flags customizing behaviour of MIR inlining * `-Zinline-mir-threshold` to change the default threshold. * `-Zinline-mir-hint-threshold` to change the threshold used by functions with inline hint. Having those as configurable flags makes it possible to experiment with with different inlining thresholds and substantially increase test coverage of MIR inlining when used with increased thresholds (for example, necessary to test #78844).
2020-11-10Changed unwrap_or to unwrap_or_else in some places.Nicholas-Baron-1/+1
The discussion seems to have resolved that this lint is a bit "noisy" in that applying it in all places would result in a reduction in readability. A few of the trivial functions (like `Path::new`) are fine to leave outside of closures. The general rule seems to be that anything that is obviously an allocation (`Box`, `Vec`, `vec![]`) should be in a closure, even if it is a 0-sized allocation.
2020-11-10Rollup merge of #78875 - petrochenkov:cleantarg, r=Mark-SimulacrumJonas Schievink-40/+35
rustc_target: Further cleanup use of target options Follow up to https://github.com/rust-lang/rust/pull/77729. Implements items 2 and 4 from the list in https://github.com/rust-lang/rust/pull/77729#issue-500228243. The first commit collapses uses of `target.options.foo` into `target.foo`. The second commit renames some target options to avoid tautology: `target.target_endian` -> `target.endian` `target.target_c_int_width` -> `target.c_int_width` `target.target_os` -> `target.os` `target.target_env` -> `target.env` `target.target_vendor` -> `target.vendor` `target.target_family` -> `target.os_family` `target.target_mcount` -> `target.mcount` r? `@Mark-Simulacrum`
2020-11-10Add flags customizing behaviour of MIR inliningTomasz Miąsko-0/+4
* `-Zinline-mir-threshold` to change the default threshold. * `-Zinline-mir-hint-threshold` to change the threshold used by functions with inline hint.
2020-11-09Add `#[cfg(panic = "...")]`David Hewitt-0/+3
2020-11-08rustc_target: Rename some target options to avoid tautologyVadim Petrochenkov-5/+5
`target.target_endian` -> `target.endian` `target.target_c_int_width` -> `target.c_int_width` `target.target_os` -> `target.os` `target.target_env` -> `target.env` `target.target_vendor` -> `target.vendor` `target.target_family` -> `target.os_family` `target.target_mcount` -> `target.mcount`
2020-11-08Collapse all uses of `target.options.foo` into `target.foo`Vadim Petrochenkov-36/+31
with an eye on merging `TargetOptions` into `Target`. `TargetOptions` as a separate structure is mostly an implementation detail of `Target` construction, all its fields logically belong to `Target` and available from `Target` through `Deref` impls.
2020-11-07Allow making `RUSTC_BOOTSTRAP` conditional on the crate nameJoshua Nelson-9/+18
The main change is that `UnstableOptions::from_environment` now requires an (optional) crate name. If the crate name is unknown (`None`), then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name`, not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how. Other major changes: - Added `Session::is_nightly_build()`, which uses the `crate_name` of the session - Added `nightly_options::match_is_nightly_build`, a convenience method for looking up `--crate-name` from CLI arguments. `Session::is_nightly_build()`should be preferred where possible, since it will take into account `#![crate_name]` (I think). - Added `unstable_features` to `rustdoc::RenderOptions` There is a user-facing change here: things like `RUSTC_BOOTSTRAP=0` no longer active nightly features. In practice this shouldn't be a big deal, since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway. - Add tests Check against `Cheat`, not whether nightly features are allowed. Nightly features are always allowed on the nightly channel. - Only call `is_nightly_build()` once within a function - Use booleans consistently for rustc_incremental Sessions can't be passed through threads, so `read_file` couldn't take a session. To be consistent, also take a boolean in `write_file_header`.
2020-11-05Responded to all feedback as of 2020-10-30Rich Kadel-2/+5
2020-11-03Rollup merge of #77950 - arlosi:sha256, r=eddybMara Bos-1/+1
Add support for SHA256 source file hashing Adds support for `-Z src-hash-algorithm sha256`, which became available in LLVM 11. Using an older version of LLVM will cause an error `invalid checksum kind` if the hash algorithm is set to sha256. r? `@eddyb` cc #70401 `@est31`
2020-11-02Auto merge of #78592 - fpoli:nll-facts-dir, r=matthewjasperbors-0/+2
Add option to customize the nll-facts' folder location This PR adds a `nll-facts-dir` option to specify the location of the directory in which NLL facts are dumped into. It works the same way `dump-mir-dir` controls the location used by the `dump-mir` option.
2020-11-02Auto merge of #78605 - nox:relax-elf-relocations, r=nagisabors-0/+2
Implement -Z relax-elf-relocations=yes|no This lets rustc users tweak whether the linker should relax ELF relocations without recompiling a whole new target with its own libcore etc.
2020-10-31Implement -Z relax-elf-relocations=yes|noAnthony Ramine-0/+2
This lets rustc users tweak whether the linker should relax ELF relocations, namely whether it should emit R_X86_64_GOTPCRELX relocations instead of R_X86_64_GOTPCREL, as the former is allowed by the ABI to be further optimised. The default value is whatever the target defines.
2020-10-30Some workAaron Hill-3/+3
2020-10-30Implement rustc side of report-future-incompatAaron Hill-3301/+56
2020-10-30Add option to customize the nll-facts' folder locationFederico Poli-0/+2
2020-10-30Fix even more clippy warningsJoshua Nelson-8/+3
2020-10-29Rollup merge of #78244 - workingjubilee:dogfood-fancy-ranges, r=varkorJonas Schievink-2/+2
Dogfood {exclusive,half-open} ranges in compiler (nfc) In particular, this allows us to write more explicit matches that avoid the pitfalls of using a fully general fall-through case, yet remain fairly ergonomic. Less logic is in guard cases, more is in the actual exhaustive case analysis. No functional changes.
2020-10-28Dogfood {exclusive,half-open} ranges in compiler (nfc)Jubilee Young-2/+2
In particular, this allows us to write more explicit matches that avoid the pitfalls of using a fully general fall-through case, yet remain fairly ergonomic. Less logic is in guard cases, more is in the actual exhaustive case analysis. No functional changes.
2020-10-28Auto merge of #78414 - nox:function-sections, r=nagisa,bjorn3bors-3/+5
Implement -Z function-sections=yes|no This lets rustc users tweak whether all functions should be put in their own TEXT section, using whatever default value the target defines if the flag is missing. I'm having fun experimenting with musl libc and trying to implement the start symbol in Rust, that means avoiding code that requires relocations, and AFAIK putting everything in its own section makes the toolchain generate `GOTPCREL` relocations for symbols that could use plain old PC-relative addressing (at least on `x86_64`) if they were all in the same section.
2020-10-27Added suggestion to `function_item_references` lint and fixed warning messageAyrton-1/+1
Also updated tests accordingly and tweaked some wording in the lint declaration.
2020-10-27Added documentation for `function_item_references` lintAyrton-0/+24
Added documentation for `function_item_references` lint to the rustc book and fixed comments in the lint checker itself.
2020-10-27Changed lint to check for `std::fmt::Pointer` and `transmute`Ayrton-2/+3
The lint checks arguments in calls to `transmute` or functions that have `Pointer` as a trait bound and displays a warning if the argument is a function reference. Also checks for `std::fmt::Pointer::fmt` to handle formatting macros although it doesn't depend on the exact expansion of the macro or formatting internals. `std::fmt::Pointer` and `std::fmt::Pointer::fmt` were also added as diagnostic items and symbols.
2020-10-27modified lint to work with MIRAyrton-0/+6
Working with MIR let's us exclude expressions like `&fn_name as &dyn Something` and `(&fn_name)()`. Also added ABI, unsafety and whether a function is variadic in the lint suggestion, included the `&` in the span of the lint and updated the test.
2020-10-26Implement -Z function-sections=yes|noAnthony Ramine-0/+2
This lets rustc users tweak whether all functions should be put in their own TEXT section, using whatever default value the target defines if the flag is missing.
2020-10-26Fix some outdated commentsAnthony Ramine-3/+3