objectionary/eo

What happens The transpile cache is keyed by a directory whose name folds a fingerprint of the whole module's inference tables: this.fingerprint = new Sticky<>(() -> new Fingerprint(tables).get()); tables is target/eo/6-inference, holding links.xml, needs.xml and provides.xml — one document each, listing every object of the module (11M, 2.2M and 1.8M for eo-runtime). Adding a single unrelated object changes all three, so version() changes, so every object of the module misses the cache and is transpiled again into a fresh directory under ~/.eo/transpiled. Two builds, the second with the same two sources byte for byte plus one new unrelated object, sharing one cache directory: after the first : [...-70b8ad9105e7-false-false-false-PhDefault] after the second : [...-369675c6fbf9-false-false-false-PhDefault, ...-70b8ad9105e7-false-false-false-PhDefault] Both directories hold bool.xmir and bytes.xmir; the first one is now orphaned and nothing prunes it. Why it is wro

What happens CoverageManifest.locations counts an anonymous formation, and the transpiler never wraps it, so its line can never be hit. For this source: +package examples [] > x bool > @ [] ? >> left ? >> right right > @ the manifest holds three locations: [Φ.examples.x.φ:4:2, Φ.examples.x.φ.α0:5:4, Φ.examples.x.φ.α0.φ:8:6] and the generated Java carries new PhCoverage(...) for two of them. Φ.examples.x.φ.α0:5:4, the [] on line 5, is only in the manifest. Feeding every location the transpiler does instrument into coverage-report as a hit still leaves DA:5,0, so the file reports 2 of 3 lines covered and no test can move it. Why it is wrong The manifest is meant to hold what a transpile would instrument — its javadoc says so, "the same string PhCoverage records a hit under". An anonymous formation becomes a nested class through anonymous-to-nested.xsl, and to-java.xsl never applies its mode="located" template to those, so the two sides of the repo

What happens Source.spans() treats every standalone \\r as a line terminator. A source using classic-Mac line endings therefore parses successfully, although the parser specification allows only LF (\\n) and CRLF (\\r\\n). [] > app\\r foo > x\\r The \\r characters above are literal U+000D bytes, not the two-character escape sequence. The parser accepts the file, emits app with child x, and reports no line-ending diagnostic. What should happen The lexical layer should accept only \\n and \\r\\n as line endings, as required by R-2.1.2. A standalone carriage return should be rejected with a deterministic parse error (or otherwise reported as an unsupported line ending), rather than silently changing the source line structure. How it was verified I rebuilt eo-parser from the current master and parsed the Java string "[] > app\\r foo > x\\r". EoSyntax returned an empty /object/errors list and emitted the two expected object names. The current implementation's Source.spans() branch for gl

The multi-line BYTES merger accepts any continuation that is at least as deep as its opener. It does not enforce R-2.2.2, which limits an indentation increase between consecutive non-blank lines to one level (two spaces). What happens Parse this source: [] > app CA-FE- BE-BE The continuation jumps from two leading spaces to six, skipping the four-space level. EoSyntax accepts the source and merges both chunks into one Φ.bytes value; no indent increased by more than one level error is emitted. What should happen A BYTES continuation should obey the same one-level indentation rule as every other line. The example should be rejected with indent increased by more than one level; a valid continuation may stay at the opener's indent or increase by one level only. How it was verified The example was parsed on the current master; the parser emitted no <errors> entry and returned a single merged bytes value. Significant whitespace determines EO structure. The special BYTES path curren

Span.leading() (eo-parser/src/main/java/org/eolang/parser/Span.java:137-142) counts by Character.isWhitespace. Span.tabbed() (lines 145-155) walks only ' ' and '\t' characters. Eo.leadingSpaces() (eo-parser/src/main/java/org/eolang/parser/Eo.java:308-314), used by the text-block indent check in Eo.continueTextBlock, counts only literal ' '. The same source line can measure a different "indent" depending on which of the three happens to be called on it, and a line inside a text block passes through both Span's notion (via the ordinary dispatch it bypasses) and Eo's own leadingSpaces without the two ever being reconciled. Routing every leading-whitespace measurement through one shared definition — Span.indent(), since it already backs the odd-indent and tab checks — would remove the risk of the text-block path disagreeing with the rest of the parser about what counts as indentation. @yegor256