"cycle error" regression with let fields between 0.4.3 and 0.5.0

[mvdan]

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

$ cue version
cue version v0.6.0-alpha.1.0.20230418084629-59080b65a5ba

go version devel go1.21-9d35ebba06 Thu Apr 20 01:07:29 2023 +0000
      -buildmode exe
       -compiler gc
        -ldflags -w -s
  DefaultGODEBUG panicnil=1
     CGO_ENABLED 1
          GOARCH amd64
            GOOS linux
         GOAMD64 v3

Does this issue reproduce with the latest stable release?

Yes; tested with v0.5.0 and master per the version output above.

What did you do?

$ cue export -
#GetF1: {
	in:  _
	out: in.f1
}

#PutOut1: {
	in: _
	out: out1: "\(in)"
}

export: {
	let data = {f1: "foo"}
	(#PutOut1 & {
		in: (#GetF1 & {
			in: data
		}).out
	}).out
}

What did you expect to see?

Same output as v0.4.3:

{
    "export": {
        "out1": "foo"
    }
}

What did you see instead?

invalid interpolation: cycle error:
    -:8:13

This bug is very similar to #2351; it's entirely possible that both will be fixed with the same commit. However, that other bug was replacing one error with a slightly less helpful error, whereas this bug is turning a successful export into an error. I also think the cycle isn't valid; just like with #2351, embedding a struct shouldn't break let definitions.

Thanks to @massive for reporting this bug and helping investigate it.

[mvdan]

Bisected to https://review.gerrithub.io/c/cue-lang/cue/+/543362, although that commit first broke this code with a slightly different error:

in: invalid interpolation: undefined field: data:
    ../../../../../tmp/f.cue:8:13
    ../../../../../tmp/f.cue:15:8

[morlay]

Not just let fields

#Build: {
	steps: [#Step, ...#Step]
	output: #Image

	_dag: {
		for idx, step in steps if idx == 0 {
			"\(idx)": step
		}

		for idx, step in steps if idx > 0 {
			"\(idx)": {
                                 // here throw cyclic task dependency in cueflow
                                 // it works well with v0.4.3 and v0.5.0-beta.1
				_prev: _dag["\(idx-1)"].output

				step & {
					input: _prev
				}
			}
		}
	}

	if len(_dag) > 0 {
		output: _dag["\(len(_dag)-1)"].output
	}
}

#Step: {
	input?: #Image
	output: #Image
	...
}

[mvdan]

@morlay could you please raise a new bug following the bug report template? That will include enough information for us to reproduce your problem and be able investigate it. What you shared here isn't enough, and on a first look, the lack of let fields means that it's a different issue.

[morlay]

@myitcv Sorry.
My case may a issue of tools/flow

I have to add new config DisableDynamicTasks to disable initTasks when after task.Fill() for a quick fix.
morlay@b9dd73e

Since v0.5.0-beta.2 (v0.5.0-beta.1 works well) the task deps will be changed after task.Fill() in complex workflow, even all tasks are static.
I will try to create another issue to post this, when I have enough time to make a simplier test case.

[morlay]

@myitcv just let you know.

Since I upgrade to v0.6.0-rc.1, my issue is gone without any patch.

[myitcv]

@myitcv just let you know.

Since I upgrade to v0.6.0-rc.1, my issue is gone without any patch.

Thanks very much for confirming, @morlay

[morlay]

Thanks very much for confirming, @morlay

cycle error is gone, but deps issue coming 🤣

#2516 #2517