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

stage2: resolve panic on array-like tuple initialization #11185

Merged
merged 2 commits into from
Mar 16, 2022

Conversation

topolarity
Copy link
Contributor

@topolarity topolarity commented Mar 15, 2022

This resolves #11159

Assorted fixes here:

  1. Comptime fields should not affect whether a type has runtime bits
  2. We were not correctly deleting the field stores after recognizing that an array initializer was a comptime-known value.
  3. LLVM was not checking that the stored type had no runtime bits, and so would generate an invalid store.

This also adds several test cases for related bugs, just to check these in for later work. Initializing tuples with mixed comptime/runtime fields is unfortunately still broken (on both stage1 and stage2) - that will have to be tackled later, probably with #11162

@@ -3218,6 +3213,12 @@ fn zirValidateArrayInit(
break :inst block.instructions.items[block_index + 1];
};

// Array has one possible value, so value is always comptime-known
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This usage of OPV seems like it might be incorrect for tuples, since they can have OPV without that being shared by all their elements.

I kept it all the same for now, since this change is just to make sure that the calculation of first_block_index is not skipped.

I think we can tackle the array/tuple init differences in another PR, along with #11182

This resolves ziglang#11159

The problem was that:
  1. We were not correctly deleting the field stores after recognizing
     that an array initializer was a comptime-known value.
  2. LLVM was not checking that the final type had no runtime bits, and
     so would generate an invalid store.

This also adds several test cases for related bugs, just to check these
in for later work.
@andrewrk andrewrk merged commit 1149e8b into ziglang:master Mar 16, 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.

stage2: array-like tuple initialization gets LLVM verification panic
2 participants