Linter fails to catch undefined objects and attributes in the code

[yegor256]

This is my code:

[n] > app
  QQ.io.stdout > @
    QQ.txt.sprintf *1
      "Hello, %s!"
      foo

Here, foo is not defined in the app object and there is no @ attribute in app. Obviously, it's a wrong reference to an object. Lints can catch this, but currently they don't. I'm getting this, in runtime:

Couldn't find object 'Φ.org.eolang.foo' because there's no class or package 'EOorg.EOeolang.EOfoo'

Let's create a lint for this.

[VasilevNStas]

@yegor256 @h1alexbel @Marat-Tim I looked into this and found that the fix is essentially already in the pipeline — the new mystery-object lint covers exactly this case.

What happens with this code

The reported snippet uses QQ.io.stdout / QQ.txt.sprintf. In the current parser (0.62.1) that QQ. notation produces parse errors on the phase lints operate on:

[2:3] error: 'trailing garbage after expression'
[4:0] error: 'indent increased by more than one level'

So the object tree is empty and there is nothing for a lint to look at. The realistic variant is the same code with an alias:

+alias org.eolang.io.stdout

[n] > app
  stdout > @
    sprintf
      "Hello, %s!"
      foo

Here foo resolves to base="Φ.foo" — a bare single-word reference. I verified that the full lint set on master does not flag it (only mandatory-meta warnings appear).

How it is covered

The mystery-object lint (added in PR #1241, linked to #20) reports exactly this shape: any base matching ^Φ\.[a-z][a-z0-9_-]*$ that is neither declared in the program nor one of the reserved org.eolang objects. Φ.foo matches that pattern, foo is not declared, and it is not in the reserved list — so it will be flagged as an error once PR #1241 is merged.

So this issue needs no separate lint; it becomes resolved by merging #1241. I'd suggest closing #682 as covered by #20 / #1241, or keeping it open as a regression check once that PR lands.