Create an avr-unknown-none target

[Patryk27]

Proposal

I'm proposing to remove the existing avr-unknown-gnu-atmega328 target and replace it with a generic avr-unknown-none variant. This variant can be then specialized for a specific CPU (well, microcontroller) using the -C target-cpu flag, like so:

# .cargo/config.toml

[build]
target = "avr-unknown-none"
rustflags = ["-C", "target-cpu=atmega328p"]

[unstable]
build-std = ["core"]

In my opinion using the generic variant is the better approach here, since it matches how LLVM implements the target internally, making it easier for rustc and LLVM to cooperate; it's also better for end users, considering that the current approach with target.jsons is just awkward.

Having a generic variant does have a downside, though - avr-unknown-none would have to remain a tier 3 target as we won't be able to provide prebuilt standard library for it - especially considering that there's like three hundred possible values for -C target-cpu.

Fortunately, all those three hundred CPUs map down into about ~30 different AVR architecture combinations, so in the future we can think about providing dedicated avr25-unknown-none etc. targets that could be moved into tier 2 and even tier 1 one day. This remains outside the scope of this proposal, though.

To avoid confusing people, I'm proposing to remove the current avr-unknown-gnu-atmega328 target - it shouldn't be widely used in practice, because virtually all tutorials and examples rely on target.jsons (see e.g. examples in avr-hal). If backwards compatibility for tier 3 targets is important though, we can think about providing a dedicated error message for people trying to use the older target.

Bikeshedding

Name

LLVM calls this target avr-unknown-unknown, but discussion on Zulip proposed avr-unknown-none to match rustc's convention better.

Implementation

See: rust-lang/rust#131651.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections to the proposal should be discussed on Zulip and formally registered here by adding a comment with the following syntax:

@rustbot concern reason-for-concern 
<description of the concern> 

Concerns can be lifted with:

@rustbot resolve reason-for-concern 

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler @rust-lang/compiler-contributors