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

Anonymous objects from nothing #812

Closed
lkuper opened this issue Aug 10, 2011 · 3 comments
Closed

Anonymous objects from nothing #812

lkuper opened this issue Aug 10, 2011 · 3 comments

Comments

@lkuper
Copy link
Contributor

lkuper commented Aug 10, 2011

Is there a reason why we'd want to be able to create an anonymous object from nothing, rather than extending an existing one?

For example, should we support being able to do this:

fn main() {

    // Anonymous object that doesn't extend an existing one.
    let my_obj = obj () {
        fn foo() -> int { ret 2; }
        fn bar() -> int { ret self.foo(); }
    };

    assert (my_obj.foo() == 2);
    assert (my_obj.bar() == 2);

}

If the answer is yes, then we need to finish implementing support for it. Right now, the parser and translator don't require an anon obj to have a "with" clause, and if there isn't one, translating an anon obj proceeds much like translating a regular obj would, with no forwarding/backwarding vtable slots created. But the above program fails in typechecking because the typechecker doesn't know what "self" is.

If the answer is no, we don't care about having this feature, we should get rid of what support does exist. Doing so would streamline the implementation of the object system a little.

@ghost ghost assigned lkuper Aug 10, 2011
@graydon
Copy link
Contributor

graydon commented Aug 10, 2011

I'd go with "yes" if it's not too difficult. Seems like a natural sort of thing to do; I imagine people will want an environment-capturing variant too, eventually.

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

marijnh commented Aug 11, 2011

(As an extra data point, consider that half the object in rustc are locally defined inside a function, and then immediately have their constructor called, with care taken to align the arguments in the call and the arglist. Object expressions would work much more natural in these cases.)

@lkuper
Copy link
Contributor Author

lkuper commented Aug 15, 2011

As it turns out, anon-objs-from-nothing already work fine as such. The above example doesn't work because it doesn't work in general to have a method A referring to another method B that is being added to an object at the same time as A. That's a problem, but has nothing to do with from-nothing objects as such. So I'll open a different issue for that bug, and close this one.

@lkuper lkuper closed this as completed in 93d425e Aug 15, 2011
@lkuper lkuper removed their assignment Jun 16, 2014
keeperofdakeys pushed a commit to keeperofdakeys/rust that referenced this issue Dec 12, 2017
Initial fixes for linux x32

Tested with a local build of rustc. The main test can be compiled but fails to execute (receives SIGTRAP, which I think in this case indicates memory violation, I will open an issue in the rustc repo).

This PR is important because it fixes the definition of `c_long` and `c_ulong`. Without these fixes, rustc crash with the error:

```
Cannot emit physreg copy instruction
UNREACHABLE executed at /checkout/src/llvm/lib/Target/X86/X86InstrInfo.cpp:5778!
```

Related rust-lang#37976
ZuseZ4 pushed a commit to EnzymeAD/rust that referenced this issue Mar 7, 2023
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
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