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.

Sign up for GitHub

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

Jump to bottom

Error when setting crate type of both dylib and cdylib in library #10243

Merged
merged 1 commit into from
Jan 18, 2022
Merged

Error when setting crate type of both dylib and cdylib in library #10243

merged 1 commit into from
Jan 18, 2022

Conversation

Rustin170506
Copy link
Member

@Rustin170506 Rustin170506 commented Jan 1, 2022 •
edited
Loading

close #10231

Error when setting crate type of both dylib and cdylib in library. Cargo can't support that at this time, since they both output the same filename.

@rust-highfive
Copy link

r? @ehuss

(rust-highfive has picked a reviewer for you, use r? to override)

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

ehuss commented Jan 1, 2022

Thanks for the pr, however this isn't quite what I meant in #10231 (comment). Cargo should only present an error for a library that defines both a dylib and cdylib crate type. I think maybe the validation could go in clean_lib, though I'm not sure.

@ehuss ehuss added S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 4, 2022
@Rustin170506
Error when setting crate type of both dylib and cdylib in library
3738002 
Signed-off-by: hi-rustin <rustin.liu@gmail.com>
@Rustin170506 Rustin170506 changed the title Make output filename collision be an error Error when setting crate type of both dylib and cdylib in library Jan 16, 2022
@Rustin170506
Copy link
Member Author

@rustbot label +S-waiting-on-author -S-waiting-on-review

@rustbot
Copy link
Collaborator

rustbot commented Jan 16, 2022

Error: The feature relabel is not enabled in this repository.
To enable it add its section in the triagebot.toml in the root of the repository.

Please let @rust-lang/release know if you're having trouble with this bot.

@Rustin170506
Copy link
Member Author

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. labels Jan 17, 2022
@alexcrichton
Copy link
Member

This seems reasonable to me, although I'm slightly wary of making "working" code before break afterwards. I think it's ok in this case though since the behavior before was pretty odd with both artifacts overriding one another.

I'm not 100% sure that this is what you originally envisioned @ehuss but as-is it looks reasonable to merge to me.

@ehuss
Copy link
Contributor

ehuss commented Jan 18, 2022

Looks good to me, thanks!

@bors r+

@bors
Copy link
Contributor

bors commented Jan 18, 2022

📌 Commit 3738002 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 Jan 18, 2022
@bors
Copy link
Contributor

bors commented Jan 18, 2022

⌛ Testing commit 3738002 with merge 95bb3c9...

@bors
Copy link
Contributor

bors commented Jan 18, 2022

☀️ Test successful - checks-actions
Approved by: ehuss
Pushing 95bb3c9 to master...

@bors bors merged commit 95bb3c9 into rust-lang:master Jan 18, 2022
@ehuss ehuss mentioned this pull request Jan 19, 2022
Merged
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 19, 2022
@bors
Auto merge of rust-lang#93063 - ehuss:update-cargo, r=ehuss
2f004d2 
Update cargo

