Inconsistent local/global assignment error with \NewMarkClass

[gusbrs]

Brief outline of the bug

Creating a new ltmarks class with \NewMarkClass results in "Inconsistent local/global assignment" error when check-declarations is enabled.

Minimal example showing the bug

\RequirePackage{latexbug}
\documentclass{article}

\ExplSyntaxOn
\debug_on:n { check-declarations }
\ExplSyntaxOff

\NewMarkClass{mymarks}

\begin{document}

Foo.

\end{document}

Log file (required) and possibly PDF file

document.log

[FrankMittelbach]

It's harmless, as the declaration should appear only at top-level, but it is a bug nonetheless. Will correct it in the next release. Thanks for spotting.

[gusbrs]

For the record, particularly regarding the "harmless" statement, I'm actually getting some slight concrete inconvenience because of this.

I'm using now ltmarks for postnotes and my regression test suite fails miserably with l3build check --dev, because the 100 errors limit is reached, and the logs are all empty. Somehow the standard l3build check (still?) works, and I don't know why the difference in behavior there. Anyway, I thought it was worth letting you know. (I mean, the fact that there's something different in --dev).

[gusbrs]

Some investigation on the previous comment. postnotes sets 4 mark classes, and current released version of ltmarks sets 6 regions, each of which makes 3 assignments. That totals 72 inconsistent assignment errors. The dev version includes further 20 mcol regions which obviously blows this number beyond the 100 error limit. That's the reason for the difference above.

And, as far as I can tell, the fix to \__mark_init_region:nn already committed handles everything. So nothing to worry about.

[FrankMittelbach]

For the record, particularly regarding the "harmless" statement, I'm actually getting some slight concrete inconvenience because of this.

I didn't want to indicate that there isn't any inconvenience due to the bug, if you enable checking then of course there is because the error means TeX is stopping (or worse, it hits 100 errors limit as in your case). All I meant was that if you don't do checking the mistake has no bad effects.

I'm using now ltmarks for postnotes and my regression test suite fails miserably with l3build check --dev, because the 100 errors limit is reached, and the logs are all empty. Somehow the standard l3build check (still?) works, and I don't know why the difference in behavior there. Anyway, I thought it was worth letting you know. (I mean, the fact that there's something different in --dev).

The reason is that with the current implementation you hit the error only a few times (if at all) per declaration, with the new one in dev you hit it quite often, which is why you end up with TeX giving up.

The problem will go away with the next dev release, but for new to pass the dev release tests you would need to either disable that particular test or move the start of checking after the declarations have been made, so yes inconvenient.

[gusbrs]

@FrankMittelbach Agreed on all accounts. It was not a complaint or anything, the point of the first comment was really that there seemed to be something different with dev, as indeed there is.

And it is not a big deal on my side either. I just can't run l3build check --dev until the next dev release. Not a problem. Indeed, this is good illustration of how useful the --dev switch is, we spotted an issue before it became a problem. ;-)

The problem will go away with the next dev release, but for new to pass the dev release tests you would need to either disable that particular test or move the start of checking after the declarations have been made, so yes inconvenient.

Actually all of my test files set \debug_on:n { check-declarations , deprecation } (except polyglossia ones, I think), perhaps I shouldn't, I guess. ;-) And yes, the checking already starts after the declarations have been made, that's why the tests still pass with current release, but when the 100 error limit is reached the whole log gets empty.

I guess I was just lucky that with the current numbers the limit is not reached. Otherwise I might have had to wait a bit. But, again, none of this is an actual problem.

Btw, thanks for the quick fix. (@muzimuzhi ).

And thanks for ltmarks as well, it does make my job in supplying running headers data there a lot easier.