Skip to content

fix: reject some-in bindings that also appear in the domain - #9062

Open
BetterAndBetterII wants to merge 2 commits into
open-policy-agent:mainfrom
BetterAndBetterII:fix/some-in-self-ref
Open

fix: reject some-in bindings that also appear in the domain#9062
BetterAndBetterII wants to merge 2 commits into
open-policy-agent:mainfrom
BetterAndBetterII:fix/some-in-self-ref

Conversation

@BetterAndBetterII

Copy link
Copy Markdown

some i, x in xs[i] compiled because the domain was rewritten after the binding. Treat that overlap as a compile error. Fixes #9052.

some i, x in xs[i] compiled because the domain was rewritten after the binding. Treat that overlap as a compile error.

Fixes open-policy-agent#9052

Signed-off-by: Yuzhong Zhang <BetterAndBetterII@users.noreply.github.com>

@anderseknert anderseknert left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! Left a comment or two on implementation details, but besides that looking good to me 👍

Comment thread v1/ast/compile.go Outdated
if val != nil {
bound.Update(val.Vars())
}
domainVis := NewVarVisitor().WithParams(VarVisitorParams{SkipClosures: true})

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we not get this from the pool instead and return it later, as we do elsewhere in this file?

vis := varVisitorPool.Get()

Comment thread v1/ast/compile.go Outdated
if v0.IsWildcard() {
continue
}
errs = append(errs, NewError(CompileErr, decl.Loc(), "var %v used in some domain", v0))

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While some domain may be technically correct, I'm not sure all policy authors would know what that means. What do you think about tweaking the "var i assigned above" error you'd normally see if you tried to bind i before the some to say var i assigned before or something like that?

Signed-off-by: Yuzhong Zhang <BetterAndBetterII@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Same var bound in some .. in shouldn't be allowed in same some .. in expression

3 participants