Tracking Issue for avr_target_feature

[taiki-e]

This is a tracking issue for AVR architecture specific part of #44839 (RFC 2045 (rust-lang/rfcs#2045)).
The feature gate for the issue is #![feature(avr_target_feature)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

• Implementation (Add avr_target_feature #146900)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• Should we hard error on -sram? (probably)

Implementation history

• Add avr_target_feature #146900

@rustbot label +O-avr +A-target-feature

[workingjubilee]

In #146900 I recommended forbidding -sram because the absence of SRAM is entirely incompatible with any reasonable implementation of a higher-level programming language.

And by "higher-level" I mean, say, C. Honestly, I bet it makes assembly painful to write too.

The current implementation of forbidding that target feature will only issue a future compatibility warning in that configuration. As there is no chance that anyone is relying on us supporting -sram, given both GCC and LLVM will error on it being used with a real language and not pure assembly, there is no particular reason, in my opinion, to not simply hard error proactively for this feature, for this target.

A complication that arose is that -Ctarget-cpu could still use a CPU that implies an absence of sram.