Swap primary/secondary spans in multiple unused formatting arguments diagnostic

[estebank]

For tooling's sake, make the following string literal the primary span:

error: multiple unused formatting arguments
 --> src/main.rs:1:30
  |
1 | fn main() { println!("Test", 1, 2) }
  |                      ------  ^  ^
  |                      |
  |                      multiple missing formatting specifiers

This way we can keep the current visual output, while giving the primary span a label that can be used by dev-tools.

CC dense-analysis/ale#1696

[RyanSquared]

Because, at the moment, there's nothing preventing this same scenario from coming up elsewhere, I'm wondering if this is by design. If it is, it might be better to make the ALE handler work on a system where it grabs the first, and then "upgrades" if it has a primary span with a label.

[estebank]

All primary spans should have a label. That not being the case is an accident of being a newer feature.

ALE could use the main message if the primary span has no label. That would be a good idea to do in order to avoid these cases as we slowly fix them.

[RyanSquared]

ALE could use the main message if the primary span has no label.

And, as I glazed over earlier, it appears to do just that. I'll see about testing it more and possibly merging the branch as-is. Glad to know I found a bug, though.

Perhaps some assurance could be made when running tests, or at the very least a scream test - when creating a span and changing the primary-ness, raise an ICE?

[estebank]

Perhaps some assurance could be made when running tests, or at the very least a scream test - when creating a span and changing the primary-ness, raise an ICE?

I'm not sure what you mean by this.

[RyanSquared]

If it's the case where every primary span should have a label, why is it not required? Is there any way, at least for the purpose of debugging, to make an assurance that all uses of a primary span implies having a label? Afterwards, it would be possible to run tests at least in this debugging mode, and every primary span without a label would result in an error.

[estebank]

@RyanSquared because doing so will be a big undertaking and in some cases it's hard to come up with a nice label for the primary span (due to the compiler's lack of context). We've been doing it piecemeal to keep it 1) at a reasonable size for anyone that can contribute and 2) to make sure that the primary span doesn't just duplicate the main message (which requires thought to be taken, it isn't a mechanical change). On all cases where there isn't a label, the main message can be used by tools.