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

Type Propagation With Numerics #6371

Closed
IGI-111 opened this issue Aug 7, 2024 · 0 comments · Fixed by #6461
Closed

Type Propagation With Numerics #6371

IGI-111 opened this issue Aug 7, 2024 · 0 comments · Fixed by #6461
Assignees
Labels
audit-report Related to the audit report bug Something isn't working P: high Should be looked at if there are no critical issues left

Comments

@IGI-111
Copy link
Contributor

IGI-111 commented Aug 7, 2024

CS-FSSA-005

Variables in Sway are strongly typed i.e., there cannot be any implicit changes in their type. Consider the
following example:

script;
trait MyTrait{
 fn foo(ref mut self);
}
impl MyTrait for u64 {
 fn foo(ref mut self) {
 let x: &mut u64 = &mut self;
 log("64");
 }
}
impl MyTrait for u32 {
 fn foo(ref mut self) {
 let x: &mut u32 = &mut self;
 log("32");
 }
}
impl u64 {
 fn baz(self) {
 log("64");
 }
}
impl u32 {
 fn baz(self) {
 log("32");
 }
}
fn bar<T>(ref mut x: T) where T: MyTrait {
 x.foo();
}
fn main() {
 let mut a = 0;
 bar(a);
 let x: &u32 = &a;
 a.baz();
}

In the example, we define MyTrait which we then implement for u32 and u64. Moreover, we implement
function baz for these types. In main() we declare variable a. Since a is assigned a literal with no type
ascription, it is initially typed as numeric. We execute bar(a). The type checker at this point will
resolve to bar::<u64> and eventually calls foo() for u64 which logs 64. This means that a should be
typed as u64. However, we later assign a reference of a to x which is explicitly typed as &u32 which
coerces a to u32. We later, call a.baz() which calls foo() for u32 and logs 32. This script is
successfully compiled and executed as described, implying a type-propagation failure.

@IGI-111 IGI-111 added bug Something isn't working P: high Should be looked at if there are no critical issues left audit-report Related to the audit report labels Aug 7, 2024
esdrubal added a commit that referenced this issue Aug 23, 2024
To fix the Numeric type propagation we now do the type checking of code
blocks twice, first to collect all the unification and second to unify
the types of a previous namespace with the variable declarations types
of the current namespace.

This changes incurs a significative performance drop in the compilation time.
The test in release goes from 3 secs to 5 secs.

This can be improved significatively when we start using LexicalScopes
instead of cloning the whole namespace on each scope.

Fixes #6371
esdrubal added a commit that referenced this issue Aug 26, 2024
To fix the Numeric type propagation we now do the type checking of code
blocks twice, first to collect all the unification and second to unify
the types of a previous namespace with the variable declarations types
of the current namespace.

This changes incurs a significative performance drop in the compilation time.
The test in release goes from 3 secs to 5 secs.

This can be improved significatively when we start using LexicalScopes
instead of cloning the whole namespace on each scope.

Fixes #6371
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
audit-report Related to the audit report bug Something isn't working P: high Should be looked at if there are no critical issues left
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants