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

Start migration to the failure crate #4795

Merged
merged 1 commit into from
Dec 19, 2017
Merged

Conversation

alexcrichton
Copy link
Member

This commit is the initial steps to migrate Cargo's error handling from the
error-chain crate to the failure crate. This is intended to be a low-cost
(in terms of diff) transition where possible so it's note "purely idiomatic
failure crate" just yet.

The error-chain dependency is dropped in this commit and Cargo now canonically
uses the Error type from the failure crate. The main last remnant of
error-chain is a custom local extension trait to use chain_err instead of
with_context. I'll try to follow up with a commit that renames this later but
I wanted to make sure everything worked first! (and chain_err is used
practically everywhere).

Some minor tweaks happened in the tests as I touched up a few error messages
here and there but overall the UI of Cargo should be exactly the same before and
after this commit.

@rust-highfive
Copy link

r? @matklad

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton
Copy link
Member Author

r? @withoutboats

@rust-highfive rust-highfive assigned withoutboats and unassigned matklad Dec 8, 2017
@bors
Copy link
Contributor

bors commented Dec 12, 2017

☔ The latest upstream changes (presumably #4788) made this pull request unmergeable. Please resolve the merge conflicts.

@bors
Copy link
Contributor

bors commented Dec 18, 2017

☔ The latest upstream changes (presumably #4828) made this pull request unmergeable. Please resolve the merge conflicts.

@bors
Copy link
Contributor

bors commented Dec 18, 2017

☔ The latest upstream changes (presumably #4818) made this pull request unmergeable. Please resolve the merge conflicts.

}
}
}
// impl Error for CliError {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should delete?

links {
CrateRegistry(registry::Error, registry::ErrorKind);
}
pub trait CargoResultExt<T, E> {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why still have this instead of using failure's ResultExt?

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh this is purely transitionary, I wanted to make sure we got past the test at least before blanket renaming chain_err to with_context everywhere. I plan on doing that change after this PR lands (just to cut down on merge conflicts hopefully)

Copy link
Contributor

Choose a reason for hiding this comment

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

Sounds good!

@@ -76,7 +80,7 @@ pub fn read(path: &Path) -> CargoResult<String> {
}

pub fn read_bytes(path: &Path) -> CargoResult<Vec<u8>> {
(|| -> CargoResult<_> {
let res = (|| -> CargoResult<_> {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could also .map_err(Into::into) instead of this ?; Ok(res) stuff.

impl CargoError {
pub fn into_internal(self) -> Self {
CargoError(CargoErrorKind::Internal(Box::new(self.0)), self.1)
impl Fail for Internal {
Copy link
Contributor

Choose a reason for hiding this comment

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

Will keep in mind that this can't be derived and see if I could make it so it could be. :-)

description("failed to get a 200 response")
display("failed to get 200 response from `{}`, got {}", url, code)
}
// error_chain! {
Copy link
Contributor

Choose a reason for hiding this comment

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

Also could probably be deleted?

@@ -31,7 +31,8 @@ impl<'cfg> Registry for ReplacedSource<'cfg> {
}).chain_err(|| {
format!("failed to query replaced source {}",
self.to_replace)
})
})?;
Copy link
Contributor

Choose a reason for hiding this comment

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

could be .map_err(Into::into) if you don't want to do this two statement thing.

Copy link
Member Author

Choose a reason for hiding this comment

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

Indeed yeah! I'm not necessarily a huge fan of that, but I found the two-statement return wasn't so bad.

Copy link
Contributor

Choose a reason for hiding this comment

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

I have no opinion :-)

@alexcrichton
Copy link
Member Author

mk, updated!

Cargo.toml Outdated
@@ -24,7 +24,7 @@ crypto-hash = "0.3"
curl = "0.4.6"
docopt = "0.8.1"
env_logger = "0.4"
error-chain = "0.11.0"
failure = "0.1"
Copy link
Contributor

Choose a reason for hiding this comment

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

You use bail!, so this should be 0.1.1 in case some monster tries to say failure = "=0.1.0".

@withoutboats
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Dec 19, 2017

📌 Commit 595dfc5 has been approved by withoutboats

@bors
Copy link
Contributor

bors commented Dec 19, 2017

⌛ Testing commit 595dfc51ec4e92fcc178f991b38178074a01ab72 with merge 026e91333995ee1c23c22fe5dee4b46409d9affd...

This commit is the initial steps to migrate Cargo's error handling from the
`error-chain` crate to the `failure` crate. This is intended to be a low-cost
(in terms of diff) transition where possible so it's note "purely idiomatic
`failure` crate" just yet.

The `error-chain` dependency is dropped in this commit and Cargo now canonically
uses the `Error` type from the `failure` crate. The main last remnant of
`error-chain` is a custom local extension trait to use `chain_err` instead of
`with_context`. I'll try to follow up with a commit that renames this later but
I wanted to make sure everything worked first! (and `chain_err` is used
practically everywhere).

Some minor tweaks happened in the tests as I touched up a few error messages
here and there but overall the UI of Cargo should be exactly the same before and
after this commit.
@alexcrichton
Copy link
Member Author

@bors: r=withoutboats

@bors
Copy link
Contributor

bors commented Dec 19, 2017

📌 Commit 37cffbe has been approved by withoutboats

@bors
Copy link
Contributor

bors commented Dec 19, 2017

⌛ Testing commit 37cffbe with merge 868d373...

bors added a commit that referenced this pull request Dec 19, 2017
Start migration to the `failure` crate

This commit is the initial steps to migrate Cargo's error handling from the
`error-chain` crate to the `failure` crate. This is intended to be a low-cost
(in terms of diff) transition where possible so it's note "purely idiomatic
`failure` crate" just yet.

The `error-chain` dependency is dropped in this commit and Cargo now canonically
uses the `Error` type from the `failure` crate. The main last remnant of
`error-chain` is a custom local extension trait to use `chain_err` instead of
`with_context`. I'll try to follow up with a commit that renames this later but
I wanted to make sure everything worked first! (and `chain_err` is used
practically everywhere).

Some minor tweaks happened in the tests as I touched up a few error messages
here and there but overall the UI of Cargo should be exactly the same before and
after this commit.
@bors
Copy link
Contributor

bors commented Dec 19, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: withoutboats
Pushing 868d373 to master...

@bors bors merged commit 37cffbe into rust-lang:master Dec 19, 2017
@alexcrichton alexcrichton deleted the failure branch December 21, 2017 15:16
@ehuss ehuss added this to the 1.24.0 milestone Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants