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

refactor(toml): Decouple target discovery from Target creation #13701

Merged
merged 23 commits into from
Apr 5, 2024

Conversation

epage
Copy link
Contributor

@epage epage commented Apr 4, 2024

What does this PR try to resolve?

This builds on #13693 so that the resolving of targets is easier to pull out into resolve_toml in prep for fixing #13456

How should we test and review this PR?

Additional information

@epage epage marked this pull request as draft April 4, 2024 19:58
@rustbot
Copy link
Collaborator

rustbot commented Apr 4, 2024

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added A-manifest Area: Cargo.toml issues S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 4, 2024
@epage

This comment was marked as resolved.

@epage epage marked this pull request as ready for review April 4, 2024 21:47
@epage epage marked this pull request as draft April 5, 2024 01:07
src/cargo/util/toml/targets.rs Outdated Show resolved Hide resolved
src/cargo/util/toml/targets.rs Outdated Show resolved Hide resolved
src/cargo/util/toml/targets.rs Show resolved Hide resolved
@epage epage force-pushed the refactor branch 3 times, most recently from 051f7b1 to 01cce32 Compare April 5, 2024 17:42
@epage epage marked this pull request as ready for review April 5, 2024 17:43
src/cargo/util/toml/targets.rs Outdated Show resolved Hide resolved
Copy link
Member

@weihanglo weihanglo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks better. I was always confsued by the odd clean_target function name 😅.

Thanks for doing this!

@weihanglo
Copy link
Member

@bors r+

@bors
Copy link
Collaborator

bors commented Apr 5, 2024

📌 Commit ff41868 has been approved by weihanglo

It is now in the queue for this repository.

@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 Apr 5, 2024
@bors
Copy link
Collaborator

bors commented Apr 5, 2024

⌛ Testing commit ff41868 with merge 28e7b2b...

@bors
Copy link
Collaborator

bors commented Apr 5, 2024

☀️ Test successful - checks-actions
Approved by: weihanglo
Pushing 28e7b2b to master...

@bors bors merged commit 28e7b2b into rust-lang:master Apr 5, 2024
21 checks passed
@epage epage deleted the refactor branch April 5, 2024 20:33
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 6, 2024
Update cargo

9 commits in 0637083df5bbdcc951845f0d2eff6999cdb6d30a..28e7b2bc0a812f90126be30f48a00a4ada990eaa
2024-04-02 23:55:05 +0000 to 2024-04-05 19:31:01 +0000
- refactor(toml): Decouple target discovery from Target creation (rust-lang/cargo#13701)
- Don't depend on `?` affecting type inference in weird ways (rust-lang/cargo#13706)
- test(metadata): Show behavior with TOML-specific types (rust-lang/cargo#13703)
- fix: adjust tracing verbosity in list_files_git (rust-lang/cargo#13704)
- doc: comments on `PackageRegistry` (rust-lang/cargo#13698)
- Switch to using gitoxide by default for listing files (rust-lang/cargo#13696)
- Allow precise update to prerelease. (rust-lang/cargo#13626)
- refactor(toml): Split out an explicit step to resolve `Cargo.toml` (rust-lang/cargo#13693)
- chore(deps): update rust crate base64 to 0.22.0 (rust-lang/cargo#13675)

r? ghost
@rustbot rustbot added this to the 1.79.0 milestone Apr 6, 2024
bors added a commit that referenced this pull request Apr 29, 2024
fix(toml): Warn, rather than fail publish, if a target is excluded

### What does this PR try to resolve?

We have a couple of problems with publishing
- Inconsistent errors: if a target that `package` doesn't verify is missing `path`, it will error, while one with `path` won't, see #13456
- Users may want to exclude targets and their choices are
  - Go ahead and include them.  I originally excluded my examples before doc-scraping was a think.  The problem was if I had to set `required-features`, I then could no longer exclude them
  - Muck with `Cargo.toml` during publish and pass `--allow-dirty`

This fixes both by auto-stripping targets on publish.  We will warn the user that we did so.

This is a mostly-one-way door on behavior because we are turning an error case into a warning.
For the most part, I think this is the right thing to do.
My biggest regret is that the warning is only during `package`/`publish` as it will be too late to act on it and people who want to know will want to know when the problem is introduced.
The error is also very late in the process but at least its before a non-reversible action has been taken.
Dry-run and `yank` help.

Fixes #13456
Fixes #5806

### How should we test and review this PR?

Tests are added in the first commit and you can then follow the commits to see how the test output evolved.

The biggest risk factors for this change are
- If the target-stripping logic mis-identifies a path as excluded because of innocuous path differences (e.g. case)
- Setting a minimum MSRV for published packages: `auto*` were added in 1.27 (#5335) but were insta-stable.  `autobins = false` did nothing until 1.32 (#6329).  I have not checked to see how this behaves pre-1.32  or pre-1.27.  Since my memory of that error is vague, I believe it will either do a redundant discovery *or* it will implicitly skip discovery

Resolved risks
- #13729 ensured our generated target paths don't have `\` in them
- #13729 ensures the paths are normalize so the list of packaged paths

For case-insensitive filesystems, I added tests to show the original behavior (works locally but will fail when depended on from a case-sensitive filesystem) and tracked how that changed with this PR (on publish warn that those targets are stripped).  We could try to normalize the case but it will also follow symlinks and is likely indicative of larger casing problems that the user had.  Weighing how broken things are now , it didn't seem changing behavior on this would be too big of a deal.

We should do a Call for Testing when this hits nightly to have people to `cargo package` and look for targets exclusion warnings that don't make sense.

### Additional information

This builds on #13701 and the work before it.

By enumerating all targets in `Cargo.toml`, it makes it so rust-lang/crates.io#5882 and rust-lang/crates.io#814 can be implemented without any other filesystem interactions.

A follow up PR is need to make much of a difference in performance because we unconditionally walk the file system just in case `autodiscover != Some(false)` or a target is missing a `path`.

We cannot turn off auto-discovery of libs, so that will always be done for bin-only packages.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-manifest Area: Cargo.toml issues 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