mbox series

[00/11] gas: scrubber adjustments

Message ID f12de588-f77f-41b5-a6d0-83c1eb7de05c@suse.com
Headers
Series gas: scrubber adjustments |

Message

Jan Beulich June 28, 2024, 1:15 p.m. UTC 
  The end goal is to finally deal with long standing issues in, in
particular, macro handling (see e.g. b3446f947bd1 ["gas: retain
whitespace between strings"]). That's the final, still work-in-
progress patch (posting for early commenting). I've come across
various other issues though, which some of the earlier patches aim
at addressing. Imo those are (in principle, subject to feedback of
course) fine to go in for 2.43. Whereas I'd prefer the final change
to go in relatively early in a release cycle, to allow time to deal
with real or perceived regressions (see patch 8 for an example
thereof).

One of the issues I'm going to face when getting farther in dealing
with target specific adjustments is that there are 5 gas targets
which don't even have a testsuite subdir:
- m32c (no maintainer)
- moxie
- ns32k (no maintainer)
- spu
- tic30 (no maintainer)
How is one supposed to have even the slightest idea whether a common
code change breaks such a target (Cc-ing the two maintainers of the
named targets which have one)? I'm already worried enough by targets
having only a pretty "slim" set of test cases.

01: there's no scrubber state 12
02: drop scrubber state -2
03: multi-byte warning adjustments
04: don't open-code IS_WHITESPACE() / IS_NEWLINE()
05: pre-init the scrubber's lex[]
06: re-work tic6x scrubber special case
07: consistently drop trailing whitespace when scrubbing
08: Arm: correct macro use in gas testsuite
09: Arm: relax gas testsuite whitespace expectations
10: aarch64: relax gas testsuite whitespace expectations
11: have scrubber retain more whitespace

Jan

Comments

Jan Beulich June 28, 2024, 1:26 p.m. UTC | #1 
In a subsequent change the scrubber is going to be changed to retain
further whitespace. Test case expectations generally would better not
depend on the specific whitespace treatment by the scrubber, unless of
course a test is specifically about it. Adjust relevant test cases to
permit blanks where those will subsequently appear.
---
This is adding just the blanks that are going to be needed; imo it would
generally be better if test case expectations were, from the very
beginning, written to focus on what is being tested, rather than taking
verbatim copies of the respective tool's output.

[actual patch attached, for size reasons]