`or_fun_call` false positive on enum variants with tuple fields

[AlexTMjugador]

Summary

I maintain several Rust projects whose CI workflows run the latest nightly Clippy almost daily. As a result of that, I've discovered that yesterday's nightly, with a commit date of 2022-10-07, introduced a likely unintended behavior change on the or_fun_call lint when initializing enum variants with tuple fields:

Obviously, in this case no function is being called to initialize the fallback value, so it is a false positive.

Lint Name

or_fun_call

Reproducer

I tried this code:

https://github.com/OptiVorbis/OptiVorbis/archive/49ca18a55293bc5e74b09106c5b09ae56aba6148.zip (OptiVorbis source ZIP)

I saw this happen:

https://github.com/OptiVorbis/OptiVorbis/actions/runs/3209020234/jobs/5245395845 (workflow run logs. Notice the Clippy lints)

I expected to see this happen:

No new lints being triggered, or not new false positives

Version

rustc 1.66.0-nightly (8b0c05d9a 2022-10-07)
binary: rustc
commit-hash: 8b0c05d9ad7121cdb97600f261bcd5f04c8db20d
commit-date: 2022-10-07
host: x86_64-unknown-linux-gnu
release: 1.66.0-nightly
LLVM version: 15.0.2

Additional Labels

No response

[kraktus]

Thanks for reporting,

Do your enums have manual implementation of Drop? If so, this is intended: #9551

[AlexTMjugador]

Thank you for your prompt response!

The affected enums, including the VorbisOptimizerError enum shown in the attached screenshot in particular, do not implement Drop: https://docs.rs/optivorbis/latest/optivorbis/enum.VorbisOptimizerError.html

[AlexTMjugador]

Sadly, yesterday's nightly (c0983a9 2022-10-12) still outputs the described false positive for the same source code. I assume the fix PR made it to the nightly, so what's going on here?

[kraktus]

Not every nightly ships a new clippy, will check on my side too