tarpaulin: Tarpaulin fails with `Error: cannot find attribute 'skip' in this scope"` with rust 1.52.0 even if skip isn't used

Describe the bug

When trying to run tarpaulin in our project with rust v1.52.0 it fails with the error:

error: Broken pipe (os error 32)
warning: build failed, waiting for other jobs to finish...
error: Broken pipe (os error 32)
error: build failed
May 07 11:14:50.974 ERROR cargo_tarpaulin: Failed to compile tests! Error: cannot find attribute `skip` in this scope
Error: "Failed to compile tests! Error: cannot find attribute `skip` in this scope"

tarpaulin works with rust 1.51.0 and we do not use the skip attribute in the codebase

To Reproduce

clone https://github.com/tremor-rs/tremor-runtime and update the rust-toolchain file to 1.52.0

Expected behavior

projects working in 1.51.0 also work in 1.52.0

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 4
  • Comments: 32 (11 by maintainers)

Commits related to this issue

Most upvoted comments

Had the same issue, also with bitvec. Updating tarpaulin to the latest alpha version (EDIT: v0.18.x is out of alpha by now) ( cargo install cargo-tarpaulin --version 0.18.3 ) And adding the --avoid-cfg-tarpaulin flag solved the problem.

On my repo I had no further errors/warnings.

hello, I’m really sorry about the issues with bitvec and nom. I started the work on nom 7 which should fix them, but the rest of what I’d like to pass in that version is not ready yet, so in the meantime I published nom 7.0.0-alpha1 which only includes dependency updates. Could you check if it works for you?

If everyone else with issues wants to check and let me know the projects if they still fail. I’ll go on a hunt around the ecosystem upgrading things as needs be 😄 also if I don’t hear anything else in a month or so I’ll probably close this issue as inactive

I used cargo tarpaulin --avoid-cfg-tarpaulin and it worked now 🎉 . You responded before I could delete my comment. 😱

Okay just checked and the askama 0.12 beta has nom at 0.7 so you’ll be able to remove the flag once the next version of askama is released (unless you wanted to move to a beta release ofc).

And with updating to 0.18.3 free 2% test coverage 😄 🚀 from our side this is fully resolved 😃

It’s just a number, it’s fine 😁

Oi, would it be possible to ignore attributes in dependencies?

We’d need a way to apply rust flags to only the top level crate and not the dependencies, unless there’s something rust can do that I’m not aware of. I tried to do this once by calling rustc directly but it didn’t work very well. The attributes also had the breaking change in 0.14.0 after I found minimal use of them in peoples code I don’t expect a change like that again anytime soon. (Also, there is the flag to enable the legacy behaviour)

they all should be locked in the lockfile so a updated rust-toolchaiun should tm not cause a change in dependencies

So in my own production rust I rely on --locked to force it to use exactly what’s in the lockfile as there seems to be some instances where things can slightly change