16 commits in 358e79fe56fe374649275ca7aebaafd57ade0e8d..95bb3c92bf516017e812e7f1c14c2dea3845b30e
2022-01-04 18:39:45 +0000 to 2022-01-18 17:39:35 +0000
- Error when setting crate type of both dylib and cdylib in library (rust-lang/cargo#10243)
- Include `help` in `--list` (rust-lang/cargo#10300)
- Add report subcommand to bash completion. (rust-lang/cargo#10295)
- Downgrade some log messages. (rust-lang/cargo#10296)
- Enable shortcut for triage bot (rust-lang/cargo#10298)
- Bump to 0.61.0, update changelog (rust-lang/cargo#10294)
- use new cargo fmt option (rust-lang/cargo#10291)
- Add `run-fail` to semver-check for docs (rust-lang/cargo#10287)
- Use `is_symlink()` method (rust-lang/cargo#10290)
- Stabilize namespaced and weak dependency features. (rust-lang/cargo#10269)
- Port cargo to clap3 (rust-lang/cargo#10265)
- feat: support rustflags per profile (rust-lang/cargo#10217)
- Make bors ignore the PR template so it doesn't end up in merge messages (rust-lang/cargo#10267)
- Be resilient to most IO error and filesystem loop while walking dirs (rust-lang/cargo#10214)
- Remove the option to disable pipelining (rust-lang/cargo#10258)
- Always ask rustc for messages about artifacts, and always process them (rust-lang/cargo#10255)
github-actions bot pushed a commit to gnoliyil/fuchsia that referenced this pull request Jan 25, 2022
@erickt
[cargo-gnaw] Tweak tests to fix cargo roll
dc3c82b 
In rust-lang/cargo#10243, cargo was changed to
disallow crate-types that produce the same filename. This can happen
with `lib` and `rlib`, or `dylib` and `cdylib`. This changes the
`multiple_crate_type` to split out these into multiple sub-crates.

Note that because cargo-gnaw currently only supports generating rules
for `lib` types, we don't produce anything for the
`sub-crate-with-rlib`.

Change-Id: Id1c15e884de228f9024a6df1fc315e03a4a33bb4
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/637408
Fuchsia-Auto-Submit: Erick Tryzelaar <etryzelaar@google.com>
Reviewed-by: Adam Perry <adamperry@google.com>
Commit-Queue: Auto-Submit <auto-submit@fuchsia-infra.iam.gserviceaccount.com>
@ehuss ehuss added this to the 1.60.0 milestone Feb 14, 2022
ehuss added a commit to ehuss/cargo_metadata that referenced this pull request Feb 15, 2022
@ehuss
Fix tests due to dylib/cdylib error.
1dcb1d2 
Cargo no longer allows to set both cdylib and dylib at the same time
(since it didn't work): rust-lang/cargo#10243
@ehuss ehuss mentioned this pull request Feb 15, 2022
Merged
ehuss added a commit to ehuss/cargo_metadata that referenced this pull request Feb 15, 2022
@ehuss
Fix tests due to dylib/cdylib error.
b368f3e 
Cargo no longer allows to set both cdylib and dylib at the same time
(since it didn't work): rust-lang/cargo#10243
@dtolnay dtolnay mentioned this pull request Dec 18, 2022
Merged
bors added a commit that referenced this pull request Dec 18, 2022
@bors
Auto merge of #11498 - dtolnay-contrib:relabel, r=ehuss
9f4efa5 
Enable triagebot's relabel functionality

### What does this PR try to resolve?

This fixes the following failure that rustbot currently posts whenever someone tries to use "<b>`@</b><b>rustbot</b>` label" in this repository.

> **Error**: The feature `relabel` is not enabled in this repository.
> To enable it add its section in the `triagebot.toml` in the root of the repository.

Unauthenticated relabel has been enabled in rust-lang/rust for nearly 4 years. People overwhelmingly use it in good faith.

<br>

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

Compare against https://github.com/rust-lang/rust/blob/1.66.0/triagebot.toml.

Also skim through the 7 pages of labels on https://github.com/rust-lang/cargo/labels, whether it makes sense the ones I decided to allow arbitrary GitHub users to apply.

<br>

### Additional information

Attempted uses of "<b>`@</b><b>rustbot</b>` label", that failed, but this PR would allow:

- #10343 (comment)
- #10243 (comment)
- #9982 (comment)
- #9128 (comment)
- #9067 (comment)
- #8441 (comment)
- #11432 (comment)
- #8841 (comment)
- #10820 (comment)
- #10572 (comment)
- #9114 (comment)
- #8980 (comment)
- #9064 (comment)
- #8726 (comment)
- #8089 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@ehuss ehuss

Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Milestone
1.60.0
Development

Successfully merging this pull request may close these issues.

Colliding filenames cause a panic when a build is re-run
6 participants
@Rustin170506 @rust-highfive @ehuss @rustbot @alexcrichton @bors