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

Missing coercion site at assignment operators and argument passing #700

Closed
philberty opened this issue Sep 30, 2021 · 0 comments · Fixed by #710
Closed

Missing coercion site at assignment operators and argument passing #700

philberty opened this issue Sep 30, 2021 · 0 comments · Fixed by #710
Assignees
Labels

Comments

@philberty
Copy link
Member

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:

init = coercion_site (init, actual, expected, stmt.get_locus ());

@philberty philberty added the bug label Sep 30, 2021
@philberty philberty self-assigned this Sep 30, 2021
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>
@bors bors bot closed this as completed in #710 Oct 13, 2021
@philberty philberty mentioned this issue Oct 18, 2021
51 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant