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

Adding support for extending objects with methods that override existing methods in the presence of self-calls #543

Closed
lkuper opened this issue Jun 21, 2011 · 2 comments

Comments

@lkuper
Copy link
Contributor

lkuper commented Jun 21, 2011

This is tricky because we have to make sure that the meaning of 'self' is also overridden. Currently xfail'd test: src/test/run-pass/anon-obj-overriding.rs.

@ghost ghost assigned lkuper Jun 21, 2011
lkuper added a commit that referenced this issue Jun 21, 2011
into four separate issues (#538, #539, #540, #543) with corresponding
tests.
lkuper added a commit that referenced this issue Jul 8, 2011
Previously, we were creating both a normal vtable entry and a
forwarding function for overriding methods, when they should have just
gotten a vtable entry.  This patch fixes that.
@lkuper
Copy link
Contributor Author

lkuper commented Jul 14, 2011

Status update: All the code (forwarding functions and such) is in place to support method overloading, but there's still at least one memory corruption bug to fix before I can close this issue. Here's a reduced test case:

fn main() {

    obj a() {
        fn foo() -> int {
            ret 2;
        }
    }

    auto my_a = a();

    auto my_b = obj() {
        fn foo() -> int {
            ret 3;
        }
        with my_a
    };

    assert (my_b.foo() == 3);
}

my_b.foo() returns 3, as we want it to, but when this program runs under valgrind we get an invalid read followed by an invalid write. Here's what I've been able to suss out: the invalid read and write are happening in drop glue, when trying to decrement a refcount. In particular, we're trying to read from, then write to, a location that contains a refcount. Either it's not actually the location of the refcount we're supposed to be decrementing, or we are not actually supposed to be decrementing anyone's refcount; I don't know which. When we compile with -g, the name of the function in which the invalid read/write happen is _ZN9glue_drop17O_5B_Ffoo_5B__5D_iFfoo_5B__5D_i_5D_17_9c52ab87ea8f24c9E. I'm not actually sure which drop glue this corresponds to; presumably it's either for the anon obj or the regular obj.

Attempting to debug from the top down, instead: the only new code that deals with drop glue (or cleanups in general) is here, where I add a cleanup for the pair I'm allocating for the anonymous object. It's entirely possible that I'm doing this wrong because I'm just guessing at what I should be passing to add_clean_temp (should it be the result of alloca, or the value from the result of trans_malloc_boxed, later, or something else?) or what type I should be passing (the node_id_type of the anon obj node, or body_ty, later, or something else?).

lkuper added a commit that referenced this issue Jul 20, 2011
I'm not sure if this is because of changes to glue generation in the
last few days while I've been working on other things, or if it's a
side effect of the improvements I made to typechecking for anonymous
objects, or something else, but I guess I'll take it!

Closes issue #543.
@lkuper
Copy link
Contributor Author

lkuper commented Jul 20, 2011

I just discovered that the tests for ths issue are suddenly passing valgrind for some reason. I'm not sure if it's because of changes to glue generation in the last few days while I've been working on other things, or if it's a side effect of the improvements I made to typechecking for anonymous objects, or something else, but I guess I'll take it. Meanwhile, the larger problem that graydon had suggested was at the heart of the memory corruption I was getting is still present and manifesting itself as issue #702. (But in the tests for that issue, we don't get memory corruption, we get flat-out wrong answers!) So there's clearly still something to fix, but in the meantime, I un-xfail'd the tests for this issue and am declaring it tentatively fixed...

@lkuper lkuper closed this as completed Jul 20, 2011
@lkuper lkuper removed their assignment Jun 16, 2014
keeperofdakeys pushed a commit to keeperofdakeys/rust that referenced this issue Dec 12, 2017
Adds many socket related constants

Started off adding a few constants to help cleaning up some `nix-rust/nix` issues.  Went a little.. further.

Adds lots of socket-related constants (`PF_*`, `MSG_*`, `AF_*`, `SO_*`, `SOL_*`, etc.) to linux/bsd flavors.

Added constants to `bsd/frebsdlike/dragonfly` for completeness, though they aren't covered by CI.  Did not touch `notbsd/linux/s390x.rs`
kazcw pushed a commit to kazcw/rust that referenced this issue Oct 23, 2018
Add support for `smlad` and `smlsd`.

- `smlad`: Dual 16-bit Signed Multiply with Addition and
           32-bit accumulation

- `smlsd`: Dual 16-bit Signed Multiply with Subtraction and
           32-bit accumulation
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
I refactored how we codegen panic statements so it now it terminate the
program per its spec. I have also removed the hack we had to try to get
the assert location.

Since we currently do not support stack unwinding, the panic codegen
will always terminate immediately and it will not try to unwind the stack.
I added an option to RMC to force the compiler to use abort as the panic
strategy and a check to rmc codegen that will fail if the user tries to
override that.

Another note is that we currently do not support `#[track_caller]` and I
have not changed that.

This change fixes rust-lang#67, fixes rust-lang#466, fixes rust-lang#543, and fixes rust-lang#636. This
change also mitigates rust-lang#545.
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

1 participant