Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0 #90128

joshtriplett · 2021-10-21T12:10:18Z

This allows selecting v0 symbol-mangling without an unstable option. Selecting legacy still requires -Z unstable-options.

This does not change the default symbol-mangling-version. See #89917 for a pull request changing the default. Rationale, from #89917:

Rust's current mangling scheme depends on compiler internals; loses information about generic parameters (and other things) which makes for a worse experience when using external tools that need to interact with Rust symbol names; is inconsistent; and can contain . characters which aren't universally supported. Therefore, Rust has defined its own symbol mangling scheme which is defined in terms of the Rust language, not the compiler implementation; encodes information about generic parameters in a reversible way; has a consistent definition; and generates symbols that only use the characters A-Z, a-z, 0-9, and _.

Support for the new Rust symbol mangling scheme has been added to upstream tools that will need to interact with Rust symbols (e.g. debuggers).

This pull request allows enabling the new v0 symbol-mangling-version.

See #89917 for references to the implementation of v0, and for references to the tool changes to decode Rust symbols.

rust-highfive · 2021-10-21T12:10:21Z

r? @wesleywiser

(rust-highfive has picked a reviewer for you, use r? to override)

compiler/rustc_session/src/config.rs

Mark-Simulacrum · 2021-10-21T12:22:25Z

I think unless the goal here is to only stabilize just the existence, not the specifics, even not changing the default still feels like it deserves a writeup similar to that given as part of the other PR seeking to change the default. There were several concerns raised on that PR that should get addressed in such a writeup, I believe. @michaelwoerister was going to work on that next week.

joshtriplett · 2021-10-21T12:32:54Z

@Mark-Simulacrum Stabilizing the existence and not the specifics was exactly the idea. But nonetheless, I'd be happy to provide a writeup explaining and justifying the change.

joshtriplett · 2021-10-21T12:36:45Z

#90128 (comment) now has an explanation and rationale, based on the one from #89917.

joshtriplett · 2021-10-21T12:49:00Z

Fixing tests to use -C now...

michaelwoerister · 2021-10-21T15:13:26Z

Presumably we'd like to remove the legacy mangling scheme from the compiler at some point. How would we handled that if this becomes a stable flag?

michaelwoerister · 2021-10-21T15:14:45Z

In general I agree that it is a good idea to offer a stable way for switching back to the legacy scheme for the time being.

camelid · 2021-10-21T21:00:03Z

Presumably we'd like to remove the legacy mangling scheme from the compiler at some point. How would we handled that if this becomes a stable flag?

