-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Comments
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. |
(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.) |
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. |
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
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:
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.
The text was updated successfully, but these errors were encountered: