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

Support array types with dependent bounds. #4751

Open
wants to merge 2 commits into from

Conversation

zygoloid
Copy link
Contributor

@zygoloid zygoloid commented Jan 2, 2025

Given N:! i32, the type [T; N] is a valid but dependent array type.

@github-actions github-actions bot requested a review from jonmeow January 2, 2025 20:48
return ints().Get(insts().GetAs<IntValue>(bound_id).int_id).getZExtValue();
auto GetArrayBoundValue(InstId bound_id) const -> std::optional<uint64_t> {
if (auto bound = insts().TryGetAs<IntValue>(
constant_values().GetConstantInstId(bound_id))) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is bound_id in GetAs() changed to constant_values().GetConstantInstId(bound_id) in TryGetAs()? Inside they both call Get(inst_id). Does this allow some different inputs to GetArrayBoundValue? The callers are passing the same inst ids it seems.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

insts().GetAs<IntValue>(bound_id) requires bound_id to exactly be an IntValue instruction. Passing the instruction through constant_values().GetConstantInstId(bound_id) first allows any bound_id whose constant value is an IntValue. So the old formulation would fail on the bound in the array type [i32; 1 + 1] whereas the new formulation succeeds there.

I don't think this is necessary for any of the current callers of this function -- they all appear to be operating on canonical array types, which would have an IntValue as the bound_id if the bound is a constant integer. I don't remember why I made this change, but I think I was concerned about changing this from check-failing to silently returning nullopt in the case that an expression with a constant value were passed in, and the best solution seemed to be to make it return a correct bound in that case instead.

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh ok, thanks!

@zygoloid zygoloid enabled auto-merge January 8, 2025 19:53
@zygoloid zygoloid added this pull request to the merge queue Jan 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants