Cargo install ripgrep command fails

[vibhutisawant]

Problem

I have installed rust 1.28.0 on ubuntu:16.04 (arch:x86_64) using https://static.rust-lang.org/dist/rust-1.28.0-x86_64-unknown-linux-gnu.tar.gz
However the ripgrep installation fails with several of these errors in series as follows.

error[E0494]: cannot refer to the interior of another static, use a constant instead
   --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/encoding_rs-0.8.14/src/lib.rs:928:42
    |
928 |     variant: VariantEncoding::SingleByte(&data::SINGLE_BYTE_DATA.ibm866, 0x0440, 96, 16),
    |                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Steps
cargo install ripgrep

Notes
Output of cargo version:
cargo 1.28.0 (96a2c7d 2018-07-13)

rust version
rustc 1.28.0 (9634041f0 2018-07-30)

[dwijnand]

Interesting.

The latest ripgrep at this time is 0.10.0: https://crates.io/crates/ripgrep
Which does indeed define 1.28.0 as the minimal rust version: https://github.com/BurntSushi/ripgrep/blob/0.10.0/.travis.yml#L65
Which ran successfully 4 months ago: https://travis-ci.org/BurntSushi/ripgrep/jobs/425857115
But the lock file indicates it should use encoding 0.8.6, not 0.8.14: https://github.com/BurntSushi/ripgrep/blob/0.10.0/Cargo.lock#L114-L115

I think I would've expected cargo install to use the lock file as is (i.e with --locked).

[ehuss]

Just to be clear, it works on a newer version of rustc.

There seems to be a bit of uncertainty if a minimum rustc bump should be a breaking change (rust-lang/api-guidelines#123).

The problem is that cargo publish does not include the Cargo.lock by default. There is an unstable option to do this (#5654). I think it would be good to start looking at fixing any known issues and moving towards stabilizing that. Although if it is optional, I'm not sure if most people will use it, so it may not help here. I wonder if it was considered if it should always be published, and let the installer decide whether or not to use it?

[alexcrichton]

Thanks for the report @vibhutisawant and thanks for looking into this @dwijnand and @ehuss! Sounds like this is covered by #5654 so I'm gonna close in favor of that.