Fixes#2095
This code pre-dates the introduction of alignment offsets,
so it was never updated to take it into account.
That said, some of the code that I have factored out is a little awkward because
it will be used in an upcoming refactoring of the whole assignment loop,
since that turns out to be more byzantine than it ought to be due to
trying to handle a too disparate set of cases in a single loop.
Turns out the checks could fail spuriously if the starting alignment is non-zero,
e.g. `align 8,$C0` in HRAM. (Fixes #2113.)
This was tripped up by a test added to exercise the linker's section placement algorithm
on a similar aligment-related issue. :D
Note that this may be caused by the code in question pre-dating alignment offsets,
and we never checked. That said, these checks only work due to the regions' starting
addresses being no more aligned than their size (..if that makes sense?), so allowing
custom memory regions (#524) could violate that assumption and make those checks incorrect.
Assembling is never *supposed* to fail, but in this case I ended up adding
a test case that triggered a bug in the assembler, and that caused the rest
of the test to become garbled. This is thus more robust.
The only case where it is not generated by our own code
(which we ought to be `assume`ing is correct) is when the bank
is used-specified, but that is caught by an earlier check.
Moving both pieces of related code together, as it were.
This also ends up changing the behaviour of scrambling,
where sections could “leak” out of the scrambling's bank pool
and resume being placed normally.
We have discussed it offline, and decided that this was a bug.
The test suite has been updated accordingly, which even gives
the occasion to move this test from a special case to the main
generic loop!
This reverts a change introduced in fd78a9ae8, though it wasn't that commit's main point
so I'm feeling okay with undoing that.
This feels like an overkill change, using a static string is good enough for this
since we never modify this. I have considered using `string_view` instead, to have
the best of both worlds, but that's not NUL-terminated so our print functions
get a little grumpy.
If `nbBanks > 1` is true, then `sectionTypeInfo[type].firstBank !=
sectionTypeInfo[type].lastBank` must also be true, so checking
whether either is true is unnecessary.
(On the other hand, if `nbBanks == 1`, then we might still have
`sectionTypeInfo[type].firstBank != sectionTypeInfo[type].lastBank`,
since only one of many valid banks for `type` could be in use.)
This should remain equivalent for our current setups,
but play nicer with anyone wanting to experiment further.
It *may* break for someone building on an Intel Mac,
but this is a libpng limitation and thus out of our control.
Non-indexed images can still have a PLTE chunk. We should use
`sortRgb` instead of `sortIndexed` for them, since their pixels' colors
may not all be present in the PLTE chunk and would be unsortable.
The current setup fails with a "cannot read tree" error.
Also added flags to parallelise each fetch, which is relevant when submodules
are involved. (So, pretty much just starter-kit, haha.)
It would be nice to also parallelise the various fetches, but that would hit
the same remote multiple times, and could lead to rate-limiting...
ISSOtm
Rangi
Rangi
Erickson Munoz