repositive / event-store-rs

Evolvable implementation of an Event Store in Rust.
3 stars 1 forks source link

Replace quote::__rt::TokenTree::Group use in event-store-derive/src/ns.rs #80

Open rjs-repos opened 4 years ago

rjs-repos commented 4 years ago

When Circle-CI builds event-store-rs as a prerequisite for cmp-platform, it gives the following error message:

error[E0433]: failed to resolve: could not find `__rt` in `quote`
 --> event-store-derive/src/ns.rs:6:12
  |
6 | use quote::__rt::TokenTree::Group;
  |            ^^^^ could not find `__rt` in `quote`

error[E0531]: cannot find tuple struct/variant `Group` in this scope
  --> event-store-derive/src/ns.rs:27:25
   |
27 |                         Group(g) => Some(g.stream()),
   |                         ^^^^^ not found in this scope
help: possible candidates are found in other modules, you can import them into scope
   |
1  | use proc_macro2::TokenTree::Group;
   |
1  | use proc_macro::TokenTree::Group;
   |
1  | use proc_macro::bridge::TokenTree::Group;
   |
1  | use quote::__private::TokenTree::Group;

The most relevevant suggestion for a replacement would seem to be quote::__private::TokenTree::Group.

rjs-repos commented 4 years ago

The same use statement ('use quote::__rt::TokenTree::Group;) is also present in the open-sourced version of this repo (https://github.com/jamwaffles/event-sauce/blob/master/event-sauce-derive/src/ns.rs) but with some surrounding changes.

rjs-repos commented 4 years ago

It seems that rt was changed to private in the quote repo 7 days ago between releases 1.0.2 and (the most recent) 1.0.3. https://github.com/dtolnay/quote/commit/41543890aa76f4f8046fffac536b9445275aab26 includes the change in lib/rs:

- pub mod __rt;
+ pub mod __private;

plus corresponding updates in its use.

Since, however, the version of quote used is locked at 0.6.12 in event-store-derive/Cargo.toml, the question becomes why Circle-CI is using version 1.0.3. Presumably it is because it always uses the most recent one (hence the failure starting when 1.0.2 became 1.0.3) and perhaps needs to be locked to 0.6.12 as well.

A follow-up question might be why we were using something that was 'hidden' or now explicitly 'private' in the first place.

jamwaffles commented 4 years ago

Try doing cargo update in the repo root and commit the changes to Cargo.lock.

More here: https://users.rust-lang.org/t/failure-derive-compilation-error/39062

rjs-repos commented 4 years ago

Summary of recent attempts to resolve the issue: In event-store-rs: [cargo update did not make any changes to Cargo.lock.] Update: 'cargo update' probably generated a new Cargo.lock but, because Cargo.lock was not under version control, git diff unhelpfully simply produced no output (rather than warning: This file is not under version control) and, because Cargo.lock is in .gitignore, git status did not show it as an untracked file. In cmp-platform: cargo update made multiple changes to Cargo.lock.

Neither of these resolved the issue, so (after looking at the differences between quote 0.6.12 and 1.0.3 - lots in particular between 0.6.13 and 1.0.0 - and being aware that they could introduce some runtime error) change the use in event-store-rs to match 1.0.3 (rt to private) and increased the quote version in Cargo.toml from 0.6.12 to 1.0.3 accordingly. The PR now (unexpectedly) failed Travis checks in (another library / crate) smallvec: error[E0658]: use of unstable library feature 'maybe_uninit' /home/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/smallvec-1.2.0/lib.rs:49:5
with a suggestion to 'use core::mem::MaybeUninit;'.

It seemed unlikely that this was due to the quote changes, so I tried a trivial PR relative to event-store-rs master (changing one word in the README). This also failed in smallvec with the same error. smallvec is not included in any of the five Cargo.toml files under event-store-rs. There is no committed Cargo.lock under event-store-rs (Cargo.lock is actually in .gitignore.) Should there be?

According to https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html:

If you’re building a non-end product, such as a rust library that other rust packages will depend on, put Cargo.lock in your .gitignore. 
If you’re building an end product, which are executable like command-line tool or an application, or a system library with crate-type of staticlib or cdylib, check Cargo.lock into git.

BUT does the absence of a Cargo.lock explain why latest versions of crates are being used in the event-store-rsTravis test build or is it supposed to be controlled by CircleCI or Travis configuration?

Interestingly, the event-sauce nightly precheck-stable build started failing 9 days ago with the same original issue (rt v. private): https://circleci.com/gh/jamwaffles/event-sauce/117

#!/bin/bash -eo pipefail
./build.sh
...
   Compiling event-sauce-derive v0.1.0 (/home/circleci/project/event-sauce-derive)
   error[E0433]: failed to resolve: could not find `__rt` in `quote`
    --> event-sauce-derive/src/ns.rs:6:12
---
rjs-repos commented 4 years ago

OK - after generating an old-format (V1) Cargo.lock with an old cargo version (1.36.0 to match the Travis build test version) rather than a V2 format using the current cargo version (1.41.0) and adding it to the test-pr-with-trivial-edit_80 PR (https://github.com/repositive/event-store-rs/pull/82), I am now back to the smallvec build issue (previously reported above). I presume that if a Cargo.lock had been generated and committed back when event-store-rs was being developed, it would not be having build problems now due to picking up new versions of required crates.

---
https://travis-ci.org/github/repositive/event-store-rs/jobs/662079093?utm_medium=notification&utm_source=github_status
    ---
    error[E0658]: use of unstable library feature 'maybe_uninit'
      --> /home/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/smallvec-1.2.0/lib.rs:49:5
         |
      49 | use core::mem::MaybeUninit;
    ---
rjs-repos commented 4 years ago

Possibilities: Can I specify (pin) an earlier version of smallvec (in the relevant Cargo.toml) that does not cause this issue? (Maybe one from the last commit date to event-store-store before my recent changes.)

Even if this does fix the current error, is there going to be a whole series of errors from multiple crates?