-
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
non-blocking build error reported in example code since 0d62ae2 #13724
Comments
Can you share the repo where this happened or create an example? It would help in debugging what is going on. |
Sorry, unfortunately it's a private corp repo :/ I may be able to do an example, tho I am not quite sure what all causes this... |
@Muscraft Here is a test demonstrating it: #[cargo_test]
fn invalid_name_in_git_repo() {
// Checks to ignore invalid package name in git repository.
let git_project = git::new("bar", |p| {
p.file("Cargo.toml", &basic_manifest("bar", "1.0.0"))
.file("src/lib.rs", "")
.file(
"dont_look_at_me/Cargo.toml",
r#"
[package]
name = "{{project_name}}"
version = "1.0.0"
edition = "2021"
"#,
)
.file("dont_look_at_me/src/lib.rs", "")
});
let p = project()
.file(
"Cargo.toml",
&format!(
r#"
[package]
name = "foo"
version = "1.0.0"
edition = "2021"
[dependencies]
bar = {{ git = "{}" }}
"#,
git_project.url()
),
)
.file("src/lib.rs", "")
.build();
p.cargo("fetch")
.with_stderr(
"\
[UPDATING] git repository `[..]`
error: invalid character `{` in package name: `{{project_name}}`, \
the first character must be a Unicode XID start character (most letters or `_`)
--> [..]/dont_look_at_me/Cargo.toml:3:28
|
3 | name = \"{{project_name}}\"
| ^^^^^^^^^^^^^^^^^^
|
[LOCKING] 2 packages
",
)
.run();
} I would generally expect it to ignore packages it cannot parse, unless it is unable to find the requested package. Errors are supposed to be deferred here and not shown unless it fails. Perhaps the new diagnostics aren't getting accumulated? |
Thanks so much, that's better and faster than what I would've done! |
So from what I understand of this situation is that this is superficial though misleading in a very negative way. As for the change. We switched from reporting the error exclusively through In terms of fixes.
|
Looking a bit more into this. Doing this would likely also fix:
The idea would be that we walk the filesystem, finding The biggest problem is with What if we changed |
One way to reduce the sympton is to reduce how much we walk in git sources. In #10752 (comment) we talked about a breadcrumb to switch our walking from recursive directory walking to workspace loading. This would reduce the chance of seeing duplicate package name warnings and reduce the parse errors reported because most of those are likely coming from test or example cases underneath a workspace. I wonder if we could switch to this model without requiring a breadcrumb... |
fix(source): Don't warn about unreferenced duplicate packages ### What does this PR try to resolve? This also improves the message, consolidating multiple duplicates and saying which was loaded instead, as it naturally fell out of the design Fixes #10752 ### How should we test and review this PR? ### Additional information We're still subject to #13724 and fully load every manifest, even if we don't use it. I'm exploring that topic at https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Redundant.20code.20in.20.60GitSouce.60.3F/near/450783427 This change builds on - #13993 - #14169 - #14231 - #14234
#14395 is tracking the performance optimization that would reduce the chance of seeing an error. |
Problem
We're seeing the following error during a
cargo build
:This started with Rust 1.77, and I bisected it to commit 0d62ae2. That one looks to really just show errors differently, so I don't know if it caused our error or just surfaced it. The build is not affected, because it's just the
cargo-generator
code for some of our stuff. That path not in any of our workspace manifests, I think cargo just finds it bywalk
ing the source files of our crate and finds the templated Cargo.toml.Steps
No response
Possible Solution(s)
We can move the templated stuff out of our repo and somewhere else, but since it's a change in behavior, I wanted to flag it.
Notes
Happy to consider any other workarounds to make cargo ignore that part of our source. Thanks!
Version
The text was updated successfully, but these errors were encountered: