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

glsl-in: Update initializer list type when parsing #2066

Merged
merged 1 commit into from
Oct 5, 2022

Conversation

JCapucho
Copy link
Collaborator

Previously when parsing an initializer list, the type passed to parse_initializer was not updated to reflect the child type, this caused implicit conversions to not work and nested initializer lists to not be allowed.

Copy link
Member

@jimblandy jimblandy left a comment

Choose a reason for hiding this comment

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

Looks good to me.

I wonder whether it would be helpful to put the bulk of this in a helper function, element_or_member_type(i: usize) -> Type or something.

Previously when parsing an initializer list, the type passed to
`parse_initializer` was not updated to reflect the child type, this
caused implicit conversions to not work and nested initializer lists to
not be allowed.
@JCapucho JCapucho force-pushed the glsl-nested-init-list branch from e442553 to 6621a41 Compare September 26, 2022 10:20
@JCapucho
Copy link
Collaborator Author

@jimblandy thanks for the suggestion, I've also took some time to improve the documentation, could you give it another look.

Comment on lines +27 to +29
/// Does not check if the index is valid and returns the same type
/// when indexing out-of-bounds a struct or indexing a non indexable
/// type.
Copy link
Member

Choose a reason for hiding this comment

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

You're counting on validation to complain if there are too many components - correct? (It does, in naga::valid::compose::validate_compose.)

This PR is still an improvement over the status quo, but tolerating bad indices here does mean that if someone supplies too many values in the initializer, you're going to be passing meaningless types to implicit_conversion, and the error messages will be pretty confusing. That is, you'll get weird GLSL front end errors, instead of the nice "too many components" error from the validator, because you'll never make it that far.

@jimblandy jimblandy merged commit e07fd98 into gfx-rs:master Oct 5, 2022
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.

2 participants