about summary refs log tree commit diff
path: root/compiler/rustc_driver/src
AgeCommit message (Collapse)AuthorLines
2021-01-13Rollup merge of #80859 - jsgf:fix-pretty-remap, r=davidtwcoDylan DPC-2/+9
Fix --pretty=expanded with --remap-path-prefix Per https://github.com/rust-lang/rust/issues/80832, using --pretty=expanded and --remap-path-prefix results in an ICE. This is becasue the session source files table is stored in remapped form, whereas --pretty-expanded looks up unremapped files. This remaps the path prefixes before lookup. ~~There don't appear to be any existing tests for --pretty=expanded; I'll look into adding some.~~ Never mind, found the pretty tests. Fixes #80832
2021-01-11driver: Use `atty` instead of rolling our ownCamelid-33/+2
Rationale: - `atty` is widely used in the Rust ecosystem - We already use it (in `rustc_errors` and other places) - We shouldn't be rolling our own TTY detector when there's a widely-used, well-tested package that we can use
2021-01-10log-color: Detect TTY based on stderr, not stdoutCamelid-2/+21
Logging goes to stderr, not stdout, so we should base our automated detection on stderr instead of stdout. Thanks to Ralf Jung for noticing and reporting the bug!
2021-01-09Fix --pretty=expanded with --remap-path-prefixJeremy Fitzhardinge-2/+9
Per https://github.com/rust-lang/rust/issues/80832, using --pretty=expanded and --remap-path-prefix results in an ICE. This is becasue the session source files table is stored in remapped form, whereas --pretty-expanded looks up unremapped files. This remaps the path prefixes before lookup.
2020-12-30where possible, pass slices instead of &Vec or &String (clippy::ptr_arg)Matthias Krüger-1/+1
2020-12-01Fix `unknown-crate` when using self-profile with rustdocJoshua Nelson-2/+0
... 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-26Auto merge of #77671 - flip1995:lint_list_always_plugins, r=oli-obk,Manishearthbors-6/+10
Always print lints from plugins, if they're available Currently you can get a list of lints and lint groups by running `rustc -Whelp`. This prints an additional line at the end: ``` Compiler plugins can provide additional lints and lint groups. To see a listing of these, re-run `rustc -W help` with a crate filename. ``` Clippy is such a "compiler plugin", that provides additional lints. Running `clippy-driver -Whelp` (`rustc` wrapper) still only prints the rustc lints with the above message at the end. But when running `clippy-driver -Whelp main.rs`, where `main.rs` is any rust file, it also prints Clippy lints. I don't think this is a good approach from a UX perspective: Why is a random file necessary to print a help message? This PR changes this behavior: Whenever a compiler callback registers lints, it is assumed that these lints come from a plugin and are printed without having to specify a Rust source file. Fixes rust-lang/rust-clippy#6122 cc `@Manishearth` `@ebroto` for the Clippy changes.
2020-11-25Reword message at the end of the output if not run with a lint toolflip1995-1/+1
2020-11-24Auto merge of #78548 - camelid:driver-tty, r=oli-obkbors-2/+21
driver: Only output ANSI logging if connected to a terminal Fixes #78435. See #78435 for more. Cc `@RalfJung` `@oli-obk`
2020-11-24Cleanup message at the end of the lint list outputflip1995-4/+1
2020-11-24Always print lints from plugins, if they're availableflip1995-2/+9
Currently you can get a list of lints and lint groups by running `rustc -Whelp`. This prints an additional line at the end: ``` Compiler plugins can provide additional lints and lint groups. To see a listing of these, re-run `rustc -W help` with a crate filename. ``` Clippy is such a "compiler plugin", that provides additional lints. Running `clippy-driver -Whelp` (`rustc` wrapper) still only prints the rustc lints with the above message at the end. But when running `clippy-driver -Whelp main.rs`, where `main.rs` is any rust file, it also prints Clippy lints. I don't think this is a good approach from a UX perspective: Why is a random file necessary to print a help message? This commit changes this behavior: Whenever a compiler callback registers lints, it is assumed that these lints come from a plugin and are printed without having to specify a Rust source file.
2020-11-23Use `early_error`Camelid-5/+12
2020-11-20Direct RUSTC_LOG (tracing/log) output to stderr instead of stdout.Eduard-Mihai Burtescu-0/+1
2020-11-15Rollup merge of #79005 - petrochenkov:noinjected, r=davidtwcoJonas Schievink-2/+0
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-10/+11
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-15Rollup merge of #79013 - jryans:cleanup-use-once-pretty-comment, ↵Dylan DPC-3/+0
r=Mark-Simulacrum Clean up outdated `use_once_payload` pretty printer comment While reading some parts of the pretty printer code, I noticed this old comment which seemed out of place. The `use_once_payload` this outdated comment mentions was removed in 2017 in 40f03a1e0d6702add1922f82d716d5b2c23a59f0, so this completes the work by removing the comment.
2020-11-13Clean up outdated `use_once_payload` pretty printer commentJ. Ryan Stinnett-3/+0
While reading some parts of the pretty printer code, I noticed this old comment which seemed out of place. The `use_once_payload` this outdated comment mentions was removed in 2017 in 40f03a1e0d6702add1922f82d716d5b2c23a59f0, so this completes the work by removing the comment.
2020-11-13cleanup: Remove `ParseSess::injected_crate_name`Vadim Petrochenkov-2/+0
2020-11-11Enable thread names in debug logging only for `parallel_compiler`Joshua Nelson-0/+2
2020-11-10Don't print thread ids and names in `tracing` logsJoshua Nelson-2/+0
Before: ``` 2:rustc INFO rustc_interface::passes Pre-codegen 2:rustcTy interner total ty lt ct all 2:rustc Adt : 1078 81.3%, 0.0% 0.0% 0.0% 0.0% 2:rustc Array : 1 0.1%, 0.0% 0.0% 0.0% 0.0% 2:rustc Slice : 1 0.1%, 0.0% 0.0% 0.0% 0.0% 2:rustc RawPtr : 2 0.2%, 0.0% 0.0% 0.0% 0.0% 2:rustc Ref : 4 0.3%, 0.1% 0.1% 0.0% 0.0% 2:rustc FnDef : 0 0.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc FnPtr : 76 5.7%, 0.0% 0.0% 0.0% 0.0% 2:rustc Placeholder : 0 0.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc Generator : 0 0.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc GeneratorWitness : 0 0.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc Dynamic : 3 0.2%, 0.0% 0.0% 0.0% 0.0% 2:rustc Closure : 0 0.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc Tuple : 13 1.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc Bound : 0 0.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc Param : 146 11.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc Infer : 2 0.2%, 0.1% 0.0% 0.0% 0.0% 2:rustc Projection : 0 0.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc Opaque : 0 0.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc Foreign : 0 0.0%, 0.0% 0.0% 0.0% 0.0% 2:rustc total 1326 0.2% 0.1% 0.0% 0.0% 2:rustcInternalSubsts interner: #437 2:rustcRegion interner: #355 2:rustcStability interner: #1 2:rustcConst Stability interner: #0 2:rustcAllocation interner: #0 2:rustcLayout interner: #0 ``` After: ``` INFO rustc_interface::passes Post-codegen Ty interner total ty lt ct all Adt : 1078 81.3%, 0.0% 0.0% 0.0% 0.0% Array : 1 0.1%, 0.0% 0.0% 0.0% 0.0% Slice : 1 0.1%, 0.0% 0.0% 0.0% 0.0% RawPtr : 2 0.2%, 0.0% 0.0% 0.0% 0.0% Ref : 4 0.3%, 0.1% 0.1% 0.0% 0.0% FnDef : 0 0.0%, 0.0% 0.0% 0.0% 0.0% FnPtr : 76 5.7%, 0.0% 0.0% 0.0% 0.0% Placeholder : 0 0.0%, 0.0% 0.0% 0.0% 0.0% Generator : 0 0.0%, 0.0% 0.0% 0.0% 0.0% GeneratorWitness : 0 0.0%, 0.0% 0.0% 0.0% 0.0% Dynamic : 3 0.2%, 0.0% 0.0% 0.0% 0.0% Closure : 0 0.0%, 0.0% 0.0% 0.0% 0.0% Tuple : 13 1.0%, 0.0% 0.0% 0.0% 0.0% Bound : 0 0.0%, 0.0% 0.0% 0.0% 0.0% Param : 146 11.0%, 0.0% 0.0% 0.0% 0.0% Infer : 2 0.2%, 0.1% 0.0% 0.0% 0.0% Projection : 0 0.0%, 0.0% 0.0% 0.0% 0.0% Opaque : 0 0.0%, 0.0% 0.0% 0.0% 0.0% Foreign : 0 0.0%, 0.0% 0.0% 0.0% 0.0% total 1326 0.2% 0.1% 0.0% 0.0% InternalSubsts interner: #437 Region interner: #355 Stability interner: #1 Const Stability interner: #0 Allocation interner: #0 Layout interner: #0 ```
2020-11-07Allow making `RUSTC_BOOTSTRAP` conditional on the crate nameJoshua Nelson-10/+11
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-10-30driver: Add env var to control log colorsCamelid-1/+13
The log color variable is whatever the log variable is (`RUSTC_LOG`, `RUSTDOC_LOG`, `MIRI_LOG`, etc.) + `_COLOR`. So `RUSTC_LOG_COLOR`, `RUSTDOC_LOG_COLOR`, `MIRI_LOG_COLOR`, etc. Thanks to @RalfJung for suggesting this! It was much easier to implement than adding a new unstable argument, which is what I tried before.
2020-10-30Fix even more clippy warningsJoshua Nelson-1/+1
2020-10-29driver: Only output ANSI if connected to a terminalCamelid-1/+1
See #78435 for more.
2020-10-26Auto merge of #77975 - bjorn3:cg_clif_subtree3, r=Mark-Simulacrumbors-23/+12
Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`
2020-10-26Add support for using cg_clif to bootstrap rustcbjorn3-23/+12
2020-10-16Rollup merge of #77493 - ↵Dylan DPC-3/+3
hosseind88:ICEs_should_always_print_the_top_of_the_query_stack, r=oli-obk ICEs should always print the top of the query stack see #76920
2020-10-15Replace target.target with target and target.ptr_width with target.pointer_widthest31-2/+2
Preparation for a subsequent change that replaces rustc_target::config::Config with its wrapped Target. On its own, this commit breaks the build. I don't like making build-breaking commits, but in this instance I believe that it makes review easier, as the "real" changes of this PR can be seen much more easily. Result of running: find compiler/ -type f -exec sed -i -e 's/target\.target\([)\.,; ]\)/target\1/g' {} \; find compiler/ -type f -exec sed -i -e 's/target\.target$/target/g' {} \; find compiler/ -type f -exec sed -i -e 's/target.ptr_width/target.pointer_width/g' {} \; ./x.py fmt
2020-10-14Rollup merge of #77795 - bjorn3:codegen_backend_interface_refactor, r=oli-obkDylan DPC-1/+1
Codegen backend interface refactor This moves several things away from the codegen backend to rustc_interface. There are a few behavioral changes where previously the incremental cache (incorrectly) wouldn't get finalized, but now it does. See the individual commit messages.
2020-10-11Auto merge of #77649 - dash2507:replace_run_compiler, r=matthewjasperbors-2/+45
Replace run_compiler with RunCompiler builder pattern Fixes #77286. Replaces rustc_driver:run_compiler with RunCompiler builder pattern.
2020-10-10Use fixed type for CodegenResultsbjorn3-1/+1
This also moves the -Zno-link implementation to rustc_interface
2020-10-10Auto merge of #77580 - petrochenkov:norestarg, r=matthewjasperbors-1/+2
rustc_target: Refactor away `TargetResult` Follow-up to https://github.com/rust-lang/rust/pull/77202. Construction of a built-in target is always infallible now, so `TargetResult` is no longer necessary. The second commit contains some further cleanup based on built-in target construction being infallible.
2020-10-09rebase with masterhosseind75-1/+3
2020-10-09run full query stack print just when RUST_BACKTRACE is sethosseind75-1/+4
2020-10-09ICEs should print the top of the query stackhosseind75-6/+1
2020-10-08Replace run_compiler with RunCompiler builder pattern.Darshan Kathiriya-2/+45
RunCompiler::new takes non-optional params, and optional params can be set using set_*field_name* method. finally `run` will forward all fields to `run_compiler`.
2020-10-08Commit suggestionKazantcev Andrey-1/+1
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
2020-10-08Remove unnecessary lamda on emitter map.Kazantcev Andrey-2/+1
2020-10-05rustc_target: Further simplify loading of built-in targetsVadim Petrochenkov-1/+2
using the fact that it is infallible. JSON roundtrip check on every rustc run is also removed, it's already performed by unit tests.
2020-10-04Rollup merge of #75143 - oli-obk:tracing, r=RalfJungYuki Okushi-5/+15
Use `tracing` spans to trace the entire MIR interp stack r? @RalfJung While being very verbose, this allows really good tracking of what's going on. While I considered schemes like the previous indenter that we had (which we could get by using the `tracing-tree` crate), this will break down horribly with things like multithreaded rustc. Instead, we can now use `RUSTC_LOG` to restrict the things being traced. You could specify a filter in a way that only shows the logging of a specific frame. ![screenshot of command line output of the new formatting](https://user-images.githubusercontent.com/332036/89291343-aa40de00-d65a-11ea-9f6c-ea06c1806327.png) If we lower the span's level to `debug`, then in `info` level logging we'd not see the frames, but in `debug` level we would see them. The filtering rules in `tracing` are super powerful, but I'm not sure if we can specify a filter so we do see `debug` level events, but *not* the `frame` spans. The documentation at https://docs.rs/tracing-subscriber/0.2.10/tracing_subscriber/struct.EnvFilter.html makes me think that we can only turn on things, not turn off things at a more precise level. cc @hawkw
2020-09-28Use `tracing` spans to trace the entire MIR interp stackOliver Scherer-5/+15
2020-09-28Rollup merge of #76474 - bjorn3:driver_selected_codegen, r=oli-obkRalf Jung-1/+11
Add option to pass a custom codegen backend from a driver This allows the driver to pass information to the codegen backend. For example the headcrab debugger may in the future want to use cg_clif to JIT code to be injected in the debuggee. This would PR make it possible to tell cg_clif which symbol can be found at which address and to tell it to inject the JITed code into the right process. This PR may also help with https://github.com/rust-lang/miri/pull/1540 by allowing miri to provide a codegen backend that only emits metadata and doesn't perform any codegen. cc @nbaksalyar (headcrab) cc @RalfJung (miri)
2020-09-27Add option to pass a custom codegen backend from a driverbjorn3-1/+11
2020-09-23/nightly/nightly-rustcErik Hofmayer-1/+1
2020-09-23Updated html_root_url for compiler cratesErik Hofmayer-1/+1
2020-09-17use strip_prefix over starts_with and manual slicing based on pattern length ↵Matthias Krüger-2/+1
(clippy::manual_strip)
2020-09-03Auto merge of #73996 - da-x:short-unique-paths, r=petrochenkovbors-1/+2
diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310, and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed, and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions, it's rather simple logic, and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path to the last component. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable from anywhere.
2020-09-03rustc_driver: have TrimmedDefPaths::GoodPath only for rustcDan Aloni-4/+2
`run_compiler` is used by clippy and other tools, which should not have the trimmed paths feature enabled by default, until we see it works well for them. Would also be nice to rename `TimePassesCallbacks` however it's a submodule change.
2020-09-02pretty: trim paths of unique symbolsDan Aloni-2/+5
If a symbol name can only be imported from one place for a type, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path and print only the name. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable anywhere. This adds a new '-Z trim-diagnostic-paths=false' option to control this feature. On the good path, with no diagnosis printed, we should try to avoid issuing this query, so we need to prevent trimmed_def_paths query on several cases. This change also relies on a previous commit that differentiates between `Debug` and `Display` on various rustc types, where the latter is trimmed and presented to the user and the former is not.
2020-09-01driver: replace `lazy_static` by `SyncLazy` from stdmarmeladema-7/+5
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2025-11-21 00:37:40 +0000