Skip to content

Conversation

@jgraef
Copy link

@jgraef jgraef commented Jan 15, 2026

I use --no-default-features -F vorbis -F playback which causes an unused code warning. While fixing this I found more warnings that you get when compiling without any decoder feature enabled. This PR fixes these warnings

Copy link
Member

@roderickvd roderickvd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some ideas to make it more idiomatic and convey clearer intent.

#[cfg_attr(docsrs, doc(cfg(feature = "dither")))]
#[inline]
fn dither(self, target_bits: BitDepth, algorithm: DitherAlgorithm) -> Dither<Self>
fn dither(self, target_bits: crate::BitDepth, algorithm: DitherAlgorithm) -> Dither<Self>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is your rationale here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you import crate::BitDepth and then just use BitDepth you'll get a warning about the unused import when the dither feature is not enabled.

We can also put the import behind a feature flag, but then we end up with feature-gated stuff spread more out and it's just easier to accidentally mess up.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Err(DecoderError::UnrecognizedFormat)
{
let _ = data;
Err(DecoderError::UnrecognizedFormat)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tagging #[allow(unused_variables)] may convey intent more clearly.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. It would just allow unused variables (generally) and I think it would need to go on the function scope, and you'd want to only disable the lint for not(feature = "symphonia").

In my opinion the last block - whether symphonia is enabled, or not - should use the data somehow, and that's what this does.

It's late and I think I'm failing to describe why I think using let _ = data; is better. Maybe tomorrow it will be clearer for either of us.

DecoderImpl::Symphonia(source, PhantomData) => source.try_seek(pos),
DecoderImpl::None(_, _) => unreachable!(),
DecoderImpl::None(_, _) => {
let _ = pos;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Trick here is to make the argument _pos in the function signature.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Starting a variable with underscore is used for unused variables. pos is not generally unused.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can use it as _pos too: source.try_seek(_pos).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but naming it _pos communicates the intent of it being unused - which it is not generally.

let sample = source.next();
(DecoderImpl::Symphonia(source, PhantomData), sample)
}
DecoderImpl::None(unreachable, phantom) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or DecoderImpl::None(_, _) => unreachable!()?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then the code after the match statement is dead code and causes a warning.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants