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.

Sign up for GitHub

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

Jump to bottom

Internal compiler error with structs, Option, and type ascription #5581

Closed
Tracked by #5562
ironcev opened this issue Feb 8, 2024 · 1 comment
Closed
Tracked by #5562

Internal compiler error with structs, Option, and type ascription #5581

ironcev opened this issue Feb 8, 2024 · 1 comment
Assignees
@esdrubal @ironcev
Labels
bug Something isn't working compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen compiler General compiler. Should eventually become more specific as the issue is triaged

Comments

@ironcev
Copy link
Member

ironcev commented Feb 8, 2024

This code fails with Internal compiler error: Verification failed: Struct field type mismatch..

script;
 
struct S<T> {
    x: T,
}

fn main() {
    let _: S<Option<u8>>  = S { x: Option::Some(1) };
}
@ironcev ironcev added bug Something isn't working compiler General compiler. Should eventually become more specific as the issue is triaged compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen labels Feb 8, 2024
@ironcev ironcev self-assigned this Feb 8, 2024
@ironcev ironcev mentioned this issue Feb 8, 2024
Open
19 tasks
esdrubal added a commit that referenced this issue Feb 21, 2024
@esdrubal
Adds reuse of enum variant TypeId.
d8e4809 
We already do unification of expressions with type annotation when necessary,
but these were not affecting enum variants because we used separate TypeIds for
the expression and for the enum variant.

With this change the enum variant and the expressions will share the same TypeId,
making unification to the expression to also affect the enum variant.

Fixes #5492
Fixes #5581

Probably helpful for #5559
@esdrubal esdrubal mentioned this issue Feb 21, 2024
Closed
7 tasks
@esdrubal esdrubal self-assigned this Feb 21, 2024
@ironcev ironcev mentioned this issue Feb 22, 2024
Merged
7 tasks
ironcev added a commit that referenced this issue Feb 23, 2024
@ironcev
Fix type check and inference issues in references, structs, and enums (…
3426dd1 
…#5643)

## Description

This PR:
- fixes #5559, #5597, and #5492 by removing the `TypeInfo::Unknown` and
providing the required contextual information to type checking of
referencing, dereferencing, `if`, and `match` expressions respectively.
The contextual information provided is taken from the
`ctx.type_annotation()` but always adapted according to the semantics of
the type-checked expression.
- fixes #5583 and #5581 by combining the contextual information coming
from the `ctx.type_annotation()` with the one coming from the enum and
struct instantiation and declaration.
- fixes #5598 by forcing the name-based and not structure-based
identity. In other words, two enums or structs are considered equal only
if they whole `call_path`s are equal. Up to now, we were expecting only
the enum or struct _names_ to be equal, which was treating types with
same names and structures (variants or fields) as equal although they
were defined in different modules.

The PR also introduces parsing of references to mutable values (`&mut
T`). Since this addition does not overlap with the above bug fixes, it
was left as is, and can be fully ignored during the review. Other
changes related to references to mutable values are removed from the
code from type-checking onward to make this PR only fixing the issues.
Continuation on references to mutable values will be done in a separate
PR.

Closes #5559, #5597, #5492, #5583, #5581, #5598.

## Checklist

- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
@ironcev
Copy link
Member Author

ironcev commented Feb 23, 2024

Closed in #5643.

@ironcev ironcev closed this as completed Feb 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@esdrubal esdrubal

@ironcev ironcev

Labels
bug Something isn't working compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen compiler General compiler. Should eventually become more specific as the issue is triaged
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Adds reuse of enum variant TypeId. FuelLabs/sway
2 participants
@esdrubal @ironcev