Build failure with latest nightly: ExprKind::AddrOf variant changed

[joshtriplett]

With an up to date nightly (rustc 1.41.0-nightly (412f43ac5 2019-11-24)), I get the following build failure:

   Compiling rerast v0.1.76
error[E0023]: this pattern has 3 fields, but the corresponding tuple variant has 2 fields
    --> /home/josh/.cargo/registry/src/github.com-1ecc6299db9ec823/rerast-0.1.76/src/rule_finder.rs:249:24
     |
249  |                 if let hir::ExprKind::AddrOf(_, _, ref expr) = addr_expr.kind {
     |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected 2 fields, found 3

error[E0023]: this pattern has 3 fields, but the corresponding tuple variant has 2 fields
    --> /home/josh/.cargo/registry/src/github.com-1ecc6299db9ec823/rerast-0.1.76/src/rule_matcher.rs:516:18
     |
516  |                 &ExprKind::AddrOf(p_kind, p_mut, ref p_expr),
     |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected 2 fields, found 3

error[E0023]: this pattern has 3 fields, but the corresponding tuple variant has 2 fields
    --> /home/josh/.cargo/registry/src/github.com-1ecc6299db9ec823/rerast-0.1.76/src/rule_matcher.rs:517:18
     |
517  |                 &ExprKind::AddrOf(c_kind, c_mut, ref c_expr),
     |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected 2 fields, found 3

[fogti]

I got another error, additionally:

error[E0061]: this function takes 2 parameters but 1 parameter was supplied
   --> src/change_to_rule.rs:155:27
    |
155 |             let session = ParseSess::new(FilePathMapping::empty());
    |                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected 2 parameters

error[E0061]: this function takes 2 parameters but 1 parameter was supplied
   --> src/change_to_rule.rs:484:35
    |
484 |                     let session = ParseSess::new(FilePathMapping::empty());
    |                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected 2 parameters

error[E0061]: this function takes 2 parameters but 1 parameter was supplied
   --> src/code_substitution.rs:181:19
    |
181 |     let session = ParseSess::new(FilePathMapping::empty());
    |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected 2 parameters

[davidlattimore]

There's new nightly builds than that. I updated to 2019-11-26 last night.

If you're stuck on an older nightly for some reason, you might need an older release. See https://github.com/google/rerast/commits/master for recent commits, which list the nightly version that they were built with.

[joshtriplett]

@davidlattimore Ah, I see. 2019-11-24 is the most recent version with a functional clippy, so that's what a fresh rustup update installed.

I installed 2019-11-28 with rustup update --force, and that let me build rerast.

[davidlattimore]

I guess probably the kinds of changes to rustc internals that break rerast, also often break clippy, so probably not surprising.

I get CI build failures whenever that happens and usually fix it within a day or so. Looks like I've done 54 such fixes since May 2018. Most breakages only take about 20 minutes to fix (helped heaps by searching for the offending type / function in the git diff of recent changes in rust repository). But having this always only work on a pretty narrow range of nightly builds isn't ideal for users of the tool.

I've been wanting to try and do a rewrite of rerast that works on stable rust. Unfortunately it would probably involve some trade-offs in terms of features. I've been thinking of matching token trees instead of a typed AST like HIR (which is what Rerast currently matches on). That would mean that matching wouldn't know about types, which is a pity. However the upside of that is that I think it'd make the tool a heap easier to use. Matching token trees would allow any part of the syntax to be matched and would also allow running on code that didn't compile. I'm hopeful that perhaps optional type constraints might then be able to be added on top of that, but that'd be further down the track (and would depend on how good type resolution was in rust-analyzer or whatever I build on).

[joshtriplett]

@davidlattimore

I've been thinking of matching token trees instead of a typed AST like HIR (which is what Rerast currently matches on). That would mean that matching wouldn't know about types

Matching on types is by far one of the most valuable features of a tool like this, and I think it's worth keeping even if that means building against nightly for now. I'd like to have the full power of coccinelle for Rust, which would include type matching as well as control-flow matching.

Perhaps rust-analyzer can help with that, and perhaps rerast could one day integrate with rust-analyzer. But I don't think you should just drop type-based matching until that time.

You might consider pinning a specific nightly version of Rust using rustup override, checking in the resulting rust-toolchain file, and updating it every time CI successfully builds and passes tests using the latest nightly.