Skip to content
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

avr-hal-generic: prefer compilation error for unsupported targets #624

Closed
wants to merge 1 commit into from

Conversation

tones111
Copy link
Contributor

@tones111 tones111 commented Jan 2, 2025

The build.rs logic is only used to detect a relatively old compiler version (Feb 2022). Since a nightly build is required to target AVR it's unlikely anyone is benefiting from this check. By removing it we reduce dependencies and implementation complexity.

@tones111
Copy link
Contributor Author

tones111 commented Jan 2, 2025

As requested this commit has been split from #619, however, since it depends on the previous change I've stacked it. As discussed here GitHub doesn't really support splitting dependent changes across multiple reviews.

The use of "unimplemented!" delays error detection until runtime, but
the target architecture is known at compile time. By removing the
unimplemented function we prevent unsupported architectures at
compile-time.
@Rahix
Copy link
Owner

Rahix commented Jan 6, 2025

So far we've tried to keep avr-hal building on non-avr targets. The motivation was mainly to allow running tests on other platforms without having to remove all avr-hal dependencies from an application. Adding a compile-time error would of course break this.


On a different note, even if we were to introduce a compile-time error, I do not think that this is the proper way to do it: The resulting error message is extremely confusing and doesn't hint at the underlying problem at all. The proper way would be a crate-global cfg'ed compile_error!(), similar to this one:

#[cfg(all(
not(feature = "device-selected"),
not(feature = "disable-device-selection-error")
))]
compile_error!(
"This crate requires you to specify your target chip as a feature.
Please select one of the following
* atmega48p
* atmega164pa
* atmega168
* atmega328p
* atmega328pb
* atmega32u4
* atmega128a
* atmega1280
* atmega2560
* atmega1284p
* atmega8
"
);

The tricky part is ensuring that such an error also short-circuits all other compiler errors that are caused by the same reason, to ensure clean and easy-to-navigate diagnostics.

@tones111 tones111 closed this Jan 6, 2025
@tones111 tones111 deleted the no_rustversion2 branch January 6, 2025 21:46
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