You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Instead of letting Cargo decide whether or not to sanitise debuginfo based on -C split-debuginfo setting (which necessitated Cargo feeding different arguments to rustc depending on that codegen option), explicit scopes unsplit-debuginfo and split-debuginfo are now created to target only embedded and split debuginfo respectively. unsplit-debuginfo does nothing when the debuginfo is split, and split-debuginfo does nothing when the debuginfo is unsplit.
Instead of numbers, the value of trim-paths is now descriptive words (or list of words) that is passed through directly to --remap-path-scopes. This is achieved by extending --remap-path-scope to take in aliases such as object = macro,unsplit-debuginfo,split-debuginfo-file (default for release profiles). Note that this does not make trim-paths a simple pass through to rustc like most other profile options, because Cargo needs to generate and emit the actual path mappings via --remap-path-prefix when trim-paths is not none.
Since most of the implementation complexities will be in rustc and not Cargo, I really want to hear what @rust-lang/compiler thinks about this (I know you guys are busy 😅)
About this issue
This issue corresponds to a meeting proposal for the compiler team steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.
Comment policy
These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).
The text was updated successfully, but these errors were encountered:
Meeting proposal info
Summary
Discuss rust-lang/rfcs#3127
From rust-lang/rfcs#3127 (comment) :
About this issue
This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.
Comment policy
These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).
The text was updated successfully, but these errors were encountered: