Don’t swallow virtual manifest parsing errors #4828
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Before this change, `cargo::util::toml::do_read_manifest` ended like this:
```rust
return match TomlManifest::to_real_manifest(/* … */) {
Ok(/* … */) => /* … */,
Err(e) => match TomlManifest::to_virtual_manifest(/* … */) {
Ok(/* … */) => /* … */,
Err(..) => Err(e),
}
};
```
Errors returned by `to_virtual_manifest` were always ignored.
As a result, when something was wrong in a virtual manifest,
Cargo would unhelpfully exit with no more output than:
```
error: failed to parse manifest at `/tmp/a/Cargo.toml`
Caused by:
no `package` section found.
```
http://doc.crates.io/manifest.html#virtual-manifest defines
a virtual manifest as “the `package` table is not present”,
so let’s first determine if a manifest is virtual based
on that criteria, and then only call one of the two methods.
Although it is not mentioned in the documentation,
`[project]` seems to be in the code an alias for `[package]`.
So let’s preserve that here too.
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
By the way, this is unrelated to the point of this PR but the code being modified also implements a “unused manifest key”, but only for non-virtual manifest. Is there a reason for that, or should the warning also apply to virtual manifests? |
|
@bors: r+ Looks great, thanks! Also yeah seems plausible to me to warn about unused keys on virtual manifests as well! |
|
📌 Commit 3e06033 has been approved by |
bors
added a commit
that referenced
this pull request
Dec 18, 2017
Don’t swallow virtual manifest parsing errors
Before this change, `cargo::util::toml::do_read_manifest` ended like this:
```rust
return match TomlManifest::to_real_manifest(/* … */) {
Ok(/* … */) => /* … */,
Err(e) => match TomlManifest::to_virtual_manifest(/* … */) {
Ok(/* … */) => /* … */,
Err(..) => Err(e),
}
};
```
Errors returned by `to_virtual_manifest` were always ignored. As a result, when something was wrong in a virtual manifest, Cargo would unhelpfully exit with no more output than:
```
error: failed to parse manifest at `/tmp/a/Cargo.toml`
Caused by:
no `package` section found.
```
http://doc.crates.io/manifest.html#virtual-manifest defines a virtual manifest as “the `package` table is not present”, so let’s first determine if a manifest is virtual based on that criteria, and then only call one of the two methods.
Although it is not mentioned in the documentation, `[project]` seems to be in the code an alias for `[package]`. So let’s preserve that here too.
|
☀️ Test successful - status-appveyor, status-travis |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Before this change,
cargo::util::toml::do_read_manifestended like this:Errors returned by
to_virtual_manifestwere always ignored. As a result, when something was wrong in a virtual manifest, Cargo would unhelpfully exit with no more output than:http://doc.crates.io/manifest.html#virtual-manifest defines a virtual manifest as “the
packagetable is not present”, so let’s first determine if a manifest is virtual based on that criteria, and then only call one of the two methods.Although it is not mentioned in the documentation,
[project]seems to be in the code an alias for[package]. So let’s preserve that here too.