Skip to content

Conversation

john-h-kastner-aws
Copy link
Contributor

Fix #242

This required a way to print out internal types that aren't accepted by the parser. I used a namespace __cedar::internal for this, so, for example, a type error that expects any set will say that it expects Set<__cedar::internal::Any>.

Description of changes

Issue #, if available

Checklist for requesting a review

The change in this PR is (choose one, and delete the other options):

  • A bug fix or other functionality change requiring a patch to cedar-policy.

I confirm that this PR (choose one, and delete the other options):

  • Updates the "Unreleased" section of the CHANGELOG with a description of my change (required for major/minor version bumps).

I confirm that cedar-spec (choose one, and delete the other options):

  • Does not require updates because my change does not impact the Cedar formal model or DRT infrastructure.

Disclaimer

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@john-h-kastner-aws john-h-kastner-aws force-pushed the jkastner/friendly_types branch from ce0154b to eb0298b Compare March 8, 2024 17:35
Copy link
Contributor

@khieta khieta left a comment

Choose a reason for hiding this comment

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

Left a couple minor comments. This will make error messages much more readable!

Comment on lines +50 to +52
/// Convert a custom type AST into the JSON representation of the type.
/// Conversion is done in an empty context.
pub fn custom_type_to_json_type(ty: Node<Type>) -> Result<SchemaType, ToJsonSchemaErrors> {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why "custom" type? Isn't it just the internal Cedar type?

(Context: I was confused by the name at first because I was trying to figure out how it related to commonType definitions in the JSON / type declarations in the new schema syntax)

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 copied the phrasing from another function in this file. We could perhaps do a consistency pass so that we call the new schema format one name everywhere.

Comment on lines +2327 to +2328
// complete schema. TODO: the final stage of schema parsing already does
// this. Can we remove duplicated checks from human schema parsing?
Copy link
Contributor

Choose a reason for hiding this comment

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

Would be good to address this TODO in the PR, or file an issue for later & add the issue number to the comment

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it's not necessarily an easy change. #711

@john-h-kastner-aws john-h-kastner-aws force-pushed the jkastner/friendly_types branch from eb0298b to 8cd9427 Compare March 8, 2024 20:42
@john-h-kastner-aws john-h-kastner-aws merged commit 6ab6d80 into main Mar 8, 2024
khieta pushed a commit that referenced this pull request Mar 11, 2024
@john-h-kastner-aws john-h-kastner-aws deleted the jkastner/friendly_types branch March 12, 2024 19:30
shaobo-he-aws pushed a commit that referenced this pull request Apr 11, 2024
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.

Better error messages for Unexpected type errors
3 participants