"field not allowed" potential regression in evalv3, also with a confusing error path

[mvdan]

# With the old evaluator.
env CUE_EXPERIMENT=evalv3=0
exec cue vet -c

# With the new evaluator.
env CUE_EXPERIMENT=evalv3=1
exec cue vet -c

-- input.cue --
package p

#Fields: {
}
#Schema: {
    #Fields & {
        Routes: _
    }
    Routes: _
}

As of 46fc54a:

# With the old evaluator. (0.010s)
> env CUE_EXPERIMENT=evalv3=0
> exec cue vet -c
# With the new evaluator. (0.031s)
> env CUE_EXPERIMENT=evalv3=1
> exec cue vet -c
[stderr]
#Schema.Routes: field not allowed:
    ./input.cue:6:2
    ./input.cue:7:3
    ./input.cue:9:2

I think evalv3 is right in rejecting this; #Fields & {Routes: _} should fail as the definition does not allow any fields.

However, evalv2 accepted this. Given that we're trying to avoid any regressions in behavior, should evalv3 allow this too?

Also, the error message is rather confusing. #Schema.Routes is allowed, and it is even present in the input.

[mvdan]

@myitcv also correctly points out that line 9 has nothing to do with this error, and should not be part of the error output.

[jeffmccune]

Given that we're trying to avoid any regressions in behavior, should evalv3 allow this too?

For Holos, I prefer this were rejected. Each time I've encountered this it's been my mistake accidentally unifying a disallowed field. This usually takes the form of unifying at the wrong level, for example foo: #Bar & { name: "Emanon" } when #Bar: metadata: name: string, or vice-versa.

In these cases I wish CUE caught my mistake early and rejected it, ideally right in vscode as a problem. Too often it didn't complain and I spent considerable time hunting down why the final output wasn't what I expected.

I know other projects may be relying on this behavior and understand it may be too impactful to change, but Holos is early enough that we are not so for us at least I'd prefer the rejection. Perhaps it could be made a flag to opt-in to rejections?

[myitcv]

I prefer this were rejected.

To me at least this is clearly a bug in v2. i.e. v3 does the right thing in rejecting with an error (albeit the error message is slight off in terms of its positioning)

However, evalv2 accepted this. Given that we're trying to avoid any regressions in behavior, should evalv3 allow this too?

This question is really aimed at establishing how painful a transition it might be for some people who (accidentally) rely on v2's behaviour. In case it is a widespread "problem" we can offer means of opting in/out to flag that changes the behaviour to ease the transition. For example, see https://tip.cuelang.org/docs/reference/command/cue-help-environment/, in particular the CUE_DEBUG setting for openinline.

[mvdan]

Indeed that's my thinking @myitcv. My initial instinct matches @jeffmccune's, that this particular edge case is clearly a bug and not a particularly tricky one at that. I agree that we should only consider patching this up in v3 for better compatibility, much like CUE_DEBUG=openinline, if many users are running into this hiccup while upgrading. I ran into it here as part of my reduction, but I'm pretty sure that I was the one that introduced the bug. Jeff's original error was #3638, an "incomplete value" failure.