-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
overloaded-box
protocol changes
#22086
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
2d0a44d
to
0c88f76
Compare
(this isn't really up for review, so I removed the assignment to @nikomatsakis , who should nonetheless be cc'ed.) |
23ea741
to
989515c
Compare
(is not quite right yet, I think I need to accommodate #21988 in some as yet unknown-to-me manner.) |
b50cab7
to
53062c4
Compare
(okay I figured out how to accommodate #21988) |
cc #22181 |
3430c4d
to
2ed35df
Compare
9bc1982
to
c1d4f12
Compare
☔ The latest upstream changes (presumably #22797) made this pull request unmergeable. Please resolve the merge conflicts. |
c1d4f12
to
d0c965d
Compare
☔ The latest upstream changes (presumably #22510) made this pull request unmergeable. Please resolve the merge conflicts. |
d0c965d
to
aaf0563
Compare
☔ The latest upstream changes (presumably #22995) made this pull request unmergeable. Please resolve the merge conflicts. |
@nikomatsakis (i'm mostly expecting a rubber stamp, though feel free to investigate as much as you like. Oh, and I guess I still owe you some performance and code size comparison data.) |
box
protocol changesbox
protocol changes
☔ The latest upstream changes (presumably #22899) made this pull request unmergeable. Please resolve the merge conflicts. |
27b06bd
to
10f05f9
Compare
This looks good to me. I'd still like those measurements. ;) UPDATE: r+, in case it wasn't clear |
10f05f9
to
52f6957
Compare
Some rough code size data:
Baseline: 6048ba8
Numbers gathered via invocation:
(and then manually feeding the data into some scheme code for calculating the percent-deltas) |
52f6957
to
e8f64b6
Compare
☔ The latest upstream changes (presumably #23265) made this pull request unmergeable. Please resolve the merge conflicts. |
…ed to Box. Precursor for landing overloaded-`box`, since that will decouple the `box` syntax from the exchange heap (and in fact will eliminate the use of the two aforementioned lang items). Instead, the new demonstration program shows a definition of the `str_eq` lang item. (We do not have that many procedural lang-items to choose from, which is a good sign for our efforts to decouple the compiler from the runtime!) (This previously used a demo of `panic_bounds_check`, but a `str_eq` demonstration is both easier to code and arguably a more interesting aspect of the language to discuss.) Fix unsafe.md example.
e8f64b6
to
68b81c1
Compare
See also issue 22405, which tracks going back to `box <expr>` if possible in the future. Precursor for overloaded-`box` and placement-`in`; see Issue 22181.
…ck> }`. Note that `box <expr>` itself remains unchanged.
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.
68b81c1
to
a0e3c71
Compare
☔ The latest upstream changes (presumably #23292) made this pull request unmergeable. Please resolve the merge conflicts. |
@pnkfelix should we close this PR or keep it open? |
@nikomatsakis i guess i'll close it; I know where to find it when I get a chance to revive it (i.e. after I fix the |
Hack the move_val_init intrinsic to trans directly into the destination address. This is to remove an intermediate (and unnecessary) alloca on the stack that one otherwise suffers when using this intrinsic. This is part of the `box` protocol work; in particular, this is meant to address the `ptr::write` codegen issues alluded to at this comment: #22086 (comment) cc #22181
This is a bootstrapping illustration of the new box prototype. The main point is to illustrate the fallout that occurs with the compiler type inference as it (nearly) stands today. (Note that much of that fallout has now landed in PR #23002.)
This PR is a revised version of PR #22006, building upon PR #22012 to remove much (but certainly not all) of the fallout observed there.
Now most of the fallout in this PR is from where
box <expr>
was being used in contexts that are implicitly coerced toBox<Trait>
, which is not compatible with the new box protocol (at least, not yet), since the use of coercion there subverts the box-protocol's attempt to infer the appropriate boxed-type to create. (This is noted at this comment on the RFC.)cfg(works)
only actually "works" atop PR Propagate container across object cast #22012), with method names that reflect where I originally found in this in thelibsyntax
crate.impl
I found ofDefault for Box<[T]>
, which may or may not be an instance of the same problem.For now, I am usually getting around this by using
Box::new(..)
;in HEAP { <expr> }
can often fix such cases, but not always;Box::new(<expr>)
always works, though it may introduce an intermediate copy that could have been otherwise avoided.see also rust-lang/rfcs#809 (which is now merged as of this (updated) writing).
oh, and
[breaking-change]