Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0 by joshtriplett · Pull Request #90128 · rust-lang/rust (original) (raw)
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
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.
r? @wesleywiser
(rust-highfive has picked a reviewer for you, use r? to override)
This comment has been minimized.
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.
This comment has been minimized.
@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.
Fixing tests to use -C now...
Relevant to the compiler team, which will review and decide on the PR/issue.
label
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?
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.
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.
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.
This comment has been minimized.
This comment has been minimized.
Oh, right, bootstrap needs to use an option compatible with a previous rustc. Will fix.
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
95 tasks
github-actions bot pushed a commit to gnoliyil/fuchsia that referenced this pull request
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
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
…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 and the issue label 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.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
…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 and the issue label 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.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
…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 and the issue label 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.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
…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 and the issue label 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.
wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request
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
- Stabilize destructuring assignment
- Relax private in public lint on generic bounds and where clauses of trait impls
- Stabilize asm! and global_asm! for x86, x86_64, ARM, Aarch64, and RISC-V
Compiler
- Stabilize new symbol mangling format, leaving it opt-in (-Csymbol-mangling-version=v0)
- Emit LLVM optimization remarks when enabled with
-Cremark - Fix sparc64 ABI for aggregates with floating point members
- Warn when a
#[test]-like built-in attribute macro is present multiple times. - Add support for riscv64gc-unknown-freebsd
- Stabilize
-Z emit-future-incompatas--json future-incompat - Soft disable incremental compilation
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.
Libraries
Stabilized APIs
std::thread::available_parallelismResult::copiedResult::clonedarch::asm!arch::global_asm!ops::ControlFlow::is_breakops::ControlFlow::is_continueTryFrom<char> for u8char::TryFromCharErrorimplementingClone,Debug,Display,PartialEq,Copy,Eq,Erroriter::zipNonZeroU8::is_power_of_twoNonZeroU16::is_power_of_twoNonZeroU32::is_power_of_twoNonZeroU64::is_power_of_twoNonZeroU128::is_power_of_twoDoubleEndedIterator for ToLowercaseDoubleEndedIterator for ToUppercaseTryFrom<&mut [T]> for [T; N]UnwindSafe for OnceRefUnwindSafe for Once- armv8 neon intrinsics for aarch64
Const-stable:
mem::MaybeUninit::as_ptrmem::MaybeUninit::assume_initmem::MaybeUninit::assume_init_refffi::CStr::from_bytes_with_nul_unchecked
Cargo
- Stabilize the
stripprofile option - Stabilize future-incompat-report
- Support abbreviating
--releaseas-r - Support
term.quietconfiguration - Remove
--hostfrom cargo {publish,search,login}
Compatibility Notes
- Refactor weak symbols in std::sys::unix 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]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 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.
- Respect doc=false in dependencies, not just the root crate
- Weaken guarantee around advancing underlying iterators in zip
- Make split_inclusive() on an empty slice yield an empty output
- Update std::env::temp_dir to use GetTempPath2 on Windows when available.
- [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.
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request
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
- Stabilize destructuring assignment
- Relax private in public lint on generic bounds and where clauses of trait impls
- Stabilize asm! and global_asm! for x86, x86_64, ARM, Aarch64, and RISC-V
Compiler
- Stabilize new symbol mangling format, leaving it opt-in (-Csymbol-mangling-version=v0)
- Emit LLVM optimization remarks when enabled with
-Cremark - Fix sparc64 ABI for aggregates with floating point members
- Warn when a
#[test]-like built-in attribute macro is present multiple times. - Add support for riscv64gc-unknown-freebsd
- Stabilize
-Z emit-future-incompatas--json future-incompat - Soft disable incremental compilation
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.
Libraries
Stabilized APIs
std::thread::available_parallelismResult::copiedResult::clonedarch::asm!arch::global_asm!ops::ControlFlow::is_breakops::ControlFlow::is_continueTryFrom<char> for u8char::TryFromCharErrorimplementingClone,Debug,Display,PartialEq,Copy,Eq,Erroriter::zipNonZeroU8::is_power_of_twoNonZeroU16::is_power_of_twoNonZeroU32::is_power_of_twoNonZeroU64::is_power_of_twoNonZeroU128::is_power_of_twoDoubleEndedIterator for ToLowercaseDoubleEndedIterator for ToUppercaseTryFrom<&mut [T]> for [T; N]UnwindSafe for OnceRefUnwindSafe for Once- armv8 neon intrinsics for aarch64
Const-stable:
mem::MaybeUninit::as_ptrmem::MaybeUninit::assume_initmem::MaybeUninit::assume_init_refffi::CStr::from_bytes_with_nul_unchecked
Cargo
- Stabilize the
stripprofile option - Stabilize future-incompat-report
- Support abbreviating
--releaseas-r - Support
term.quietconfiguration - Remove
--hostfrom cargo {publish,search,login}
Compatibility Notes
- Refactor weak symbols in std::sys::unix 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]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 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.
- Respect doc=false in dependencies, not just the root crate
- Weaken guarantee around advancing underlying iterators in zip
- Make split_inclusive() on an empty slice yield an empty output
- Update std::env::temp_dir to use GetTempPath2 on Windows when available.
- [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.
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request
…=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.
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request
bors added a commit to rust-lang-ci/rust that referenced this pull request
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
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.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
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.
gnoliyil pushed a commit to gnoliyil/fuchsia that referenced this pull request
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
gnoliyil pushed a commit to gnoliyil/fuchsia that referenced this pull request
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
lnicola pushed a commit to lnicola/rust-analyzer that referenced this pull request
RalfJung pushed a commit to RalfJung/rust-analyzer that referenced this pull request
Labels
This issue / PR is in PFCP or FCP with a disposition to merge it.
The final comment period is finished for this PR / Issue.
This PR was explicitly merged by bors.
Marks issues that should be documented in the release notes of the next release.
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Relevant to the compiler team, which will review and decide on the PR/issue.