-
Notifications
You must be signed in to change notification settings - Fork 13k
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
desugaring-based box placement-in (take-4 branch) #26180
Conversation
r? @sfackler (rust_highfive has picked a reviewer for you, use r? to override) |
Feel free to reassign. Also, you've already looked at much of this before, so feel free to ask me to point out the bits that are most different. Actually, let me try to do some of that off the bat; the newest parts of this are:
|
☔ The latest upstream changes (presumably #26192) made this pull request unmergeable. Please resolve the merge conflicts. |
update test/compile-fail/feature-gate-box-expr.rs to reflect new feature gates. Part of what lands with Issue 22181.
See discussion on Issue 22231.
Namely: * Update run-pass/new-box-syntax * Fix doc-embedded test for `alloc::boxed` to reflect new syntax. * Fix test/debuginfo/box.rs to reflect new syntax. Part of what lands with Issue 22181.
…t suite. Precursor for overloaded-`box` and placement-`in`; see Issue 22181.
Precursor for overloaded-`box` and placement-`in`; see Issue 22181.
… depth. This is a total hack; it not only needs a feature-gate, but probably should be feature-gated forever (if possible). ignore-pretty in test/run-pass/pushpop-unsafe-okay.rs
…dest`. rebase update to typeck/check/mod.rs
in effort to understand treatment of `allow_internal_unstable`.
… box protocol. Actually for some reason I opted for type-annotations for most of this. (And that's really what I should have been striving for in the other commits, but its just easier to write `Box::new` most of the time.)
Precursor for landing overloaded-box, since that will decouple the box syntax from the exchange heap (and should eliminate the use of the `malloc` and `free` lang items). (This is a simplified approach to PR rust-lang#22499; note that I have once again changes which lang item to use for the illustration.)
dca3dcf
to
a61490c
Compare
☔ The latest upstream changes (presumably #26955) made this pull request unmergeable. Please resolve the merge conflicts. |
@pnkfelix let's talk about this branch; I liked the idea of isolating out the placement new work and landing that first to avoid |
@nikomatsakis yeah I have just finished factoring the |
Nice. Niko -------- Original message -------- From: Felix S Klock II [email protected] Date:07/21/2015 12:21 (GMT-05:00) To: rust-lang/rust [email protected] Cc: Niko Matsakis [email protected] Subject: Re: [rust] desugaring-based box placement-in (take-4 branch) (#26180) — |
closing in favor of PR #27215. |
…akis Macro desugaring of `in PLACE { BLOCK }` into "simpler" expressions following the in-development "Placer" protocol. Includes Placer API that one can override to integrate support for `in` into one's own type. (See [RFC 809].) [RFC 809]: https://github.com/rust-lang/rfcs/blob/master/text/0809-box-and-in-for-stdlib.md Part of #22181 Replaced PR #26180. Turns on the `in PLACE { BLOCK }` syntax, while leaving in support for the old `box (PLACE) EXPR` syntax (since we need to support that at least until we have a snapshot with support for `in PLACE { BLOCK }`. (Note that we are not 100% committed to the `in PLACE { BLOCK }` syntax. In particular I still want to play around with some other alternatives. Still, I want to get the fundamental framework for the protocol landed so we can play with implementing it for non `Box` types.) ---- Also, this PR leaves out support for desugaring-based `box EXPR`. We will hopefully land that in the future, but for the short term there are type-inference issues injected by that change that we want to resolve separately.
Macro-desugaring of
box
and placement-box
into "simpler" expressions.Includes
Placer
API that one can override to integrate support forbox
into one's own type.Part of #22181
Does not turn on the
in <place-expr> { <block> ... }
syntax proposed in rust-lang/rfcs#809 , so there is still more to be done in that area. But I wanted to get this into the review pipeline now, since it is more invasive than we originally anticipated it being.