Opt-in link-time lint warnings, e.g. when ld can be ldh, or jp can be jr

[Rangi42]

These would be useful as opt-in link-time warnings:

• [ ] For every ld, check for and suggest using ldh instead if possible.

  (This would be an improved substitute for the removed feature of rgbasm -L, which optimized known-constant ld to ldh.)

• [ ] For every jp, check for and suggest using jr instead if possible.

• [ ] For every control flow instruction (call, jp, jr, rst) targeting a label in ROMX, do a lint equivalent of assert BANK(@) == 0 || BANK(<target>) == 0 || BANK(@) == BANK(<target>).

  (rst always targets ROM0, but if we add support for swappable ROM0, possibly via HDFs (#524), then this would be multi-banked.)

  Do this only if PC is in a ROMX section, which also excludes LOAD. (In theory, BANK(@) != 0 for ROMX, but -t maps ROMX to ROM0. The destination is then guaranteed to be in ROM0 as well, but that may not remain the case if we add some similar feature to HDFs, so a cheap stringent check for BANK(@) == 0 is good for future-proofing.)

  (Possibly make this a multi-level lint, where by default cross-SECTION jumps are not checked?)

[aaaaaa123456789]

I'd say that all warnings should be enabled by -W flags. Other than that, good idea.

[Rangi42]

Hm, so rgbasm and rgblink would both need flags for this.

[Rangi42]

As pointed out in #1114, it would be useful to allow each warning for all occurrences of a pattern, or just the first occurrence, or not warn for that pattern. ("A pattern" might be "ld which can be ldh", or "jp which can be jr", or "ld X, Y after ld Y, X", or "call+ret which can be jp", or so on.)

Inline comments or pragmas to suppress warnings at particular sites would also be useful (e.g. maybe this ld [$ff00], a is in a LOAD section and will be modifiable to non-HRAM addresses).

[im-mi]

Checking if a jump target is close enough to use jr when the target label exists in a different section is bound to cause all sorts of unwanted warnings as sections get shifted around by the linker. Perhaps that feature should be limited to cases where the jump target is in the same section (or section fragment, for fragmented sections).

On a similar note, a warning could also be produced when performing a suspicious call or jump. For example: if code in a non-fixed ROM bank is calling a subroutine in a different non-fixed ROM bank, then it's probably a bug.

Of course many of these features can be implemented using macros, but having them built-in would be pretty convenient.