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.
