Skip to content

Conversation

@couchand
Copy link
Contributor

I'm writing some code that could be shared across AVR chips, and I'd like to depend on the common parts of this repo. The downstream users will be pulling it in anyway, but I'll leave it to them to pick a chip.

This feature allows a dependent crate to opt in to not picking a specific device, keeping the current user-friendly behavior of a compile fail when a device isn't chosen.

Happy to discuss more or bikeshed the feature name.

bors bot added a commit to rust-embedded/svd2rust that referenced this pull request Aug 15, 2020
467: Allow unused FieldReader r=therealprof a=couchand

I'm developing code that's general across AVR chips.  I'd like to depend on the shared parts of Rahix/avr-device (see Rahix/avr-device#44).  When compiling without any specific device feature enabled, there are no users of the `FieldReader::new` method.  This PR skips the lint for this case.

This is somewhat related to #427 but not exactly.

Co-authored-by: Andrew Dona-Couch <[email protected]>
@Rahix
Copy link
Owner

Rahix commented Aug 15, 2020

Can you explain a bit more what this is needed for? I think adding such a feature-flag just nullifies the error-mechanism altogether because as soon as any crate in the dependency tree enables it, no error will be emitted regardless of whether any chips were selected. Note that you can still have libraries depend on avr-device, for example avr-hal-generic pulls in avr-device without any chip-feature enabled. That's ok, it just means that any crate intending to use the libaray must select a chip-feature for avr-device and avr-hal-generic can only really use the non-specific parts of avr-device.

But maybe you have something I'm missing here?

@couchand
Copy link
Contributor Author

Oh my you're right. I was satisfied that it wouldn't cause problems for other users of this crate, but hadn't considered that it would eliminate the aid for anything downstream of my code.

I came to this because I reflexively constantly run cargo check, and so it bothers me a bit that the crate won't build on its own. But I do have unit tests (which select a chip feature), so all I need to do is get in the habit of going straight to cargo test rather than ever checking this project.

Thanks!

@couchand couchand closed this Aug 16, 2020
@Rahix
Copy link
Owner

Rahix commented Aug 16, 2020

Maybe we can make the hard error a warning instead so you can still build, but get a notice that you might have missed something?

@couchand
Copy link
Contributor Author

Well, I'd rather it be a hard error for everyone and maybe a minor habit break for me in one specific case than weaken what otherwise seems to be a reasonable protection into a warning that can easily get lost in the noise.

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