-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Cargo.lock generation matches LF/CRLF line endings #13339
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @epage (or someone else) soon. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I misunderstood but this goes in a different direction than what is discussed in #12897 and I would recommend proposing it there and for us to resolve that before moving forward with an implementation review.
This is preparation for rust-lang#13339 and covers hot spots I found as well as areas currently covered by `profile::start(...)`. This is split out to avoid conflicts while working through the remaining issues for rust-lang#13339. Maybe it will also serve to help debugging...
fix(cli): Trace core cargo operations ### What does this PR try to resolve? This is preparation for #13339 and covers hot spots I found as well as areas currently covered by `profile::start(...)`. This is split out to avoid conflicts while working through the remaining issues for #13339. Maybe it will also serve to help debugging... ### How should we test and review this PR? ### Additional information ```console $ rg profile::start src/ src/cargo/ops/cargo_compile/mod.rs: let _p = profile::start("compiling"); src/cargo/ops/resolve.rs: let _p = profile::start("resolving with overrides..."); src/cargo/util/rustc.rs: let _p = profile::start("Rustc::new"); src/cargo/core/global_cache_tracker.rs: let _p = crate::util::profile::start("cleaning global cache files"); src/cargo/core/global_cache_tracker.rs: let _p = crate::util::profile::start("global cache db sync"); src/cargo/core/global_cache_tracker.rs: let _p = crate::util::profile::start(format!( src/cargo/core/global_cache_tracker.rs: let _p = crate::util::profile::start(format!("update db for removed {table_name}")); src/cargo/core/global_cache_tracker.rs: let _p = crate::util::profile::start(format!( src/cargo/core/global_cache_tracker.rs: let _p = crate::util::profile::start("populate untracked crate"); src/cargo/core/global_cache_tracker.rs: let _p = crate::util::profile::start(format!("populate untracked {table_name}")); src/cargo/core/global_cache_tracker.rs: let _p = crate::util::profile::start(format!("update NULL sizes {table_name}")); src/cargo/core/global_cache_tracker.rs: let _p = crate::util::profile::start("saving last-use data"); src/cargo/core/resolver/features.rs: let _p = profile::start("resolve features"); src/cargo/core/resolver/mod.rs: let _p = profile::start("resolving"); src/cargo/core/compiler/fingerprint/mod.rs: let _p = profile::start(format!( src/cargo/core/compiler/mod.rs: let p = profile::start(format!("preparing: {}/{}", unit.pkg, unit.target.name())); src/cargo/core/compiler/build_runner/mod.rs: let _p = profile::start("preparing layout"); src/cargo/core/compiler/custom_build.rs: let _p = profile::start(format!( src/cargo/core/compiler/job_queue/mod.rs: let _p = profile::start("executing the job graph"); ```
This is preparation for rust-lang#13339 and covers hot spots I found as well as areas currently covered by `profile::start(...)`. This is split out to avoid conflicts while working through the remaining issues for rust-lang#13339. Maybe it will also serve to help debugging...
What does this PR try to resolve?
This PR attempts to resolve issue #12897. If a Cargo.toml is present, it detects if a CRLF line ending ends the first line, and then outputs the corresponding line ending when generating the lockfile.
How should we test and review this PR?
The additional test should test for the CRLF adherence, just as the
preserve_line_endings_issue_2076
test used to do before we started testing for equality based on lines.Additional Notes
If this approach proves successful, the
Emitter
struct could be used to ensure compliance in other auto-generated files that contain line endings that should maintain the previous line ending style, such as thecargo add
bug discussed in the issue #12897 thread.