Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ast: Deprecating any() and all() built-in functions #4271

Merged

Conversation

johanfylling
Copy link
Contributor

Updating compiler strict mode to produce error when these deprecated methods are used.

Fixes: #2437
Signed-off-by: Johan Fylling johan.dev@fylling.se

types.B,
),
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just moving these down to the "deprecated" section.

ast/compile.go Outdated
@@ -4406,14 +4411,17 @@ func safetyErrorSlice(unsafe unsafeVars, rewritten map[Var]Var) (result Errors)
return
}

func checkUnsafeBuiltins(unsafeBuiltinsMap map[string]struct{}, node interface{}) Errors {
func checkUnsafeBuiltins(unsafeBuiltinsMap map[string]struct{}, deprecatedBuiltinsMap map[string]struct{}, node interface{}) Errors {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Perhaps I should rename this function as "unsafe" has a special meaning here. How are we on renaming existing compiler stages?
Although "unsafe" could also mean "implicitly unsafe"/"deprecated" ..

Copy link
Member

Choose a reason for hiding this comment

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

Renaming the internal function is fine, but renaming the stage could break callers because we have an API that lets them register custom stages before/after a stage name... I agree that "safe" is not the best term to use here. That said, the "unsafe function" support is deprecated in favor of using capabilities--so, I'd probably just leave the stage name as is (we can remove it entirely eventually.)

srenatus
srenatus previously approved these changes Jan 25, 2022
Copy link
Contributor

@srenatus srenatus left a comment

Choose a reason for hiding this comment

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

This looks good to me. The only alternative I'd have thought about was wrapping it into the check for undefined functions, https://github.com/open-policy-agent/opa/blob/main/ast/compile.go#L278. It's happening a little earlier the the compiler stages.

Updating compiler strict mode to produce error when these deprecated methods are used.

Fixes: open-policy-agent#2437
Signed-off-by: Johan Fylling <johan.dev@fylling.se>
tsandall
tsandall previously approved these changes Jan 29, 2022
Copy link
Member

@tsandall tsandall left a comment

Choose a reason for hiding this comment

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

Looks fine to me. I probably would have just put this into another stage but that's not a big deal.

ast/compile.go Outdated
@@ -4406,14 +4411,17 @@ func safetyErrorSlice(unsafe unsafeVars, rewritten map[Var]Var) (result Errors)
return
}

func checkUnsafeBuiltins(unsafeBuiltinsMap map[string]struct{}, node interface{}) Errors {
func checkUnsafeBuiltins(unsafeBuiltinsMap map[string]struct{}, deprecatedBuiltinsMap map[string]struct{}, node interface{}) Errors {
Copy link
Member

Choose a reason for hiding this comment

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

Renaming the internal function is fine, but renaming the stage could break callers because we have an API that lets them register custom stages before/after a stage name... I agree that "safe" is not the best term to use here. That said, the "unsafe function" support is deprecated in favor of using capabilities--so, I'd probably just leave the stage name as is (we can remove it entirely eventually.)

…re merge)

Signed-off-by: Johan Fylling <johan.dev@fylling.se>
@srenatus srenatus merged commit 503a520 into open-policy-agent:main Jan 31, 2022
@johanfylling johanfylling deleted the 2437/strict_any_all_deprecated branch January 31, 2022 10:18
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.

Deprecate and remove any() and all() functions
4 participants