Ensure tests are built with same dependencies as parent crate

[dtolnay]

The crate that gets compiled by trybuild is given the same dependencies in its Cargo.toml as the outer crate has. But it may have an old Cargo.lock left over from a previous cargo test run that causes it to use a different set of patch versions of those dependencies compared to what is used currently by the outer crate whose tests we are running. To avoid this, trybuild should somehow write a Cargo.lock (or failing that, use a sequence of cargo update --precise commands) to keep the resolved set of dependencies in sync.

[TriplEight]

Steps to repro:

# download the cache from https://drive.google.com/file/d/1J3ZqSTP_yRugPcx6aIohiHdhDxZ7A3Qp/view?usp=sharing
# unzip the cache to ~/cache/targets/
docker run -it -v ~/cache/:/ci-cache parity/ink-ci-linux:demo

# inside of the container:
export SCCACHE_DIR=/ci-cache/sccache
export CARGO_HOME=/ci-cache/cargo
export CARGO_TARGET_DIR=/ci-cache/targets/337/test/

git clone https://github.com/paritytech/ink .
git checkout 79f8571172892426161d70adc7d514767dcc3c9b

cargo test --verbose --all-features --release --manifest-path lang/macro/Cargo.toml --test compile_tests

[TriplEight]

locally I'm getting

running 1 test
error: failed to download `aho-corasick v0.7.9`

Caused by:
  can't make HTTP request in the offline mode
test compile_tests ... FAILED

[ascjones]

A naive solution would be to remove the cached Cargo.lock from the location of the crate generated by trybuild. e.g. master...ascjones:rm-cargo-lock.

It will then write a new Cargo.lock which will resolve the best set of dependencies available locally (because of --offline) which should be the same as those downloaded for the outer crate.

I've tested this for the repro above and it works, and rerunning the tests with the package resolution is fast.

I'm not sure though that this will guarantee the exact same set of dependencies, or what other unintended consequences there may be. But putting this suggestion forward as the "simplest thing that will possibly work".

Another idea I'm currently investigating is when copying the dependencies to the crate generated by trybuild, read the precise versions from the outer crate's Cargo.lock and write them to the generated Cargo.toml. In this way we would guarantee the same set of dependencies.

@dtolnay let me know what you think of those ideas and I can prepare a PR, or go back to the drawing board.

[ascjones]

As an alternative to deleting the Cargo.lock, running cargo generate-lockfile --offline would force refresh the Cargo.lock.

Tried it and it works: master...ascjones:generate-lockfile

Edit: PR for this 👇

[dtolnay]

I published the partial workaround in #54 in 1.0.24. Thanks @ascjones!

[cecton]

I'm still getting this issue on version 1.0.35