-
Notifications
You must be signed in to change notification settings - Fork 157
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
Missing coercion site at assignment operators and argument passing #700
Comments
philberty
added a commit
that referenced
this issue
Oct 5, 2021
…type Coercion sites like CallExpr arguments must coerce the arguments for type checking, but we must still insert the type of the actual argument for that mapping not the coerced type. For example we might have: ```rust fn dynamic_dispatch(t: &dyn Bar) { t.baz(); } fn main() { let a = &Foo(123); dynamic_dispatch(a); } ``` Here the argument 'a' has a type of (&ADT{Foo}) but this is coerceable to (&dyn{Bar}) which is fine. The backend needs to be able to detect the coercion from the two types in order to generate the vtable code. This patch fixes the type checking such that we store the actual type of (&ADT{Foo}) at that argument mapping instead of the coerced one. Addresses: #700
philberty
added a commit
that referenced
this issue
Oct 5, 2021
…Expr When we coerce the types of arguments to the parameters of functions for example we must store the actual type of the argument at that HIR ID not the coerced ones. This gives the backend a chance to then figure out when to actually implement any coercion site code. such as computing the dynamic objects. Fixes: #700
bors bot
added a commit
that referenced
this issue
Oct 13, 2021
710: Ensure for Coercion Sites we emit the code nessecary r=philberty a=philberty Coercion sites in Rust can require extra code generation for CallExpressions arguments for example. This ensures we detect those cases and emit the extra code necessary. Please read the individual commit messages for more detail on how this works. Fixes #700 #708 #709 727: Remove lambda iterators in various HIR classes r=philberty a=dafaust (This is a revision of #726 with formatting fixes) This patch removes the lambda iterators used in various HIR objects. These iterators make interacting with the IR for static analysis more difficult. Instead, get_X () helpers are added for accessing elements, and uses of the iterators replaced with for loops. The following objects are adjusted in this patch: - HIR::ArrayElemsValues - HIR::TupleExpr - HIR::StructExprField - HIR::StructStruct - HIR::TupleStruct Fixes: #703 Fixes: #704 Fixes: #705 Fixes: #706 Fixes: #707 Co-authored-by: Philip Herron <philip.herron@embecosm.com> Co-authored-by: David Faust <david.faust@oracle.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The type-checking pass is correctly calling coerce for these cases but the backend code needs to have the opportunity to handle any conversions required for this and needs to call out to:
gccrs/gcc/rust/backend/rust-compile-stmt.h
Line 88 in fdcad08
The text was updated successfully, but these errors were encountered: