-
-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tarpaulin skip no longer working since 0.13.4 #487
Comments
Yeah it's mentioned in #486 I didn't expect that effect but that's largely because I didn't fully grok cfg_attr and now it's clear I was kind of misusing it. I'll work on this after my working day is finished but the current thinking is that it might be necessary to add: #![feature(register_tool)]
#![register_tool(tarpaulin)]
// then replace #[cfg_attr(tarpaulin, skip)] with:
#[tarpaulin::skip]
fn my_function() {} It's more idiomatic but it does involve using nightly rust if you want skip attributes. Alternatively, I could remove |
Hmm, I don't think you should have to require nightly to support custom attributes? serde for example has them, and does not require nightly? Same with clippy, which uses the |
Clippy and rustfmt are tool attributes supported in the compiler. I thnik serde is probably a proc-macro attribute so taking in a token stream and generating code etc? This https://doc.rust-lang.org/reference/attributes.html#tool-attributes and rust-lang/rust#66079 are my references for this though I might be incorrect or there might be an easier way to achieve what we want |
Oh, interesting. Yeah, you're probably right on both accounts.. Hmm... // #[tarpaulin::skip]
fn my_function() {} |
it uses syn and parses object attributes looking for them, I can add code to find I could also see if the rust team are willing to give me a tool lint but I'm not sure if I'm big enough for that |
Here's another option: #[cfg(tarpaulin_skip)] |
oh true true, I kinda like that |
+1 to @jonhoo's suggestion not having to rely on |
I've added support for both just pushed to a feature branch to make sure it passes CI. Also added an integration test for it (will also add another one for the nightly feature). Once it passes I'll do a release since it's a pretty small change and with the extra tests I can be more confident about it |
Wait |
It's on the branch |
I've also yanked 0.13.4 until this is sorted out although that doesn't help anyone affected using the latest docker image |
Err, I guess it'd have to be more like |
that still changes what code is compiled in when running in/out of tarpaulin, the aim of the initial implementation was so that tarpaulin would remove the lines from the results but they'd still be present and ran. Which is why I now have in the branch |
@xd009642 no, the above would never actually change anything, since it'd always be true |
ooh right so I wouldn't --cfg it I follow now. I suppose it is a unique enough name that someone wouldn't try to use it themselves 🤔 |
Luckily enough this part of the code is quite easy to modify now so I've just made the change and pushed it, feel free to feedback on the readme and example projects |
Yeah, my thinking is that you'd pass #[cfg(not(tarpaulin_include))] That way, people can still use |
Yeah I've just implemented it like that and tests pass and it's working as expected on a larger project I used it on. I'll merge it into develop, sleep on it and then tomorrow work out if it's ready for release. Don't want to jump the gun again 😅 |
It's still a break release of course, since the old |
Yeah I was planning on making it 0.14.0 |
Thanks for the super speedy reply and resolution @xd009642 <3! |
I've done a few more tests and now 0.14.0 release is in progress (once CI and docker hub is finished it will be all done). As always let me know if anything doesn't work with it 👍 |
Still happen |
@Stargateur That's an issue in time, they've fixed it but haven't yet released a new version since then. Either see if they'll release a new version soon or in the meantime stick to tarpaulin 0.13.x |
See: https://github.com/wayfair-tremor/tremor-runtime/pull/321/checks?check_run_id=803402444
This is seems to be a regression since 0.13.3
The text was updated successfully, but these errors were encountered: