cmd/cue: syntax errors in potential inputs silently dropped

[myitcv]

What version of CUE are you using (cue version)?

$ cue version
cue version +bd9ae537 linux/arm64

Does this issue reproduce with the latest release?

Yes

What did you do?

! exec cue eval
cmp stderr stderr.golden

-- x.cue --
package x

x: 5
-- y.cue --
pacakge x

y: 4
-- stderr.golden --
expected label or ':', found 'IDENT' x:
    ./y.cue:1:9

What did you expect to see?

Subject to the suggestion below, a passing test.

What did you see instead?

> ! exec cue eval
[stdout]
x: 5
FAIL: /tmp/testscript1597855587/repro.txt/script.txt:1: unexpected command success

This conversation started off the back of a problem someone raised in Slack.

The issue today is that cue eval (not specific to eval) succeeds because cmd/cue sees the syntax error in y.cue and so ignores the file. However, it's hopefully obvious that the user intended the file to belong to package x.

Whilst an LSP implementation (#142) will likely help to prevent such syntax errors in the first place, we can't rule them out and it doesn't seem ideal that files with syntax errors silently get dropped.

Following a discussion with @rogpeppe, we believe that a better heuristic here would be to raise syntax errors unless it is known that a file does not belong to the set of packages specified as input to cmd/cue (hence the expectation in the testscript test above).

Under this suggestion, given a cmd/cue input package p, syntax errors would therefore be raised for:

• files without a (valid) package clause (that contain other syntax errors)
• files with a valid package p clause that contain syntax errors

But syntax errors would not be raised for:

• files without a package clause
• files which belongs to a different package (noting that a file can have a valid package clause but still have invalid syntax)
• files that belong to package p but are ignored by virtue of an unsatisfied build attribute

[rogpeppe]

Probably another issue, but I have thought for a while that files without a package clause that co-exist with files with a package clause should result in an error, because it's a very common mistake to make.

[mpvl]

@rogpeppe: if one looks at the original intent, then one could argue it should be allowed.

However, we could indeed require an explicit package _ or something in case such files need to coexist with package files.