I think the idea (correct me if I'm wrong) is that just -C symbol-mangling-version=v0 would be stabilized; -C symbol-mangling-version=legacy would still be feature-gated. Then, once v0 is the default, -C symbol-mangling-version=v0 would do nothing.

joshtriplett · 2021-10-21T21:48:31Z

Exactly. I was proposing to leave legacy unstable for now. We could change that when changing the default, or we could leave it permanently unstable and eventually remove it.

joshtriplett · 2021-10-23T11:51:18Z

Rebased.

joshtriplett · 2021-10-23T12:06:32Z

Oh, right, bootstrap needs to use an option compatible with a previous rustc. Will fix.

ehuss · 2022-01-02T18:54:19Z

@joshtriplett Would you be willing to add docs for this at https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/codegen-options/index.md?

rust-timer · 2022-01-02T21:51:32Z

Finished benchmarking commit (8f3238f): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

The unstable syntax gives a warning on the current toolchain. The new syntax is stable as of rust-lang/rust#90128 Change-Id: If2ff4bdbae68256b8e13e1d2c54c6346aaac99f2 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/635923 Fuchsia-Auto-Submit: Dan Johnson <computerdruid@google.com> Reviewed-by: Tyler Mandry <tmandry@google.com> Commit-Queue: Auto-Submit <auto-submit@fuchsia-infra.iam.gserviceaccount.com>

…overage, r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: rust-lang#79121) This PR stabilizes support for instrumentation-based code coverage, previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now, but show a deprecation warning for it.) Many, many people have tested this support, and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized, will the compiler flag be updated to -C instrument-coverage? (If so, the -Z variant could also be supported for some time, to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so, what is the current status and timeline? This stabilization PR depends on rust-lang#90128 , which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4), which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage, and using an older version of LLVM. Given that LLVM 13 has now been released, requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11, nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer, allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](rust-lang#79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage`, but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at rust-lang/compiler-team#278 . Based on that, `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.

…overage, r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: rust-lang#79121) This PR stabilizes support for instrumentation-based code coverage, previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now, but show a deprecation warning for it.) Many, many people have tested this support, and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized, will the compiler flag be updated to -C instrument-coverage? (If so, the -Z variant could also be supported for some time, to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so, what is the current status and timeline? This stabilization PR depends on rust-lang#90128 , which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4), which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage, and using an older version of LLVM. Given that LLVM 13 has now been released, requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11, nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer, allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](rust-lang#79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage`, but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at rust-lang/compiler-team#278 . Based on that, ``@pnkfelix`` suggested that this needed a stabilization PR and a compiler-team FCP.

…overage, r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: rust-lang#79121) This PR stabilizes support for instrumentation-based code coverage, previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now, but show a deprecation warning for it.) Many, many people have tested this support, and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized, will the compiler flag be updated to -C instrument-coverage? (If so, the -Z variant could also be supported for some time, to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so, what is the current status and timeline? This stabilization PR depends on rust-lang#90128 , which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4), which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage, and using an older version of LLVM. Given that LLVM 13 has now been released, requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11, nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer, allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](rust-lang#79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage`, but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at rust-lang/compiler-team#278 . Based on that, ```@pnkfelix``` suggested that this needed a stabilization PR and a compiler-team FCP.

…overage, r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: rust-lang#79121) This PR stabilizes support for instrumentation-based code coverage, previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now, but show a deprecation warning for it.) Many, many people have tested this support, and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized, will the compiler flag be updated to -C instrument-coverage? (If so, the -Z variant could also be supported for some time, to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so, what is the current status and timeline? This stabilization PR depends on rust-lang#90128 , which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4), which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage, and using an older version of LLVM. Given that LLVM 13 has now been released, requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11, nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer, allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](rust-lang#79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage`, but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at rust-lang/compiler-team#278 . Based on that, `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.

Pkgsrc changes: * Bump available bootstraps to 1.58.1. * Adjust one patch (and checksum) so that it still applies. Upstream changes: Version 1.59.0 (2022-02-24) ========================== Language -------- - [Stabilize default arguments for const generics][90207] - [Stabilize destructuring assignment][90521] - [Relax private in public lint on generic bounds and where clauses of trait impls][90586] - [Stabilize asm! and global_asm! for x86, x86_64, ARM, Aarch64, and RISC-V][91728] Compiler -------- - [Stabilize new symbol mangling format, leaving it opt-in (-Csymbol-mangling-version=v0)][90128] - [Emit LLVM optimization remarks when enabled with `-Cremark`][90833] - [Fix sparc64 ABI for aggregates with floating point members][91003] - [Warn when a `#[test]`-like built-in attribute macro is present multiple times.][91172] - [Add support for riscv64gc-unknown-freebsd][91284] - [Stabilize `-Z emit-future-incompat` as `--json future-incompat`][91535] - [Soft disable incremental compilation][94124] This release disables incremental compilation, unless the user has explicitly opted in via the newly added RUSTC_FORCE_INCREMENTAL=1 environment variable. This is due to a known and relatively frequently occurring bug in incremental compilation, which causes builds to issue internal compiler errors. This particular bug is already fixed on nightly, but that fix has not yet rolled out to stable and is deemed too risky for a direct stable backport. As always, we encourage users to test with nightly and report bugs so that we can track failures and fix issues earlier. See [94124] for more details. [94124]: rust-lang/rust#94124 Libraries --------- - [Remove unnecessary bounds for some Hash{Map,Set} methods][91593] Stabilized APIs --------------- - [`std::thread::available_parallelism`][available_parallelism] - [`Result::copied`][result-copied] - [`Result::cloned`][result-cloned] - [`arch::asm!`][asm] - [`arch::global_asm!`][global_asm] - [`ops::ControlFlow::is_break`][is_break] - [`ops::ControlFlow::is_continue`][is_continue] - [`TryFrom<char> for u8`][try_from_char_u8] - [`char::TryFromCharError`][try_from_char_err] implementing `Clone`, `Debug`, `Display`, `PartialEq`, `Copy`, `Eq`, `Error` - [`iter::zip`][zip] - [`NonZeroU8::is_power_of_two`][is_power_of_two8] - [`NonZeroU16::is_power_of_two`][is_power_of_two16] - [`NonZeroU32::is_power_of_two`][is_power_of_two32] - [`NonZeroU64::is_power_of_two`][is_power_of_two64] - [`NonZeroU128::is_power_of_two`][is_power_of_two128] - [`DoubleEndedIterator for ToLowercase`][lowercase] - [`DoubleEndedIterator for ToUppercase`][uppercase] - [`TryFrom<&mut [T]> for [T; N]`][tryfrom_ref_arr] - [`UnwindSafe for Once`][unwindsafe_once] - [`RefUnwindSafe for Once`][refunwindsafe_once] - [armv8 neon intrinsics for aarch64][stdarch/1266] Const-stable: - [`mem::MaybeUninit::as_ptr`][muninit_ptr] - [`mem::MaybeUninit::assume_init`][muninit_init] - [`mem::MaybeUninit::assume_init_ref`][muninit_init_ref] - [`ffi::CStr::from_bytes_with_nul_unchecked`][cstr_from_bytes] Cargo ----- - [Stabilize the `strip` profile option][cargo/10088] - [Stabilize future-incompat-report][cargo/10165] - [Support abbreviating `--release` as `-r`][cargo/10133] - [Support `term.quiet` configuration][cargo/10152] - [Remove `--host` from cargo {publish,search,login}][cargo/10145] Compatibility Notes ------------------- - [Refactor weak symbols in std::sys::unix][90846] This may add new, versioned, symbols when building with a newer glibc, as the standard library uses weak linkage rather than dynamically attempting to load certain symbols at runtime. - [Deprecate crate_type and crate_name nested inside `#![cfg_attr]`][83744] This adds a future compatibility lint to supporting the use of cfg_attr wrapping either crate_type or crate_name specification within Rust files; it is recommended that users migrate to setting the equivalent command line flags. - [Remove effect of `#[no_link]` attribute on name resolution][92034] This may expose new names, leading to conflicts with preexisting names in a given namespace and a compilation failure. - [Cargo will document libraries before binaries.][cargo/10172] - [Respect doc=false in dependencies, not just the root crate][cargo/10201] - [Weaken guarantee around advancing underlying iterators in zip][83791] - [Make split_inclusive() on an empty slice yield an empty output][89825] - [Update std::env::temp_dir to use GetTempPath2 on Windows when available.][89999] - [unreachable! was updated to match other formatting macro behavior on Rust 2021][92137] Internal Changes ---------------- These changes provide no direct user facing benefits, but represent significant improvements to the internals and overall performance of rustc and related tools. - [Fix many cases of normalization-related ICEs][91255] - [Replace dominators algorithm with simple Lengauer-Tarjan][85013] - [Store liveness in interval sets for region inference][90637] - [Remove `in_band_lifetimes` from the compiler and standard library, in preparation for removing this unstable feature.][91867] [91867]: rust-lang/rust#91867 [83744]: rust-lang/rust#83744 [83791]: rust-lang/rust#83791 [85013]: rust-lang/rust#85013 [89825]: rust-lang/rust#89825 [89999]: rust-lang/rust#89999 [90128]: rust-lang/rust#90128 [90207]: rust-lang/rust#90207 [90521]: rust-lang/rust#90521 [90586]: rust-lang/rust#90586 [90637]: rust-lang/rust#90637 [90833]: rust-lang/rust#90833 [90846]: rust-lang/rust#90846 [91003]: rust-lang/rust#91003 [91172]: rust-lang/rust#91172 [91255]: rust-lang/rust#91255 [91284]: rust-lang/rust#91284 [91535]: rust-lang/rust#91535 [91593]: rust-lang/rust#91593 [91728]: rust-lang/rust#91728 [91878]: rust-lang/rust#91878 [91896]: rust-lang/rust#91896 [91926]: rust-lang/rust#91926 [91984]: rust-lang/rust#91984 [92020]: rust-lang/rust#92020 [92034]: rust-lang/rust#92034 [92483]: rust-lang/rust#92483 [cargo/10088]: rust-lang/cargo#10088 [cargo/10133]: rust-lang/cargo#10133 [cargo/10145]: rust-lang/cargo#10145 [cargo/10152]: rust-lang/cargo#10152 [cargo/10165]: rust-lang/cargo#10165 [cargo/10172]: rust-lang/cargo#10172 [cargo/10201]: rust-lang/cargo#10201 [cargo/10269]: rust-lang/cargo#10269 [cstr_from_bytes]: https://doc.rust-lang.org/stable/std/ffi/struct.CStr.html#method.from_bytes_with_nul_unchecked [muninit_ptr]: https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.html#method.as_ptr [muninit_init]: https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.html#method.assume_init [muninit_init_ref]: https://doc.rust-lang.org/stable/std/mem/union.MaybeUninit.html#method.assume_init_ref [unwindsafe_once]: https://doc.rust-lang.org/stable/std/sync/struct.Once.html#impl-UnwindSafe [refunwindsafe_once]: https://doc.rust-lang.org/stable/std/sync/struct.Once.html#impl-RefUnwindSafe [tryfrom_ref_arr]: https://doc.rust-lang.org/stable/std/convert/trait.TryFrom.html#impl-TryFrom%3C%26%27_%20mut%20%5BT%5D%3E [lowercase]: https://doc.rust-lang.org/stable/std/char/struct.ToLowercase.html#impl-DoubleEndedIterator [uppercase]: https://doc.rust-lang.org/stable/std/char/struct.ToUppercase.html#impl-DoubleEndedIterator [try_from_char_err]: https://doc.rust-lang.org/stable/std/char/struct.TryFromCharError.html [available_parallelism]: https://doc.rust-lang.org/stable/std/thread/fn.available_parallelism.html [result-copied]: https://doc.rust-lang.org/stable/std/result/enum.Result.html#method.copied [result-cloned]: https://doc.rust-lang.org/stable/std/result/enum.Result.html#method.cloned [asm]: https://doc.rust-lang.org/stable/core/arch/macro.asm.html [global_asm]: https://doc.rust-lang.org/stable/core/arch/macro.global_asm.html [is_break]: https://doc.rust-lang.org/stable/std/ops/enum.ControlFlow.html#method.is_break [is_continue]: https://doc.rust-lang.org/stable/std/ops/enum.ControlFlow.html#method.is_continue [try_from_char_u8]: https://doc.rust-lang.org/stable/std/primitive.char.html#impl-TryFrom%3Cchar%3E [zip]: https://doc.rust-lang.org/stable/std/iter/fn.zip.html [is_power_of_two8]: https://doc.rust-lang.org/stable/core/num/struct.NonZeroU8.html#method.is_power_of_two [is_power_of_two16]: https://doc.rust-lang.org/stable/core/num/struct.NonZeroU16.html#method.is_power_of_two [is_power_of_two32]: https://doc.rust-lang.org/stable/core/num/struct.NonZeroU32.html#method.is_power_of_two [is_power_of_two64]: https://doc.rust-lang.org/stable/core/num/struct.NonZeroU64.html#method.is_power_of_two [is_power_of_two128]: https://doc.rust-lang.org/stable/core/num/struct.NonZeroU128.html#method.is_power_of_two [stdarch/1266]: rust-lang/stdarch#1266

…=estebank,Mark-Simulacrum Add missing rustc arg docs Add documentation for recently added rustc args `-C symbol-mangling-version` was stabilized in rust-lang#90128. `--json=future-incompat` was stabilized in rust-lang#91535.

…rister Add documentation on v0 symbol mangling. This adds official documentation for the v0 symbol mangling format, migrating the documentation from [RFC 2603](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html). The format was originally stabilized as the `-C symbol-mangling-version` option, but the specifics were not stabilized (per rust-lang#90128 (comment)). Per the discussion at rust-lang#93661 (comment) this adds those specifics as an official description of the format. cc rust-lang#89917

…ster Add documentation on v0 symbol mangling. This adds official documentation for the v0 symbol mangling format, migrating the documentation from [RFC 2603](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html). The format was originally stabilized as the `-C symbol-mangling-version` option, but the specifics were not stabilized (per rust-lang#90128 (comment)). Per the discussion at rust-lang#93661 (comment) this adds those specifics as an official description of the format. cc rust-lang#89917

Add documentation on v0 symbol mangling. This adds official documentation for the v0 symbol mangling format, migrating the documentation from [RFC 2603](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html). The format was originally stabilized as the `-C symbol-mangling-version` option, but the specifics were not stabilized (per rust-lang/rust#90128 (comment)). Per the discussion at rust-lang/rust#93661 (comment) this adds those specifics as an official description of the format. cc #89917

Remove support for alias `-Z symbol-mangling-version` (This is very similar to the removal of `-Z instrument-coverage` in rust-lang#117111.) `-C symbol-mangling-version` was stabilized back in rustc 1.59.0 (2022-02-24) via rust-lang#90128, with the old unstable flag kept around (with a warning) as an alias to ease migration.

Rollup merge of rust-lang#117509 - Zalathar:zsymbol, r=petrochenkov Remove support for alias `-Z symbol-mangling-version` (This is very similar to the removal of `-Z instrument-coverage` in rust-lang#117111.) `-C symbol-mangling-version` was stabilized back in rustc 1.59.0 (2022-02-24) via rust-lang#90128, with the old unstable flag kept around (with a warning) as an alias to ease migration.

This was stabilized toward the beginning of 2022 (rust-lang/rust#90128), though it still isn't the default used by the compiler. Fuchsia tooling should know how to demangle Rust symbols by now (except for tools that already don't work with the legacy mangling scheme, http://fxbug.dev/64315). Test: Manually verified that zxdb can symbolize backtraces when this option is enabled. Fixed: 57302 Change-Id: If0284671499af04194ab6033a3b7c54cf2314cd2 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/769822 Reviewed-by: Joseph Ryan <josephry@google.com> Commit-Queue: Tyler Mandry <tmandry@google.com> Fuchsia-Auto-Submit: Tyler Mandry <tmandry@google.com> Reviewed-by: David Koloski <dkoloski@google.com> Reviewed-by: Dangyi Liu <dangyi@google.com>

Add documentation on v0 symbol mangling. This adds official documentation for the v0 symbol mangling format, migrating the documentation from [RFC 2603](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html). The format was originally stabilized as the `-C symbol-mangling-version` option, but the specifics were not stabilized (per rust-lang/rust#90128 (comment)). Per the discussion at rust-lang/rust#93661 (comment) this adds those specifics as an official description of the format. cc #89917

rust-highfive assigned wesleywiser Oct 21, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 21, 2021

joshtriplett mentioned this pull request Oct 21, 2021

Tracking issue for RFC 2603, "Rust Symbol Mangling (v0)" #60705

Open

16 tasks

bjorn3 reviewed Oct 21, 2021

View reviewed changes

compiler/rustc_session/src/config.rs Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

eddyb reviewed Oct 21, 2021

View reviewed changes

compiler/rustc_session/src/config.rs Outdated Show resolved Hide resolved

compiler/rustc_session/src/config.rs Outdated Show resolved Hide resolved

joshtriplett force-pushed the stabilize-symbol-mangling-version branch from b2173bc to 5d67a5c Compare October 21, 2021 12:21

joshtriplett force-pushed the stabilize-symbol-mangling-version branch 2 times, most recently from 56352db to a497380 Compare October 21, 2021 12:26

This comment has been minimized.

Sign in to view

joshtriplett force-pushed the stabilize-symbol-mangling-version branch from a497380 to 9b08922 Compare October 21, 2021 12:31

joshtriplett mentioned this pull request Oct 21, 2021

Tracking Issue for LLVM InstrProf code coverage (current flag: -Zinstrument-coverage) #79121

Closed

3 tasks

joshtriplett added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Oct 21, 2021

joshtriplett force-pushed the stabilize-symbol-mangling-version branch from 5fd9867 to ea11b04 Compare October 21, 2021 13:25

joshtriplett mentioned this pull request Oct 21, 2021

Stabilize -Z instrument-coverage as -C instrument-coverage #90132

Merged

This comment has been minimized.

Sign in to view

joshtriplett force-pushed the stabilize-symbol-mangling-version branch from ea11b04 to 6f05867 Compare October 23, 2021 11:51

This comment has been minimized.

Sign in to view

joshtriplett force-pushed the stabilize-symbol-mangling-version branch from 6f05867 to 70bebbe Compare October 23, 2021 15:19

joshtriplett deleted the stabilize-symbol-mangling-version branch January 2, 2022 23:20

ojeda mentioned this pull request Jan 12, 2022

Rust unstable features needed for the kernel Rust-for-Linux/linux#2

Open

89 tasks

tmiasko mentioned this pull request Jan 14, 2022

Stabilize -Zsymbol-mangling-version / RFC2603? #77116

Closed

ehuss mentioned this pull request Feb 4, 2022

Add missing rustc arg docs #93661

Merged

EFanZh mentioned this pull request Feb 17, 2022

Docs: Remove unnecessary -Zunstable-flags in docs #94076

Closed

ehuss mentioned this pull request Feb 20, 2022

Update for recent stabilizations rust-lang/rustc-dev-guide#1310

Merged

ehuss mentioned this pull request May 31, 2022

Add documentation on v0 symbol mangling. #97571

Merged

Zalathar mentioned this pull request Oct 21, 2023

schroedingers instrument-coverage #116980

Closed

Zalathar mentioned this pull request Nov 2, 2023

Remove support for alias -Z symbol-mangling-version #117509

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0 #90128

Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0 #90128

joshtriplett commented Oct 21, 2021 •

edited

Loading

rust-highfive commented Oct 21, 2021

This comment has been minimized.

Mark-Simulacrum commented Oct 21, 2021

This comment has been minimized.

joshtriplett commented Oct 21, 2021

joshtriplett commented Oct 21, 2021

joshtriplett commented Oct 21, 2021

michaelwoerister commented Oct 21, 2021

michaelwoerister commented Oct 21, 2021

camelid commented Oct 21, 2021

joshtriplett commented Oct 21, 2021

This comment has been minimized.

joshtriplett commented Oct 23, 2021

This comment has been minimized.

joshtriplett commented Oct 23, 2021

ehuss commented Jan 2, 2022

rust-timer commented Jan 2, 2022

Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0 #90128

Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0 #90128

Conversation

joshtriplett commented Oct 21, 2021 • edited Loading

rust-highfive commented Oct 21, 2021

This comment has been minimized.

Mark-Simulacrum commented Oct 21, 2021

This comment has been minimized.

joshtriplett commented Oct 21, 2021

joshtriplett commented Oct 21, 2021

joshtriplett commented Oct 21, 2021

michaelwoerister commented Oct 21, 2021

michaelwoerister commented Oct 21, 2021

camelid commented Oct 21, 2021

joshtriplett commented Oct 21, 2021

This comment has been minimized.

joshtriplett commented Oct 23, 2021

This comment has been minimized.

joshtriplett commented Oct 23, 2021

ehuss commented Jan 2, 2022

rust-timer commented Jan 2, 2022

joshtriplett commented Oct 21, 2021 •

edited

Loading