Skip to content
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 use of .. in dep-info-basedir #10281

Merged
merged 1 commit into from
May 7, 2022
Merged

Conversation

Gnurfos
Copy link

@Gnurfos Gnurfos commented Jan 11, 2022

Summary

This allows setting, in .cargo/config's dep-info-basedir, some relative path that goes above the crate's directory.

Motivation

In a setup like this:

repo_root
├── Makefile
├── some_c_things
│   └── foo.c
└── rust_things
    ├── Cargo.toml
    └─── src
        └── lib.rs

If you want the generated .d files to be includable directly in the Makefile (without post-processing), you need them to mention paths relative to the root, like:

rust_things/target/....: rust_things/src/lib.rs

Implementation

For this you need to have relative paths with parent directories (in this case ..) in dep-info-basedir, which does not work without the change in this PR (due to render_filename doing only strip_prefix, while the basedir still contains literal ..s).

Let me know if this change is acceptable. Another implementation could be to canonicalize in ConfigRelativePath::resolve_path instead, especially since that struct outputs absolute paths. But that would have it access the filesystem, while it currently doesn't.

@rust-highfive
Copy link

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) soon.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 11, 2022
@Gnurfos
Copy link
Author

Gnurfos commented Jan 11, 2022

Hi, @ehuss , I'm having trouble getting this to work for Windows, due to canonicalize there converting to an "extended path", while I need to support non-existing files (as per the pre-existing test) which cannot be canonicalized.
Is it problematic if my changes are made unix-only ? (the behaviour of canonicalize might change in the future)

@ehuss
Copy link
Contributor

ehuss commented Jan 11, 2022

Using fs::canonicalize is generally problematic and we try to avoid it as much as possible. It does need to support Windows, so you'll need to find some way around that. Maybe something like normalize_path could be used?

@Gnurfos
Copy link
Author

Gnurfos commented Jan 12, 2022

Thanks, I got it to work with normalize_path. It's not great that it doesn't follow symlinks, but I suppose it will fit most people's use cases. Better to have it work on Windows and use a centralized function

@ehuss
Copy link
Contributor

ehuss commented May 7, 2022

Thanks!

@bors r+

@bors
Copy link
Contributor

bors commented May 7, 2022

📌 Commit e5ff81b has been approved by ehuss

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 7, 2022
@bors
Copy link
Contributor

bors commented May 7, 2022

⌛ Testing commit e5ff81b with merge 9fa2bba...

@bors
Copy link
Contributor

bors commented May 7, 2022

☀️ Test successful - checks-actions
Approved by: ehuss
Pushing 9fa2bba to master...

@bors bors merged commit 9fa2bba into rust-lang:master May 7, 2022
bors added a commit to rust-lang-ci/rust that referenced this pull request May 12, 2022
Update cargo

20 commits in a44758ac805600edbb6ba51e7e6fb81a6077c0cd..3f052d8eed98c6a24f8b332fb2e6e6249d12d8c1
2022-05-04 02:29:34 +0000 to 2022-05-12 15:19:04 +0000
- pre-stabilization documentation for workspace inheritance (rust-lang/cargo#10659)
- test: Make curr_dir work in/out of workspace (rust-lang/cargo#10658)
- Fix no_cross_doctests race condition. (rust-lang/cargo#10660)
- Fix typo (rust-lang/cargo#10657)
- feat(install): Support `foo@version` like cargo-add (rust-lang/cargo#10650)
- fix typos found by the `typos-cli` crate (rust-lang/cargo#10649)
- feat(yank): Support foo@version like cargo-add (rust-lang/cargo#10597)
- add `cargo-features` to unstable docs for workspace inheritance (rust-lang/cargo#10648)
- Use the traits added to the Rust 2021 Edition prelude (rust-lang/cargo#10646)
- Pass `--target` to `rustdoc` for `cargo test` if specified with host target. (rust-lang/cargo#10594)
- Fix use of .. in dep-info-basedir (rust-lang/cargo#10281)
- fix some typos (rust-lang/cargo#10639)
- Move snapshot tests into testsuite (rust-lang/cargo#10638)
- Improve support of condition compilation checking (rust-lang/cargo#10566)
- When documenting private items in a binary, ignore warnings about links to private items (rust-lang/cargo#10142)
- Extend pkgid syntax with ``@`` support (rust-lang/cargo#10582)
- move one `snapshot/add` test into `testsuite/cargo_add/` (rust-lang/cargo#10631)
- Add caveat for covering features (rust-lang/cargo#10605)
- Improve CARGO_ENCODED_RUSTFLAGS and CARGO_ENCODED_RUSTDOCFLAGS variables docs (rust-lang/cargo#10633)
- reorganize `snapshot` tests to better work in contexts that sort by extension (rust-lang/cargo#10629)
@ehuss ehuss added this to the 1.62.0 milestone May 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants