The rule at src/main/resources/org/eolang/lints/design/package-member-without-void.xsl:15 reports every named top-level formation in a +package file that declares no void attribute:
<xsl:for-each select="/object/o[eo:abstract(.) and @name and not(o[eo:void(.)])]">
and tells the programmer the object "does not declare any void attributes, so it can never be reached in the implicit (receiver) form, only through the package namespace". That was true while PhDefault.absent was the only way a member could get a receiver: at runtime it looked the member up on the classpath and wrote the receiver into the member's first void, so a member with no void had nowhere for one to go.
objectionary/eo#6616 replaces that lookup with a compile-time merge. A new 4-merge stage splices every member of a package into the object the package names, and the member then reads its receiver through ^:
[] > naturals
range > @
...
^ > r
Declaring no void is the correct shape for such a member, not a defect, and the rule reports it anyway. Worse, it cannot tell the two cases apart: it runs at 3-lint, one stage before the merge, and whether a package is merged is decided by the mergedPackages parameter of the merge mojo, which no XMIR the linter reads carries. The question the rule asks stopped being answerable where it is asked.
objectionary/eo#6770 added the first three +unlint package-member-without-void metas, to range/naturals.eo, chunk/to-output.eo and output/dead.eo. Seven packages are left in objectionary/eo#6657 and each one adds more, on the way to roughly forty metas whose only purpose is to say that a rule no longer applies.
Delete the stylesheet and the six packs under src/test/resources/org/eolang/lints/packs/single/package-member-without-void/, along with the rule's entry wherever the lint set enumerates it. The behaviour it guarded is now the compiler's to enforce, and it has the merge stage to enforce it with.
The rule at
src/main/resources/org/eolang/lints/design/package-member-without-void.xsl:15reports every named top-level formation in a+packagefile that declares no void attribute:and tells the programmer the object "does not declare any void attributes, so it can never be reached in the implicit (receiver) form, only through the package namespace". That was true while
PhDefault.absentwas the only way a member could get a receiver: at runtime it looked the member up on the classpath and wrote the receiver into the member's first void, so a member with no void had nowhere for one to go.objectionary/eo#6616 replaces that lookup with a compile-time merge. A new
4-mergestage splices every member of a package into the object the package names, and the member then reads its receiver through^:Declaring no void is the correct shape for such a member, not a defect, and the rule reports it anyway. Worse, it cannot tell the two cases apart: it runs at
3-lint, one stage before the merge, and whether a package is merged is decided by themergedPackagesparameter of the merge mojo, which no XMIR the linter reads carries. The question the rule asks stopped being answerable where it is asked.objectionary/eo#6770 added the first three
+unlint package-member-without-voidmetas, torange/naturals.eo,chunk/to-output.eoandoutput/dead.eo. Seven packages are left in objectionary/eo#6657 and each one adds more, on the way to roughly forty metas whose only purpose is to say that a rule no longer applies.Delete the stylesheet and the six packs under
src/test/resources/org/eolang/lints/packs/single/package-member-without-void/, along with the rule's entry wherever the lint set enumerates it. The behaviour it guarded is now the compiler's to enforce, and it has the merge stage to enforce it with.