[pganssle]

Stacked on #159770; only the top two commits are new here.

When an encoded word does not fit in the remaining space of a line, _fold_as_ew shrinks the chunk being encoded one character at a time until it fits. Nothing stops it from shrinking the chunk to nothing, and an empty chunk makes no progress: the loop appends an empty encoded word and a new continuation line forever.

>>> import email.policy
>>> email.policy.default.clone(max_line_length=20).fold('Subject', '😀')
# never returns

This is reachable whenever a single character's encoded form is wider than a fresh continuation line, e.g. any character outside the BMP at max_line_length=20 (the q-encoded word is 24 characters). The two earlier fixes in this area (bpo-33529, bpo-36564) handled lines too short for the RFC 2047 chrome, but not lines too short for the chrome plus one character.

The fix keeps at least one character in the chunk, so the loop always advances and the line runs over max_line_length instead. That matches what _refold_parse_tree already does when it cannot fold a part at all, and avoids raising for widths that work for every other input.

Tests, next to the two earlier infinite-loop regressions in test_policy.py:

• An exact-output regression case, as the earlier two have.
• A Hypothesis property: folding any generated unstructured value at any width in 1..120 (plus 0 and None) either raises HeaderParseError (only possible at widths of 13 or fewer, where no encoded word fits) or reparses to the same value modulo leading whitespace, which the parser drops. 100 examples take about 0.2 s; the explicit examples replay under the stubs.
• The round-trip strategy cannot produce text that is itself a well-formed encoded word, because such text is written out unencoded and so decodes to something else on reparse. That is a separate question, filed as email: a header value that is itself a well-formed RFC 2047 encoded word is decoded or written verbatim, never encoded #160148.

• Issue: [Meta] Research: what can we test with Hypothesis? #107862

[bitdancer]

Thanks for finding this. I actually thought I had observed that case during those previous changes, but I must be mis-remembering. Either that, or there's an open issue I can't find ;)

I'll have to look in to the hypothesis stuff...looking at it without understanding hypothesis it is completely opaque to me what exactly it is testing.

As for the encoded word bug, please separate that out into a new issue. If/how to fix it should be a separate discussion. I prefer not to add "expected failure" tests.

[pganssle]

Done: the expected failure is removed from this PR and filed separately as #160148, with the test included in the issue text for reference. The branch now has only the infinite loop fix, its regression test, and the round-trip property (plus a comment pointing at #160148 for why the strategy avoids encoded-word look-alikes).

On the Hypothesis test: it generates subjects from a small set of pieces (words, whitespace runs, RFC 5322 specials, 2/3/4-byte characters, =? and ?=) at every width from 1 to 120, folds each one, reparses, and checks it comes back the same (modulo leading whitespace). The @example lines are the fixed cases that always run, including the ones that looped before this fix and the two earlier bpo regressions; without Hypothesis installed only those run.