-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Try to better handle restricted crate names. #7959
Conversation
I know making some of these changes to errors might be a little aggressive, so I'd be happy to discuss dialing it back. Particularly the package name starting with numbers. |
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.
This does feel a bit aggressive but I think it's also fine to try this out and see what the warnings look like. I left a few inline comments but overall looks great, thanks!
"{} target `{}` is a reserved Windows filename, \ | ||
this target will not work on Windows platforms", | ||
target_kind_human, name | ||
)); |
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.
Hm can you clarify this a bit for me? How come we'd only issue this warning on windows, and how comit it applies to all targets? It should be ok to have a library called con
, right? I don't think that creates any of the bad file names?
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.
My thinking for only showing on Windows is: if someone wants to create an executable called con
, and they never intend for it to be used on Windows, then that would create a warning that they cannot silence. Maybe if we had the "compatibility" table we discussed at the last meeting, we could warn on all platforms and then allow the warning to be silenced by specifying that it is incompatible with windows?
FWIW, I scanned all of crates.io, and didn't find any targets with a reserved name. Part of this came up with a user on Discord who had a package named prune
with a binary named prn
, and was confused when their Windows CI failed. I don't think they've published to crates.io, though.
As for libraries, in some situations rustc creates filenames like con.tr1cof326ip8vwg.rcgu.o
which fail on windows. It also seems like it would just be a risky thing to do, and I didn't want to put in effort and complexity to handle that edge case, which is pretty far on the edge.
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.
Oh for sure binaries make sense here, I was just confused about the library part. The point about crate names showing up in object files makes sense though!
pub fn is_windows_reserved(name: &str) -> bool { | ||
[ | ||
"con", "prn", "aux", "nul", "com1", "com2", "com3", "com4", "com5", "com6", "com7", "com8", | ||
"com9", "lpt1", "lpt2", "lpt3", "lpt4", "lpt5", "lpt6", "lpt7", "lpt8", "lpt9", |
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.
So just to clarify, lpt9.foobarbazhello
is an invalid filename on Windows?
All of these are invalid as the filestem of a file anywhere on Windows?
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.
Correct on the extension.
As for "anywhere", that's a bit of a stretch. It is possible to create these files, like with cygwin tools which use different APIs, but those files end up causing problems with the rest of the Windows ecosystem.
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.
Ah ok, thanks for clarifying! I agree yeah that I've seen these "work" in some contexts but it gets really weird when only some contexts have them work and others don't.
@bors: r+ |
📌 Commit 2a874aa has been approved by |
☀️ Test successful - checks-azure |
Update cargo Update cargo 21 commits in bda50510d1daf6e9c53ad6ccf603da6e0fa8103f..7019b3ed3d539db7429d10a343b69be8c426b576 2020-03-02 18:05:34 +0000 to 2020-03-17 21:02:00 +0000 - Run through clippy (rust-lang/cargo#8015) - Fix config profiles using "dev" in `cargo test`. (rust-lang/cargo#8012) - Run CI on all PRs. (rust-lang/cargo#8011) - Add unit-graph JSON output. (rust-lang/cargo#7977) - Split workspace/validate() into multiple functions (rust-lang/cargo#8008) - Use Option::as_deref (rust-lang/cargo#8005) - De-duplicate edges (rust-lang/cargo#7993) - Revert "Disable preserving mtimes on archives" (rust-lang/cargo#7935) - Close the front door for clippy but open the back (rust-lang/cargo#7533) - Fix CHANGELOG.md typos (rust-lang/cargo#7999) - Update changelog note about crate-versions flag. (rust-lang/cargo#7998) - Bump to 0.45.0, update changelog (rust-lang/cargo#7997) - Bump libgit2 dependencies (rust-lang/cargo#7996) - Avoid buffering large amounts of rustc output. (rust-lang/cargo#7838) - Add "Updating" status for git submodules. (rust-lang/cargo#7989) - WorkspaceResolve: Use descriptive lifetime label. (rust-lang/cargo#7990) - Support old html anchors in manifest chapter. (rust-lang/cargo#7983) - Don't create hardlink for library test and integrations tests, fixing rust-lang/cargo#7960 (rust-lang/cargo#7965) - Partially revert change to filter debug_assertions. (rust-lang/cargo#7970) - Try to better handle restricted crate names. (rust-lang/cargo#7959) - Fix bug with new feature resolver and required-features. (rust-lang/cargo#7962)
63: Add a prefix to each package names to adapt to rust-lang/cargo#7959 r=qryxip a=qryxip Fixes #62. bors r+ Co-authored-by: Ryo Yamashita <qryxip@gmail.com>
Add --name suggestion for cargo new Resolves #8613 Since `check_name` have already got a parameter to show name help, I reuse the logic and sync the behavior between `cargo init` and `cargo new`. The divergence seems to be intentionally made in #7959: _...Only print the --name suggestion for `cargo init`._ Feel free to discuss.
This attempts to improve handling of restricted crate names, particularly for
cargo new
andcargo init
. Hopefully the code is straightforward to follow, but in summary the changes are:General changes
cargo new
. crates.io also rejects numbers. Numbers are also not valid crate names.-
. This is a somewhat arbitrary change, but seems like it would stem problems. crates.io also rejects this.cargo package/publish
: Warn if a special Windows name is in the package.cargo new/init specific changes
--name
suggestion forcargo init
. I found the suggestion confusing, and I feel like it doesn't really make sense forcargo new
(since it would only affect the directory name).