You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix ICE in relation to local declarations with erroneous initializers (#5631)
## Description
Fixes#5616 and #5622.
When generating the IR for constant and variable declarations the name
being declared is not added to the local environment if the initializer
cannot be compiled. This can happen when initializing a constant using a
non-constant expression.
Since the name isn't added to the environment, and since we attempt to
continue compilation after an error, any attempt to use the name later
in the code will cause the name to not be found, which in turn causes
the IR converter to throw an ICE because it assumes that all used names
are in scope.
This PR fixes the issue by not throwing the initializer error until the
name has been added to the environment. Note that
1. The initializer must be compiled before the name is added to the
environment. The name should not be in scope during its own
initialization.
2. #5602 is blocking a more elegant solution to this problem. The lack
of a `Never` type means that the call to `convert_resolved_typeid` may
fail if the initializer diverges, and since that call must be made
before the new name can be added to the environment we check for
termination first. The order of operations is therefore currently a)
compile the initializer, then b) check that the initializer did not
result in an error and did not diverge, then c) resolve the type of the
name being declared, then d) add the name to the environment, and
finally e) throw an error if the initializer resulted in an error. Once
the `Never` type is introduced we can move the terminator check to the
end of that sequence.
## Checklist
- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] 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.
- [x] 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.
0 commit comments