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

Using methods in a first-class manner doesn't work #758

Closed
msullivan opened this issue Jul 28, 2011 · 3 comments
Closed

Using methods in a first-class manner doesn't work #758

msullivan opened this issue Jul 28, 2011 · 3 comments

Comments

@msullivan
Copy link
Contributor

obj foo() { fn f() { } }

fn main() {
    let my_foo = foo();
    let f = my_foo.f;
}

triggers

rustc: Instructions.cpp:968: void llvm::StoreInst::AssertOK(): Assertion `getOperand(0)->getType() == cast<PointerType>(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"' failed.
@ghost ghost assigned msullivan Jul 28, 2011
@msullivan msullivan reopened this Jul 28, 2011
@msullivan
Copy link
Contributor Author

This is because we don't treat methods like normal functions. Instead of representing them as a fn_pair, we represent them just as the function and track the object through a side channel. The function also takes an object instead of a closure ptr.

I was hoping that I could fix this by changing translation of methods so that foo.bar got translated into the fn_pair (bar, foo). This would simplify translation of method calls, simplify things, and fix #435 for free. Unfortunately it doesn't work. Objects are represented as two words (vtable ptr and body ptr) whereas closure pointers are one word.
Some modification of this scheme would be the prettiest way to solve this problem, but it might not fly with what we need for the rest of the object system.

The other approach is fixing #435 so that bind explicitly knows about binding object methods, and then automatically doing binds like we do for functions with type parameters.

@msullivan
Copy link
Contributor Author

Hm. Extending an existing object creates a new body that references the old one (and doesn't share the body like I had been thinking it might). That means that the vtbl pointer could just as easily be put in the body, reducing object pointers to a single word, simplifying method call handling, and making this this bug and #435 go away.

lkuper added a commit that referenced this issue Aug 9, 2011
@lkuper
Copy link
Contributor

lkuper commented Aug 9, 2011

This test is now failing with a segfault rather than an LLVM assertion, most likely due to recent object system rearrangement. Meanwhile, #435 is passing. Hm.

jdm pushed a commit to jdm/rust that referenced this issue Sep 21, 2011
LValues no longer carry information about generics and objs, instead
there's an extended form of lvalue, lval_maybe_callee, only used by
call and bind, which holds this info.

This makes it possible to take the value of a method and get a working
closure, and will (with some more work) allow us to call statically
known functions without loading from their pair.

Closes rust-lang#435
Closes rust-lang#758
keeperofdakeys pushed a commit to keeperofdakeys/rust that referenced this issue Dec 12, 2017
Add networking symbols for uclibc/x86_64
bors pushed a commit to rust-lang-ci/rust that referenced this issue Oct 26, 2020
Add object::write as alternative object file writer
flip1995 pushed a commit to flip1995/rust that referenced this issue May 21, 2024
Add new lint `while_float`

This PR adds a nursery lint that checks for while loops comparing floating point values.

changelog:
```
changelog: [`while_float`]: Checks for while loops comparing floating point values.
```

Fixes rust-lang#758
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
* Clarify some parts of install-guide.mc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants