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

Housekeeping - nothing to see here, move along #90

Merged
merged 4 commits into from
Aug 14, 2018

Conversation

mati865
Copy link
Contributor

@mati865 mati865 commented Aug 7, 2018

  1. std::env::home_dir() was lying about it's functionality: Deprecate std::env::home_dir and fix incorrect documentation rust-lang/rust#51656
  2. As always: new features/bugs, bug fixes, performance improvements. It would be boring but regex gained ability to detect and use SIMD on supported machines: rust-lang/regex@e455d53
    Before:
 elfx86exts target/release/cargo-install-update 
MODE64 (call)
CMOV (cmovb)
SSE1 (movups)
SSE2 (movdqu)

After:

 elfx86exts target/release/cargo-install-update
MODE64 (call)
CMOV (cmovb)
SSE1 (movups)
SSE2 (movdqu)
AVX (vxorps)
AVX2 (vpcmpeqd)
SSSE3 (pshufb)
  1. Clippy wants to help saving those miliseconds
  2. Rustfmt now sorts lines which begin with use keyword, there is option (disabled by default) to do the same for extern crate

I can squash commits if you want.

mati865 added 2 commits August 7, 2018 23:00
New regex enables SIMD on supported plaftorms.
Copy link
Owner

@nabijaczleweli nabijaczleweli left a comment

Choose a reason for hiding this comment

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

Thank you for doing this (and taking the time to gnome this repo when I don't've the strength to, I genuinely appreciate it a tremendous lot ❤️).

Re: squashing: unnecessary, this is really well split into self-contained chunks 👍

I'd some, mainly stylistic, nitpicks, (would feel silly to immediately revert an entire commit at merge, when I put my dumb pedantry in :Р).

@@ -59,7 +59,7 @@ fn actual_main() -> Result<(), i32> {
if !search_res.success() {
return Err(search_res.code().unwrap_or(-1));
}
println!("");
Copy link
Owner

Choose a reason for hiding this comment

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

I'm pretty sure this code pre-dates zero-arg writeln!()s :Р
Good catch 👍

src/ops/mod.rs Outdated
@@ -340,7 +340,7 @@ impl GitRepoPackage {
GitRepoPackage {
name: c.get(1).unwrap().as_str().to_string(),
url: url.into_string(),
branch: branch,
branch,
Copy link
Owner

Choose a reason for hiding this comment

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

I'd actually rather this stay explicit, as it's more aesthetically pleasing, if you please.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll revert this change and disable the lint.

src/options.rs Outdated
@@ -225,7 +225,7 @@ fn cargo_dir() -> (String, PathBuf) {
}
}

fn existing_dir_validator(label: &str, s: String) -> Result<(), String> {
fn existing_dir_validator(label: &str, s: &str) -> Result<(), String> {
fs::canonicalize(&s).map(|_| ()).map_err(|_| format!("{} directory \"{}\" not found", label, s))
Copy link
Owner

Choose a reason for hiding this comment

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

There's little difference here though, innit, seeing as the string will've gotten drop()ped by the end of the caller's line anyway, but good idiomaticity catch 👍

(Although, does it work with fs::canonicalise(s) here? Seems superiour, innit?)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't remember if I tried fs::canonicalise(s) but yeah looks like it should work.

@@ -1,10 +1,9 @@
extern crate cargo_update;
extern crate tabwriter;

use std::io::{Write, stdout};
use tabwriter::TabWriter;
use std::io::{stdout, Write};
use std::process::exit;
Copy link
Owner

Choose a reason for hiding this comment

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

I'd actually rather this commit dropped, consider the width-priority ordering superiour.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fine, I'll disable use sorting in rustfmt config.

@mati865
Copy link
Contributor Author

mati865 commented Aug 12, 2018

I'd some, mainly stylistic, nitpicks, (would feel silly to immediately revert an entire commit at merge, when I put my dumb pedantry in :Р).

That's the point of the reviews 😉
I'll address it on the Monday probably.

Maybe instead of blindly bumping minimal versions it'd better to add CI checking whether the crates in said versions are buildable rust-lang/cargo#5657?

@nabijaczleweli
Copy link
Owner

I'm not sure if I'm extremely dumb (yes), extremely tired (hardly), or if the way the feature's explained just doesn't click for me (probably) but I somehow don't get what it does?

@mati865
Copy link
Contributor Author

mati865 commented Aug 13, 2018

Versions declared in Cargo.toml are in fact "minimal supported versions". Cargo will automatically use latest compatible version, consider this example:

[dependencies]
foo = "1.0"

You are declaring this crate will work with versions: 1.0 >= foo < 2.0.
It's not always possible to use latests versions like Cargo does by default so we have two hypothetical environments:

  1. Cargo uses latest foo = "1.1", everything works fine.
  2. Cargo uses older but declared to work foo = "1.0", everything works fine.

Then you start using foo::x without noticing it was added in foo = "1.1" and Cargo.toml still points to foo = "1.0":

  1. Cargo uses latest foo = "1.1", everything works fine.
  2. Cargo uses older but declared to work foo = "1.0" and user gets the compilation error.

There is ongoing effort to mitigate it by adding CI job with -Z minimal-versions to make sure we are not lying about supported dependencies versions. Another less nice solution is to always declare latest versions, "if we support only the latest version we cannot be lying about earlier versions".

@mati865
Copy link
Contributor Author

mati865 commented Aug 13, 2018

Updated libgit2 should fix #92

@nabijaczleweli nabijaczleweli merged commit 9109bdf into nabijaczleweli:master Aug 14, 2018
@nabijaczleweli
Copy link
Owner

nabijaczleweli commented Aug 14, 2018

Released in v1.6.2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants