Skip to content

Conversation

hudlow
Copy link
Contributor

@hudlow hudlow commented Jan 30, 2025

fixes #433

Copy link

@timostamm timostamm left a comment

Choose a reason for hiding this comment

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

I ran the added tests against cel-go, and can confirm that the expressions parse successfully - although I'm not sure that the conformance tests are suitable to cover them, see comments below.

Comment on lines 407 to 412
name: "struct_names"
description: "Check that reserved identifiers are permitted as struct names as long as they are not language keywords"
test {
name: "as"
description: "Check that `as` can be used as a struct name."
expr: "as{} || true"

Choose a reason for hiding this comment

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

Running these tests in cel-go at d8351df yields the error "unknown type: as" when planning the program (conformance_test.go:237).

So the expressions parse sucessfully, confirming that the identifiers are permitted in cel-go, but the planner expects a type as to be declared.

Comment on lines 530 to 535
name: "struct_fields"
description: "Check that reserved identifiers are permitted as struct fields as long as they are not language keywords"
test {
name: "as"
description: "Check that `as` can be used as a struct name."
expr: "a{ as: 1 } || true"

Choose a reason for hiding this comment

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

Same as the "struct_names" tests, these tests don't pass with cel-go because the planner expects a to be declared. They do parse successfully.

@TristonianJones
Copy link
Collaborator

/gcbrun

@TristonianJones
Copy link
Collaborator

@hudlow I'm fine with the updates to the grammar in the spec file. Maybe separate out the conformance test changes into another PR?

}
}
section {
name: "struct_names"
Copy link
Collaborator

Choose a reason for hiding this comment

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

We're going to restrict the use of identifiers in type names to declared types, which will render most of the struct_names tests moot. Perhaps remove this even though it's technically correct as it's not feasible to actually execute?

test {
name: "as"
description: "Check that `as` can be used as a struct name."
expr: "a{ as: 1 } || true"
Copy link
Collaborator

Choose a reason for hiding this comment

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

The recommendation would be to update the TestAllTypes proto with fields that use the reserved identifiers. We may need to enable backtick syntax in the CEL environment to support this case, but I believe it will work if we do.

@hudlow hudlow marked this pull request as ready for review March 16, 2025 20:35
@hudlow
Copy link
Contributor Author

hudlow commented Mar 16, 2025

Per suggestion, updated to separate out test changes

@hudlow hudlow requested a review from TristonianJones March 17, 2025 16:26
@TristonianJones
Copy link
Collaborator

/gcbrun

@TristonianJones TristonianJones merged commit ed0181b into google:master Mar 24, 2025
1 of 2 checks passed
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.

Are reserved identifiers permitted for member access?

3 participants