-
Notifications
You must be signed in to change notification settings - Fork 170
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 Iterators #1895
Comments
Updated the test case here i think I have mised up int impls from rust 1.29 and rust 1.49 so need to spent more time exracting code from libcore |
|
philberty
added a commit
that referenced
this issue
Aug 12, 2023
We hit an assertion with range based iterators here. This code was used to solve complex generics such as: struct Foo<X,Y>(X,Y); impl<T> Foo<T, i32> { fn test<Y>(self, a: Y) { } } The impl item will have the signiture of: fn test<T,Y> (Foo<T, i32> self, a:Y) So in the case where we have: let a = Foo(123f32, 456); a.test<bool>(true); We need to solve the generic argument T from the impl block by infering the arguments there and applying them so that when we apply the generic argument bool we dont end up in the case of missing number of generics. Addresses #1895 gcc/rust/ChangeLog: * typecheck/rust-hir-type-check-expr.cc (TypeCheckExpr::visit): remove hack Signed-off-by: Philip Herron <[email protected]>
philberty
added a commit
that referenced
this issue
Aug 12, 2023
We hit an assertion with range based iterators here. This code was used to solve complex generics such as: struct Foo<X,Y>(X,Y); impl<T> Foo<T, i32> { fn test<Y>(self, a: Y) { } } The impl item will have the signiture of: fn test<T,Y> (Foo<T, i32> self, a:Y) So in the case where we have: let a = Foo(123f32, 456); a.test<bool>(true); We need to solve the generic argument T from the impl block by infering the arguments there and applying them so that when we apply the generic argument bool we dont end up in the case of missing number of generics. Addresses #1895 gcc/rust/ChangeLog: * typecheck/rust-hir-type-check-expr.cc (TypeCheckExpr::visit): remove hack Signed-off-by: Philip Herron <[email protected]>
philberty
added a commit
that referenced
this issue
Aug 12, 2023
We do extra checking after the fact here to ensure its a valid candidate and in the case there is only one candidate lets just go for it. Addresses #1895 gcc/rust/ChangeLog: * backend/rust-compile-base.cc (HIRCompileBase::resolve_method_address): use the single candidate Signed-off-by: Philip Herron <[email protected]>
philberty
added a commit
that referenced
this issue
Aug 12, 2023
We can endup with duplicate symbol names for different intrinsics with our current hash setup. This adds in the mappings and extra info to improve hash uniqueness. Addresses #1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (check_for_cached_intrinsic): simplify this cached intrinsic check * backend/rust-mangle.cc (legacy_mangle_item): use new interface * typecheck/rust-tyty.h: new managle helper Signed-off-by: Philip Herron <[email protected]>
philberty
added a commit
that referenced
this issue
Aug 12, 2023
We can endup with duplicate symbol names for different intrinsics with our current hash setup. This adds in the mappings and extra info to improve hash uniqueness. Addresses #1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (check_for_cached_intrinsic): simplify this cached intrinsic check * backend/rust-mangle.cc (legacy_mangle_item): use new interface * typecheck/rust-tyty.h: new managle helper Signed-off-by: Philip Herron <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this issue
Aug 12, 2023
We hit an assertion with range based iterators here. This code was used to solve complex generics such as: struct Foo<X,Y>(X,Y); impl<T> Foo<T, i32> { fn test<Y>(self, a: Y) { } } The impl item will have the signiture of: fn test<T,Y> (Foo<T, i32> self, a:Y) So in the case where we have: let a = Foo(123f32, 456); a.test<bool>(true); We need to solve the generic argument T from the impl block by infering the arguments there and applying them so that when we apply the generic argument bool we dont end up in the case of missing number of generics. Addresses #1895 gcc/rust/ChangeLog: * typecheck/rust-hir-type-check-expr.cc (TypeCheckExpr::visit): remove hack Signed-off-by: Philip Herron <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this issue
Aug 12, 2023
We do extra checking after the fact here to ensure its a valid candidate and in the case there is only one candidate lets just go for it. Addresses #1895 gcc/rust/ChangeLog: * backend/rust-compile-base.cc (HIRCompileBase::resolve_method_address): use the single candidate Signed-off-by: Philip Herron <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this issue
Aug 12, 2023
We can endup with duplicate symbol names for different intrinsics with our current hash setup. This adds in the mappings and extra info to improve hash uniqueness. Addresses #1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (check_for_cached_intrinsic): simplify this cached intrinsic check * backend/rust-mangle.cc (legacy_mangle_item): use new interface * typecheck/rust-tyty.h: new managle helper Signed-off-by: Philip Herron <[email protected]>
philberty
added a commit
that referenced
this issue
Aug 21, 2023
There is a case where some generic types are holding onto inference variable pointers directly. So this gives the backend a chance to do one final lookup to resolve the type. This now allows us to compile a full test case for iterators but there is still one miscompilation in here which results in a segv on O2 and bad result on -O0. Addresses #1895 gcc/rust/ChangeLog: * backend/rust-compile-type.cc (TyTyResolveCompile::visit): do a final lookup gcc/testsuite/ChangeLog: * rust/compile/iterators1.rs: New test. Signed-off-by: Philip Herron <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this issue
Aug 23, 2023
There is a case where some generic types are holding onto inference variable pointers directly. So this gives the backend a chance to do one final lookup to resolve the type. This now allows us to compile a full test case for iterators but there is still one miscompilation in here which results in a segv on O2 and bad result on -O0. Addresses #1895 gcc/rust/ChangeLog: * backend/rust-compile-type.cc (TyTyResolveCompile::visit): do a final lookup gcc/testsuite/ChangeLog: * rust/compile/iterators1.rs: New test. Signed-off-by: Philip Herron <[email protected]>
philberty
added a commit
that referenced
this issue
Aug 31, 2023
The overflow intrinsic returns a tuple of (value, boolean) where it value is the operator result and boolean if it overflowed or not. The intrinsic here did not initilize the resulting tuple and therefore was creating a use before init error resulting in garbage results Addresses #1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (op_with_overflow_inner): fix use before init Signed-off-by: Philip Herron <[email protected]>
philberty
added a commit
that referenced
this issue
Aug 31, 2023
Ensure the uninit intrinsic does not get optimized away Addresses #1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (uninit_handler): Update fndecl attributes Signed-off-by: Philip Herron <[email protected]>
philberty
added a commit
that referenced
this issue
Aug 31, 2023
The intrinsic move_val_init was being optimized away even at -O0 because the function looked "pure" but this adds in the attributes to enforce that this function has side-effects to override that bad assumption by the middle-end. Addresses #1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (move_val_init_handler): mark as side-effects Signed-off-by: Philip Herron <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this issue
Aug 31, 2023
The overflow intrinsic returns a tuple of (value, boolean) where it value is the operator result and boolean if it overflowed or not. The intrinsic here did not initilize the resulting tuple and therefore was creating a use before init error resulting in garbage results Addresses #1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (op_with_overflow_inner): fix use before init Signed-off-by: Philip Herron <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this issue
Aug 31, 2023
Ensure the uninit intrinsic does not get optimized away Addresses #1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (uninit_handler): Update fndecl attributes Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 12, 2024
We can endup with duplicate symbol names for different intrinsics with our current hash setup. This adds in the mappings and extra info to improve hash uniqueness. Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (check_for_cached_intrinsic): simplify this cached intrinsic check * backend/rust-mangle.cc (legacy_mangle_item): use new interface * typecheck/rust-tyty.h: new managle helper Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 12, 2024
There is a case where some generic types are holding onto inference variable pointers directly. So this gives the backend a chance to do one final lookup to resolve the type. This now allows us to compile a full test case for iterators but there is still one miscompilation in here which results in a segv on O2 and bad result on -O0. Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-type.cc (TyTyResolveCompile::visit): do a final lookup gcc/testsuite/ChangeLog: * rust/compile/iterators1.rs: New test. Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 12, 2024
The overflow intrinsic returns a tuple of (value, boolean) where it value is the operator result and boolean if it overflowed or not. The intrinsic here did not initilize the resulting tuple and therefore was creating a use before init error resulting in garbage results Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (op_with_overflow_inner): fix use before init Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 12, 2024
Ensure the uninit intrinsic does not get optimized away Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (uninit_handler): Update fndecl attributes Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 12, 2024
The intrinsic move_val_init was being optimized away even at -O0 because the function looked "pure" but this adds in the attributes to enforce that this function has side-effects to override that bad assumption by the middle-end. Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (move_val_init_handler): mark as side-effects Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 12, 2024
We were massing the match scruitinee expression as a way to access the result of the expression. This is wrong and needs to be stored in a temporary otherwise it will cause the code to be regnerated for each time it is used. This is not an issue in the case where the expression is only used once. Fixes Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-expr.cc (CompileExpr::visit): use a temp for the value gcc/testsuite/ChangeLog: * rust/execute/torture/iter1.rs: New test. Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 16, 2024
We hit an assertion with range based iterators here. This code was used to solve complex generics such as: struct Foo<X,Y>(X,Y); impl<T> Foo<T, i32> { fn test<Y>(self, a: Y) { } } The impl item will have the signiture of: fn test<T,Y> (Foo<T, i32> self, a:Y) So in the case where we have: let a = Foo(123f32, 456); a.test<bool>(true); We need to solve the generic argument T from the impl block by infering the arguments there and applying them so that when we apply the generic argument bool we dont end up in the case of missing number of generics. Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * typecheck/rust-hir-type-check-expr.cc (TypeCheckExpr::visit): remove hack Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 16, 2024
We do extra checking after the fact here to ensure its a valid candidate and in the case there is only one candidate lets just go for it. Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-base.cc (HIRCompileBase::resolve_method_address): use the single candidate Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 16, 2024
We can endup with duplicate symbol names for different intrinsics with our current hash setup. This adds in the mappings and extra info to improve hash uniqueness. Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (check_for_cached_intrinsic): simplify this cached intrinsic check * backend/rust-mangle.cc (legacy_mangle_item): use new interface * typecheck/rust-tyty.h: new managle helper Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 16, 2024
There is a case where some generic types are holding onto inference variable pointers directly. So this gives the backend a chance to do one final lookup to resolve the type. This now allows us to compile a full test case for iterators but there is still one miscompilation in here which results in a segv on O2 and bad result on -O0. Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-type.cc (TyTyResolveCompile::visit): do a final lookup gcc/testsuite/ChangeLog: * rust/compile/iterators1.rs: New test. Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 16, 2024
The overflow intrinsic returns a tuple of (value, boolean) where it value is the operator result and boolean if it overflowed or not. The intrinsic here did not initilize the resulting tuple and therefore was creating a use before init error resulting in garbage results Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (op_with_overflow_inner): fix use before init Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 16, 2024
Ensure the uninit intrinsic does not get optimized away Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (uninit_handler): Update fndecl attributes Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 16, 2024
The intrinsic move_val_init was being optimized away even at -O0 because the function looked "pure" but this adds in the attributes to enforce that this function has side-effects to override that bad assumption by the middle-end. Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (move_val_init_handler): mark as side-effects Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 16, 2024
We were massing the match scruitinee expression as a way to access the result of the expression. This is wrong and needs to be stored in a temporary otherwise it will cause the code to be regnerated for each time it is used. This is not an issue in the case where the expression is only used once. Fixes Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-expr.cc (CompileExpr::visit): use a temp for the value gcc/testsuite/ChangeLog: * rust/execute/torture/iter1.rs: New test. Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 16, 2024
We hit an assertion with range based iterators here. This code was used to solve complex generics such as: struct Foo<X,Y>(X,Y); impl<T> Foo<T, i32> { fn test<Y>(self, a: Y) { } } The impl item will have the signiture of: fn test<T,Y> (Foo<T, i32> self, a:Y) So in the case where we have: let a = Foo(123f32, 456); a.test<bool>(true); We need to solve the generic argument T from the impl block by infering the arguments there and applying them so that when we apply the generic argument bool we dont end up in the case of missing number of generics. Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * typecheck/rust-hir-type-check-expr.cc (TypeCheckExpr::visit): remove hack Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 16, 2024
We do extra checking after the fact here to ensure its a valid candidate and in the case there is only one candidate lets just go for it. Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-base.cc (HIRCompileBase::resolve_method_address): use the single candidate Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 16, 2024
We can endup with duplicate symbol names for different intrinsics with our current hash setup. This adds in the mappings and extra info to improve hash uniqueness. Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (check_for_cached_intrinsic): simplify this cached intrinsic check * backend/rust-mangle.cc (legacy_mangle_item): use new interface * typecheck/rust-tyty.h: new managle helper Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 16, 2024
There is a case where some generic types are holding onto inference variable pointers directly. So this gives the backend a chance to do one final lookup to resolve the type. This now allows us to compile a full test case for iterators but there is still one miscompilation in here which results in a segv on O2 and bad result on -O0. Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-type.cc (TyTyResolveCompile::visit): do a final lookup gcc/testsuite/ChangeLog: * rust/compile/iterators1.rs: New test. Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 16, 2024
The overflow intrinsic returns a tuple of (value, boolean) where it value is the operator result and boolean if it overflowed or not. The intrinsic here did not initilize the resulting tuple and therefore was creating a use before init error resulting in garbage results Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (op_with_overflow_inner): fix use before init Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 16, 2024
Ensure the uninit intrinsic does not get optimized away Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (uninit_handler): Update fndecl attributes Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 16, 2024
The intrinsic move_val_init was being optimized away even at -O0 because the function looked "pure" but this adds in the attributes to enforce that this function has side-effects to override that bad assumption by the middle-end. Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (move_val_init_handler): mark as side-effects Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 16, 2024
We were massing the match scruitinee expression as a way to access the result of the expression. This is wrong and needs to be stored in a temporary otherwise it will cause the code to be regnerated for each time it is used. This is not an issue in the case where the expression is only used once. Fixes Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-expr.cc (CompileExpr::visit): use a temp for the value gcc/testsuite/ChangeLog: * rust/execute/torture/iter1.rs: New test. Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 17, 2024
We hit an assertion with range based iterators here. This code was used to solve complex generics such as: struct Foo<X,Y>(X,Y); impl<T> Foo<T, i32> { fn test<Y>(self, a: Y) { } } The impl item will have the signiture of: fn test<T,Y> (Foo<T, i32> self, a:Y) So in the case where we have: let a = Foo(123f32, 456); a.test<bool>(true); We need to solve the generic argument T from the impl block by infering the arguments there and applying them so that when we apply the generic argument bool we dont end up in the case of missing number of generics. Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * typecheck/rust-hir-type-check-expr.cc (TypeCheckExpr::visit): remove hack Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 17, 2024
We do extra checking after the fact here to ensure its a valid candidate and in the case there is only one candidate lets just go for it. Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-base.cc (HIRCompileBase::resolve_method_address): use the single candidate Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 17, 2024
We can endup with duplicate symbol names for different intrinsics with our current hash setup. This adds in the mappings and extra info to improve hash uniqueness. Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (check_for_cached_intrinsic): simplify this cached intrinsic check * backend/rust-mangle.cc (legacy_mangle_item): use new interface * typecheck/rust-tyty.h: new managle helper Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 17, 2024
There is a case where some generic types are holding onto inference variable pointers directly. So this gives the backend a chance to do one final lookup to resolve the type. This now allows us to compile a full test case for iterators but there is still one miscompilation in here which results in a segv on O2 and bad result on -O0. Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-type.cc (TyTyResolveCompile::visit): do a final lookup gcc/testsuite/ChangeLog: * rust/compile/iterators1.rs: New test. Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 17, 2024
The overflow intrinsic returns a tuple of (value, boolean) where it value is the operator result and boolean if it overflowed or not. The intrinsic here did not initilize the resulting tuple and therefore was creating a use before init error resulting in garbage results Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (op_with_overflow_inner): fix use before init Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 17, 2024
Ensure the uninit intrinsic does not get optimized away Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (uninit_handler): Update fndecl attributes Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 17, 2024
The intrinsic move_val_init was being optimized away even at -O0 because the function looked "pure" but this adds in the attributes to enforce that this function has side-effects to override that bad assumption by the middle-end. Addresses Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-intrinsic.cc (move_val_init_handler): mark as side-effects Signed-off-by: Philip Herron <[email protected]>
CohenArthur
pushed a commit
to CohenArthur/gccrs
that referenced
this issue
Jan 17, 2024
We were massing the match scruitinee expression as a way to access the result of the expression. This is wrong and needs to be stored in a temporary otherwise it will cause the code to be regnerated for each time it is used. This is not an issue in the case where the expression is only used once. Fixes Rust-GCC#1895 gcc/rust/ChangeLog: * backend/rust-compile-expr.cc (CompileExpr::visit): use a temp for the value gcc/testsuite/ChangeLog: * rust/execute/torture/iter1.rs: New test. Signed-off-by: Philip Herron <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a parent issue to track progress on getting for-loops working, which actually uses iterators under the hood.
Task List
split_current_token
implementation #1905Deref
bounds #2190Goal-test case:
The text was updated successfully, but these errors were encountered: