Add `Config::hash_untracked_state` callback
For context, I'm looking to use [late module passes](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/context/struct.LintStore.html#structfield.late_module_passes) in Clippy which unlike regular late passes run incrementally per module
However we have a config file which can change between runs, we need changes to that to invalidate the `lint_mod` query. This PR adds a side channel for us to hash some extra state into `Options` in order to do that
This does not make any changes to Clippy, I plan to do that in a PR to the Clippy repo along with some other required changes
An alternative implementation would be to add a new query to track this state and override the `lint_mod` query in Clippy to first call that
cc `@rust-lang/clippy`
`NoAnn` and `IdentifiedAnnotation` impl both `pprust_ast::PpAnn` and
`pprust_hir::PpAnn`, which is a bit confusing, because the optional
`tcx` is only needed for the HIR cases. (Currently the `tcx` is
unnecessarily provided in the `expanded` AST cases.)
This commit splits each one into `Ast` and `Hir` versions, which makes
things clear about where the `tcx` is needed. The commit also renames
all the traits so they consistently end with `Ann`.
`call_with_pp_support_ast` and `call_with_pp_support_hir` how each have
a single call site. This commit inlines and removes them, which also
removes the need for all the supporting traits: `Sess`,
`AstPrinterSupport`, and `HirPrinterSupport`. The `sess` member is also
removed from several structs.
The handling of the `PpMode` variants is currently spread across three
functions: `print_after_parsing`, `print_after_hir_lowering`, and
`print_with_analysis`. Each one handles some of the variants. This split
is primarily because `print_after_parsing` has slightly different
arguments to the other two.
This commit changes the structure. It merges the three functions into a
single `print` function, and encapsulates the different arguments in a
new enum `PrintExtra`.
Benefits:
- The code is a little shorter.
- All the `PpMode` variants are handled in a single `match`, with no
need for `unreachable!` arms.
- It enables the trait removal in the subsequent commit by reducing
the number of `call_with_pp_support_ast` call sites from two to one.
First, both `AstPrinterSupport` and `HirPrinterSupport` have a `sess`
method. This commit introduces a `Sess` trait and makes the support
traits be subtraits of `Sess`, to avoid some duplication.
Second, both support traits have a `pp_ann` method that isn't needed if
we enable `trait_upcasting`. This commit removes those methods.
(Both of these traits will be removed in a subsequent commit, as will
the `trait_upcasting` use.)
`phase_3_run_analysis_passes` no longer exists, and AFAICT this code has
been refactored so much since this comment was written that it no longer
has any useful meaning.
Use `std::path::PathBuf` rather than `String`; use `std::env::var_os`
rather than `std::env::var`. These changes avoid a number of error paths
which can arise in the presence of non-UTF-8 paths.
Don't modify libstd to dump rustc ICEs
Do a much simpler thing and just dump a `std::backtrace::Backtrace` to file.
r? `@estebank` `@oli-obk`
Fixes#115610
Make SIGSEGV handler emit nicer backtraces
This annotates the code heavily with comments to explain what is going on, for the benefit of other compiler contributors. The backtrace also emits appropriate comments to clarify, to a programmer who may not know why a bunch of file paths and hexadecimal blather was just dumped into stderr, what is going on. Finally, it detects cycles and uses their regularity to avoid repeating a bunch of text. The previous backtraces we were emitting was extremely unfriendly, potentially confusing, and often alarming, and this makes things almost "nice".
We can't necessarily make them much nicer than this, because a signal handler must use "signal-safe" functions. This precludes conveniences like dynamic allocations. Fortunately, Rust's stdlib has allocation-free formatting, but it may hinder integrating this error with our localization middleware, as I wasn't able to clearly ascertain, at a glance, whether there was a zero-alloc path through it.
r? `@Nilstrieb`
Always add LC_BUILD_VERSION for metadata object files
As of Xcode 15 Apple's linker has become a bit more strict about the warnings it produces. One of those new warnings requires all valid Mach-O object files in an archive to have a LC_BUILD_VERSION load command:
```
ld: warning: no platform load command found in 'ARCHIVE[arm64][2106](lib.rmeta)', assuming: iOS-simulator
```
This was already being done for Mac Catalyst so this change expands this logic to include it for all Apple platforms. I filed this behavior change as FB12546320 and was told it was the new intentional behavior.
As of Xcode 15 Apple's linker has become a bit more strict about the
warnings it produces. One of those new warnings requires all valid
Mach-O object files in an archive to have a LC_BUILD_VERSION load
command:
```
ld: warning: no platform load command found in 'ARCHIVE[arm64][2106](lib.rmeta)', assuming: iOS-simulator
```
This was already being done for Mac Catalyst so this change expands this
logic to include it for all Apple platforms. I filed this behavior
change as FB12546320 and was told it was the new intentional behavior.
Fix missing dependency file with `-Zunpretty`
This PR force the `output_filenames` to be run ~~in every early exits like~~ when using `-Zunpretty`, so to respect the `dep-info` flag.
Fixes https://github.com/rust-lang/rust/issues/112898
r? `@oli-obk`
Support `--print KIND=PATH` command line syntax
As is already done for `--emit KIND=PATH` and `-L KIND=PATH`.
In the discussion of #110785, it was pointed out that `--print KIND=PATH` is nicer than trying to apply the single global `-o` path to `--print`'s output, because in general there can be multiple print requests within a single rustc invocation, and anyway `-o` would already be used for a different meaning in the case of `link-args` and `native-static-libs`.
I am interested in using `--print cfg=PATH` in Buck2. Currently Buck2 works around the lack of support for `--print KIND=PATH` by [indirecting through a Python wrapper script](d43cf3a51a/prelude/rust/tools/get_rustc_cfg.py) to redirect rustc's stdout into the location dictated by the build system.
From skimming Cargo's usages of `--print`, it definitely seems like it would benefit from `--print KIND=PATH` too. Currently it is working around the lack of this by inserting `--crate-name=___ --print=crate-name` so that it can look for a line containing `___` as a delimiter between the 2 other `--print` informations it actually cares about. This is commented as a "HACK" and "abuse". 31eda6f7c3/src/cargo/core/compiler/build_context/target_info.rs (L242) (FYI `@weihanglo` as you dealt with this recently in https://github.com/rust-lang/cargo/pull/11633.)
Mentioning reviewers active in #110785: `@fee1-dead` `@jyn514` `@bjorn3`
Implement rust-lang/compiler-team#578.
When an ICE is encountered on nightly releases, the new rustc panic
handler will also write the contents of the backtrace to disk. If any
`delay_span_bug`s are encountered, their backtrace is also added to the
file. The platform and rustc version will also be collected.
First, we reuse the `MAX_FRAMES` constant.
Co-authored-by: erikdesjardins <erikdesjardins@users.noreply.github.com>
Then we choose an arbitrary recursion depth for
the other case. In this case, I used 2d20. Honest.
This cleans up the formatting of the backtrace considerably,
dodging the fact that a backtrace with recursion normally
emits hundreds of lines. Instead, simply write repeated symbols,
and add how many times the recursion occurred.
Also, it makes it look more like the "normal" backtrace.
Some fine details in the code are important for reducing
the amount of possible panic branches.
...to both compiler contributors and other rustc invokers.
The previous error messaging was extremely unfriendly,
and potentially both confusing and alarming.
The entire modules is extracted into a new file to help
ease of reading, and plenty of comments get layered in.
The design of the messaging is focused on preventing
the overall purpose of the output from being too opaque
in common cases, so users understand why it is there.
There's not an immediate need for it being actionable,
but some suggestions are offered anyways.
Previously, forgetting to call `interface::set_thread_safe_mode` would cause the following ICE:
```
thread 'rustc' panicked at 'uninitialized dyn_thread_safe mode!', /rustc/dfe0683138de0959b6ab6a039b54d9347f6a6355/compiler/rustc_data_structures/src/sync.rs:74:18
```
This calls `set_thread_safe_mode` in `interface::run_compiler` to avoid requiring it in the caller.
Fixes `tests/run-make-fulldeps/issue-19371` when parallel-compiler is enabled.
rustc installs a signal stack that assumes that
MINSIGSTKSZ is a constant, unchanging value.
Newer hardware undermines that assumption greatly,
with register files larger than MINSIGSTKZ.
Properly handle this so that it is correct on
all supported Linux versions with all CPUs.
Currently, the output of `rustc --explain foo` displays the raw markdown in a
pager. This is acceptable, but using actual formatting makes it easier to
understand.
This patch consists of three major components:
1. A markdown parser. This is an extremely simple non-backtracking recursive
implementation that requires normalization of the final token stream
2. A utility to write the token stream to an output buffer
3. Configuration within rustc_driver_impl to invoke this combination for
`--explain`. Like the current implementation, it first attempts to print to
a pager with a fallback colorized terminal, and standard print as a last
resort.
If color is disabled, or if the output does not support it, or if printing
with color fails, it will write the raw markdown (which matches current
behavior).
Pagers known to support color are: `less` (with `-r`), `bat` (aka `catbat`),
and `delta`.
The markdown parser does not support the entire markdown specification, but
should support the following with reasonable accuracy:
- Headings, including formatting
- Comments
- Code, inline and fenced block (no indented block)
- Strong, emphasis, and strikethrough formatted text
- Links, anchor, inline, and reference-style
- Horizontal rules
- Unordered and ordered list items, including formatting
This parser and writer should be reusable by other systems if ever needed.
Because `Lrc<Box<T>>` is silly. (Clippy warns about `Rc<Box<T>>` and
`Arc<Box<T>>`, and it would warn here if (a) we used Clippy with rustc,
and (b) Clippy knew about `Lrc`.)
There's no need to store it in `Queries`. We can just use a local
variable, because it's always used shortly after it's produced.
The commit also removes the `tcx.analysis()` call in `ongoing_codegen`,
because it's easy to ensure that's done beforehand.
All this makes the dataflow within `run_compiler` easier to follow, at
the cost of making one test slightly more verbose, which I think is a
good tradeoff.
Don't print unsupported split-debuginfo modes with `-Zunstable-options`
Currently unsupported `split-debuginfo` options are enabled by `-Zunstable-options`, for projects that have `-Zunstable-options` for other reasons this can be [an unexpected interaction](https://github.com/rust-lang/rust-clippy/pull/10516#issuecomment-1562604764)
This PR makes it so that `--print split-debuginfo -Zunstable-options` doesn't print unsupported modes, so that a cargo config of e.g.
```toml
[profile.dev]
split-debuginfo = "unpacked"
```
Would not cause an unsupported mode to be enabled on `x86_64-pc-windows-msvc`
Write to stdout if `-` is given as output file
With this PR, if `-o -` or `--emit KIND=-` is provided, output will be written to stdout instead. Binary output (those of type `obj`, `llvm-bc`, `link` and `metadata`) being written this way will result in an error unless stdout is not a tty. Multiple output types going to stdout will trigger an error too, as they will all be mixded together.
This implements https://github.com/rust-lang/compiler-team/issues/431
The idea behind the changes is to introduce an `OutFileName` enum that represents the output - be it a real path or stdout - and to use this enum along the code paths that handle different output types.
If `-o -` or `--emit KIND=-` is provided, output will be written
to stdout instead. Binary output (`obj`, `llvm-bc`, `link` and
`metadata`) being written this way will result in an error unless
stdout is not a tty. Multiple output types going to stdout will
trigger an error too, as they will all be mixded together.
Each of `{D,Subd}iagnosticMessage::{Str,Eager}` has a comment:
```
// FIXME(davidtwco): can a `Cow<'static, str>` be used here?
```
This commit answers that question in the affirmative. It's not the most
compelling change ever, but it might be worth merging.
This requires changing the `impl<'a> From<&'a str>` impls to `impl
From<&'static str>`, which involves a bunch of knock-on changes that
require/result in call sites being a little more precise about exactly
what kind of string they use to create errors, and not just `&str`. This
will result in fewer unnecessary allocations, though this will not have
any notable perf effects given that these are error paths.
Note that I was lazy within Clippy, using `to_string` in a few places to
preserve the existing string imprecision. I could have used `impl
Into<{D,Subd}iagnosticMessage>` in various places as is done in the
compiler, but that would have required changes to *many* call sites
(mostly changing `&format("...")` to `format!("...")`) which didn't seem
worthwhile.
rustc driver: Remove argument 0 before at-expansion to prevent ICE
Under Unix-based operating systems, when I execute rustc by setting argv0 to ``@/dev/null`,` it will expand command-line arguments from this file, leading to an empty arglist, which then triggers an ICE by trying to remove first argument.
The panic message is this:
```
thread 'main' panicked at 'range start index 1 out of range for slice of length 0', compiler/rustc_driver/src/lib.rs:972:17
```
My fix is to remove the first argument before expanding arguments.
<details>
<summary>Full backtrace</summary>
```sh
% (exec -a `@/dev/null` `rustup which rustc`)
thread 'main' panicked at 'range start index 1 out of range for slice of length 0', compiler/rustc_driver/src/lib.rs:972:17
stack backtrace:
0: 0x7fcec776659a - std::backtrace_rs::backtrace::libunwind::trace::h595f06c70adcc478
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
1: 0x7fcec776659a - std::backtrace_rs::backtrace::trace_unsynchronized::h177a0149c76cdde9
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x7fcec776659a - std::sys_common::backtrace::_print_fmt::hc0701fd2c3530c58
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/sys_common/backtrace.rs:65:5
3: 0x7fcec776659a - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hd4cd115d8750fd6c
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/sys_common/backtrace.rs:44:22
4: 0x7fcec77c839e - core::fmt::write::h93e2f5923c7eca08
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/core/src/fmt/mod.rs:1213:17
5: 0x7fcec7756be5 - std::io::Write::write_fmt::h8162dbb45f0b9e62
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/io/mod.rs:1682:15
6: 0x7fcec7766365 - std::sys_common::backtrace::_print::h1835ef8a8f9066da
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/sys_common/backtrace.rs:47:5
7: 0x7fcec7766365 - std::sys_common::backtrace::print::hcb5e6388b9235f41
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/sys_common/backtrace.rs:34:9
8: 0x7fcec776912f - std::panicking::default_hook::{{closure}}::h9c084969ccf9a722
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:267:22
9: 0x7fcec7768e6b - std::panicking::default_hook::h68fa2ba3c3c6c12f
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:286:9
10: 0x7fcecaab56e4 - <rustc_driver[f4ad927b3c57833d]::DEFAULT_HOOK::{closure#0}::{closure#0} as core[d16e85342ea223d9]::ops::function::FnOnce<(&core[d16e85342ea223d9]::panic::panic_info::PanicInfo,)>>::call_once::{shim:vtable#0}
11: 0x7fcec776996a - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::h4e6ced11e07d8b24
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/alloc/src/boxed.rs:2002:9
12: 0x7fcec776996a - std::panicking::rust_panic_with_hook::h8d5c434518ef298c
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:692:13
13: 0x7fcec77696e9 - std::panicking::begin_panic_handler::{{closure}}::hf33414f5dabf6faf
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:579:13
14: 0x7fcec7766a4c - std::sys_common::backtrace::__rust_end_short_backtrace::hc50389427413bb75
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/sys_common/backtrace.rs:137:18
15: 0x7fcec77693f2 - rust_begin_unwind
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:575:5
16: 0x7fcec77c4d43 - core::panicking::panic_fmt::h2de7a7938f816de8
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/core/src/panicking.rs:64:14
17: 0x7fcec77cb492 - core::slice::index::slice_start_index_len_fail_rt::h0c87d85ce11d10f6
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/core/src/slice/index.rs:53:5
18: 0x7fcec77cb416 - core::slice::index::slice_start_index_len_fail::h504609f2a6b168d1
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/core/src/slice/index.rs:41:9
19: 0x7fceca0eca1f - rustc_driver[f4ad927b3c57833d]::handle_options
20: 0x7fceca0e037f - <rustc_driver[f4ad927b3c57833d]::RunCompiler>::run
21: 0x7fceca0dfd0d - <core[d16e85342ea223d9]::panic::unwind_safe::AssertUnwindSafe<rustc_driver[f4ad927b3c57833d]::main::{closure#0}> as core[d16e85342ea223d9]::ops::function::FnOnce<()>>::call_once
22: 0x7fceca17ce89 - rustc_driver[f4ad927b3c57833d]::main
23: 0x564f5f008a87 - rustc_main[f164605d1302e295]::main
24: 0x564f5f008973 - std[3da461b304582a2c]::sys_common::backtrace::__rust_begin_short_backtrace::<fn(), ()>
25: 0x564f5f008969 - <std[3da461b304582a2c]::rt::lang_start<()>::{closure#0} as core[d16e85342ea223d9]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
26: 0x7fcec774795c - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h699977d052768608
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/core/src/ops/function.rs:287:13
27: 0x7fcec774795c - std::panicking::try::do_call::h4e121e623c70f903
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:483:40
28: 0x7fcec774795c - std::panicking::try::hf9d919e062bc178a
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:447:19
29: 0x7fcec774795c - std::panic::catch_unwind::h7a7b12272684cb97
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panic.rs:140:14
30: 0x7fcec774795c - std::rt::lang_start_internal::{{closure}}::hd96b0eb4844b8762
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/rt.rs:148:48
31: 0x7fcec774795c - std::panicking::try::do_call::h1af1f88f4f92a22c
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:483:40
32: 0x7fcec774795c - std::panicking::try::hf20d7abea7f0f097
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:447:19
33: 0x7fcec774795c - std::panic::catch_unwind::hb0e084c3a9c042e4
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panic.rs:140:14
34: 0x7fcec774795c - std::rt::lang_start_internal::hca9d5c7277f5b67c
at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/rt.rs:148:20
35: 0x564f5f008ab7 - main
36: 0x7fcec74a1790 - <unknown>
37: 0x7fcec74a184a - __libc_start_main
38: 0x564f5f00899e - <unknown>
39: 0x0 - <unknown>
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md
note: rustc 1.68.0 (2c8cc3432 2023-03-06) running on x86_64-unknown-linux-gnu
query stack during panic:
end of query stack
```
</details>
I also checked if I can trigger a similar problem by passing empty argument list to `execve`, but at least under Linux, it seems to always insert an empty first argument if there are none.
very minor cleanups
- add `must_use` to `early_error_no_abort`
this was already being used at its only callsite, but this ensures that new code remembers to use it if it's called in the future. found this while investigating https://github.com/rust-lang/rust/issues/110090.
- remove outdated and incorrect comment in `builder.rs`. `doc_rust_lang_org_channel` doesn't exist in rustdoc, it gets it from an env var instead: b275d2c30b/src/librustdoc/clean/utils.rs (L569-L573)
Only depend on CFG_VERSION in rustc_interface
This avoids having to rebuild the whole compiler on each commit when `omit-git-hash = false`.
cc https://github.com/rust-lang/rust/issues/76720 - this won't fix it, and I'm not suggesting we turn this on by default, but it will make it less painful for people who do have `omit-git-hash` on as a workaround.
- add `must_use` to `early_error_no_abort`
this was already being used at its only callsite, but this ensures
that new code remembers to use it if it's called in the future.
- remove outdated and incorrect comment in `builder.rs`.
`doc_rust_lang_org_channel` doesn't exist in rustdoc, it gets it from
an env var instead.
Error message all end up passing into a function as an `impl
Into<{D,Subd}iagnosticMessage>`. If an error message is creatd as
`&format("...")` that means we allocate a string (in the `format!`
call), then take a reference, and then clone (allocating again) the
reference to produce the `{D,Subd}iagnosticMessage`, which is silly.
This commit removes the leading `&` from a lot of these cases. This
means the original `String` is moved into the
`{D,Subd}iagnosticMessage`, avoiding the double allocations. This
requires changing some function argument types from `&str` to `String`
(when all arguments are `String`) or `impl
Into<{D,Subd}iagnosticMessage>` (when some arguments are `String` and
some are `&str`).
Introduce `DynSend` and `DynSync` auto trait for parallel compiler
part of parallel-rustc #101566
This PR introduces `DynSend / DynSync` trait and `FromDyn / IntoDyn` structure in rustc_data_structure::marker. `FromDyn` can dynamically check data structures for thread safety when switching to parallel environments (such as calling `par_for_each_in`). This happens only when `-Z threads > 1` so it doesn't affect single-threaded mode's compile efficiency.
r? `@cjgillot`
Make the BUG_REPORT_URL configurable by tools
This greatly simplifies how hard it is to set a custom bug report url; previously tools had to copy
the entire hook implementation.
I haven't changed clippy in case they want to make the change upstream instead of the subtree, but
I'm happy to do so here if the maintainers want - cc ````@rust-lang/clippy````
Fixes https://github.com/rust-lang/rust/issues/109486.
This greatly simplifies how hard it is to set a custom bug report url; previously tools had to copy
the entire hook implementation.
- Switch clippy to the new hook
This also adds a `extra_info` callback so clippy can include its own version number, which differs
from rustc's.
- Call `install_ice_hook` in rustfmt
Fluent, with all the icu4x it brings in, takes quite some time to
compile. `fluent_messages!` is only needed in further downstream rustc
crates, but is blocking more upstream crates like `rustc_index`. By
splitting it out, we allow `rustc_macros` to be compiled earlier, which
speeds up `x check compiler` by about 5 seconds (and even more after the
needless dependency on `serde_json` is removed from
`rustc_data_structures`).
Add `-Z time-passes-format` to allow specifying a JSON output for `-Z time-passes`
This adds back the `-Z time` option as that is useful for [my rustc benchmark tool](https://github.com/Zoxc/rcb), reverting https://github.com/rust-lang/rust/pull/102725. It now uses nanoseconds and bytes as the units so it is renamed to `time-precise`.
It partially expands crate attributes before the main expansion pass (without modifying the crate), and the produced preliminary crate attribute list is used for querying a few attributes that are required very early.
Crate-level cfg attributes are then expanded normally during the main expansion pass, like attributes on any other nodes.
This makes it easier to open the messages file while developing on features.
The commit was the result of automatted changes:
for p in compiler/rustc_*; do mv $p/locales/en-US.ftl $p/messages.ftl; rmdir $p/locales; done
for p in compiler/rustc_*; do sed -i "s#\.\./locales/en-US.ftl#../messages.ftl#" $p/src/lib.rs; done
Extend `CodegenBackend` trait with a function returning the translation
resources from the codegen backend, which can be added to the complete
list of resources provided to the emitter.
Signed-off-by: David Wood <david.wood@huawei.com>
Instead of loading the Fluent resources for every crate in
`rustc_error_messages`, each crate generates typed identifiers for its
own diagnostics and creates a static which are pulled together in the
`rustc_driver` crate and provided to the diagnostic emitter.
Signed-off-by: David Wood <david.wood@huawei.com>
Most tests involving save-analysis were removed, but I kept a few where
the `-Zsave-analysis` was an add-on to the main thing being tested,
rather than the main thing being tested.
For `x.py install`, the `rust-analysis` target has been removed.
For `x.py dist`, the `rust-analysis` target has been kept in a
degenerate form: it just produces a single file `reduced.json`
indicating that save-analysis has been removed. This is necessary for
rustup to keep working.
Closes#43606.
Introduce `-Zterminal-urls` to use OSC8 for error codes
Terminals supporting the OSC8 Hyperlink Extension can support inline anchors where the text is user defineable but clicking on it opens a browser to a specified URLs, just like `<a href="URL">` does in HTML.
https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
Terminals supporting the OSC8 Hyperlink Extension can support inline
anchors where the text is user defineable but clicking on it opens a
browser to a specified URLs, just like `<a href="URL">` does in HTML.
https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
