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

Implement optimization fuel and re-enable struct field reordering #40377

Merged
merged 9 commits into from Apr 12, 2017

Conversation

Projects
None yet
@camlorn
Contributor

camlorn commented Mar 9, 2017

See this discussion for background.

This pull request adds two new compilation options: -Z print-fuel=crate prints the optimization fuel used by a crate and -Z fuel=crate=n sets the optimization fuel for a crate.

It also turns field reordering back on. There is no way to test this feature without something consuming fuel. We can roll this back if we want, but then the optimization fuel bits will be dead code.

The one notable absence from this PR is a test case. I'm not sure how to do one that's worth having. The only thing I can think of to test is -Z fuel=foo=0. The problem with other tests is that either (1) they're so big that future optimizations will apply, thus breaking them or (2) we don't know which order the optimizations will be applied in, so we can't guess the message that will be printed. If someone has a useful proposal for a good test, I certainly want to add one.

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Mar 9, 2017

Collaborator

r? @arielb1

(rust_highfive has picked a reviewer for you, use r? to override)

Collaborator

rust-highfive commented Mar 9, 2017

r? @arielb1

(rust_highfive has picked a reviewer for you, use r? to override)

@camlorn

This comment has been minimized.

Show comment
Hide comment
@camlorn

camlorn Mar 9, 2017

Contributor

To be honest, we probably want:

r? @eddyb

Contributor

camlorn commented Mar 9, 2017

To be honest, we probably want:

r? @eddyb

@rust-highfive rust-highfive assigned eddyb and unassigned arielb1 Mar 9, 2017

@eddyb

eddyb approved these changes Mar 9, 2017

LGTM, except for the (accidental) submodule changes.

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Mar 9, 2017

Member

I was going to cc @rust-lang/compiler, but I think I'll also nominate it for discussion tomorrow.

Member

eddyb commented Mar 9, 2017

I was going to cc @rust-lang/compiler, but I think I'll also nominate it for discussion tomorrow.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Mar 9, 2017

Contributor

Discussed in @rust-lang/compiler -- let's land this thing! It'd be nice to have some sort of tests. We talked about having a test that checks that we disabled reordering on one out of two structs (by supplying one unit of fuel). We might have to adjust the test in the future but for now it's ok.

Contributor

nikomatsakis commented Mar 9, 2017

Discussed in @rust-lang/compiler -- let's land this thing! It'd be nice to have some sort of tests. We talked about having a test that checks that we disabled reordering on one out of two structs (by supplying one unit of fuel). We might have to adjust the test in the future but for now it's ok.

@camlorn

This comment has been minimized.

Show comment
Hide comment
@camlorn

camlorn Mar 9, 2017

Contributor

I hope to do the tests this evening when I get back. Should they be under run-pass? Going to hit the no fuel and 1 fuel cases.

Contributor

camlorn commented Mar 9, 2017

I hope to do the tests this evening when I get back. Should they be under run-pass? Going to hit the no fuel and 1 fuel cases.

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Mar 9, 2017

Member

@camlorn Maybe an ui test for the layout of the structs? i.e. like the existing ones you updated here.

Member

eddyb commented Mar 9, 2017

@camlorn Maybe an ui test for the layout of the structs? i.e. like the existing ones you updated here.

@camlorn

This comment has been minimized.

Show comment
Hide comment
@camlorn

camlorn Mar 9, 2017

Contributor

@eddyb
that would require knowing which one is being optimized. @nikomatsakis's idea is better: get the size of 2 structs and assert that only one of them is right.

But this means it won't have a UI.

Contributor

camlorn commented Mar 9, 2017

@eddyb
that would require knowing which one is being optimized. @nikomatsakis's idea is better: get the size of 2 structs and assert that only one of them is right.

But this means it won't have a UI.

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Mar 9, 2017

Member

@camlorn It's in AST order, i.e. struct Foo; struct Bar; will need 1 for the first and 2 for both.
That's ignoring on-demand but on-demand should only kick in if you mention that type elsewhere.

Member

eddyb commented Mar 9, 2017

@camlorn It's in AST order, i.e. struct Foo; struct Bar; will need 1 for the first and 2 for both.
That's ignoring on-demand but on-demand should only kick in if you mention that type elsewhere.

@camlorn

This comment has been minimized.

Show comment
Hide comment
@camlorn

camlorn Mar 10, 2017

Contributor

@eddyb
I will do a UI test if that is what you really really want. But it's kind of overkill. All we have to do is ask if the size is right, because a bunch of other tests already cover the optimization itself.

I can't get to this tonight, it's going to have to be the morning. It will not be some morning in a month from now, it will be tomorrow morning.

Contributor

camlorn commented Mar 10, 2017

@eddyb
I will do a UI test if that is what you really really want. But it's kind of overkill. All we have to do is ask if the size is right, because a bunch of other tests already cover the optimization itself.

I can't get to this tonight, it's going to have to be the morning. It will not be some morning in a month from now, it will be tomorrow morning.

@camlorn

This comment has been minimized.

Show comment
Hide comment
@camlorn

camlorn Mar 10, 2017

Contributor

Okay. There we go. 100% test coverage. And I don't think any of them are even fragile.

Contributor

camlorn commented Mar 10, 2017

Okay. There we go. 100% test coverage. And I don't think any of them are even fragile.

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb
Member

eddyb commented Mar 10, 2017

@bors r+

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Mar 10, 2017

Contributor

📌 Commit 94a0375 has been approved by eddyb

Contributor

bors commented Mar 10, 2017

📌 Commit 94a0375 has been approved by eddyb

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Mar 13, 2017

Contributor

🔒 Merge conflict

Contributor

bors commented Mar 13, 2017

🔒 Merge conflict

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Mar 13, 2017

Member

@bors retry

Member

eddyb commented Mar 13, 2017

@bors retry

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Mar 13, 2017

Contributor

🔒 Merge conflict

Contributor

bors commented Mar 13, 2017

🔒 Merge conflict

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 13, 2017

Member

@bors: r=eddyb

Member

alexcrichton commented Mar 13, 2017

@bors: r=eddyb

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Mar 13, 2017

Contributor

📌 Commit 3fb94b7 has been approved by eddyb

Contributor

bors commented Mar 13, 2017

📌 Commit 3fb94b7 has been approved by eddyb

@camlorn

This comment has been minimized.

Show comment
Hide comment
@camlorn

camlorn Mar 13, 2017

Contributor

Wait, what happened here?

Contributor

camlorn commented Mar 13, 2017

Wait, what happened here?

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 13, 2017

Member

bors is getting confused nowadays due to submodule updates and such, so it'll think there's a merge conflict when there isn't one. I rebased the branch and r+'d it.

Member

alexcrichton commented Mar 13, 2017

bors is getting confused nowadays due to submodule updates and such, so it'll think there's a merge conflict when there isn't one. I rebased the branch and r+'d it.

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Mar 14, 2017

Contributor

⌛️ Testing commit 3fb94b7 with merge e67c62b...

Contributor

bors commented Mar 14, 2017

⌛️ Testing commit 3fb94b7 with merge e67c62b...

bors added a commit that referenced this pull request Mar 14, 2017

Auto merge of #40377 - camlorn:optimization_fuel, r=eddyb
Implement optimization fuel and re-enable struct field reordering

See [this discussion](https://internals.rust-lang.org/t/rolling-out-or-unrolling-struct-field-reorderings/4485) for background.

This pull request adds two new compilation options: `-Z print-fuel=crate` prints the optimization fuel used by a crate and `-Z fuel=crate=n` sets the optimization fuel for a crate.

It also turns field reordering back on.  There is no way to test this feature without something consuming fuel.  We can roll this back if we want, but then the optimization fuel bits will be dead code.

The one notable absence from this PR is a test case.  I'm not sure how to do one that's worth having.  The only thing I can think of to test is `-Z fuel=foo=0`.  The problem with other tests is that either (1) they're so big that future optimizations will apply, thus breaking them or (2) we don't know which order the optimizations will be applied in, so we can't guess the message that will be printed.  If someone has a useful proposal for a good test, I certainly want to add one.
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Mar 14, 2017

Contributor

💔 Test failed - status-travis

Contributor

bors commented Mar 14, 2017

💔 Test failed - status-travis

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 14, 2017

Member
Member

alexcrichton commented Mar 14, 2017

frewsxcv added a commit to frewsxcv/rust that referenced this pull request Mar 14, 2017

Rollup merge of #40377 - camlorn:optimization_fuel, r=eddyb
Implement optimization fuel and re-enable struct field reordering

See [this discussion](https://internals.rust-lang.org/t/rolling-out-or-unrolling-struct-field-reorderings/4485) for background.

This pull request adds two new compilation options: `-Z print-fuel=crate` prints the optimization fuel used by a crate and `-Z fuel=crate=n` sets the optimization fuel for a crate.

It also turns field reordering back on.  There is no way to test this feature without something consuming fuel.  We can roll this back if we want, but then the optimization fuel bits will be dead code.

The one notable absence from this PR is a test case.  I'm not sure how to do one that's worth having.  The only thing I can think of to test is `-Z fuel=foo=0`.  The problem with other tests is that either (1) they're so big that future optimizations will apply, thus breaking them or (2) we don't know which order the optimizations will be applied in, so we can't guess the message that will be printed.  If someone has a useful proposal for a good test, I certainly want to add one.

bors added a commit that referenced this pull request Mar 14, 2017

Auto merge of #40513 - frewsxcv:rollup, r=frewsxcv
Rollup of 12 pull requests

- Successful merges: #40346, #40377, #40387, #40433, #40456, #40457, #40466, #40467, #40495, #40496, #40497, #40503
- Failed merges:
@arielb1

This comment has been minimized.

Show comment
Hide comment
@arielb1

arielb1 Mar 14, 2017

Contributor

@bors r-

Contributor

arielb1 commented Mar 14, 2017

@bors r-

@arielb1

This comment has been minimized.

Show comment
Hide comment
@arielb1

arielb1 Mar 14, 2017

Contributor

@bors r+

Contributor

arielb1 commented Mar 14, 2017

@bors r+

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Mar 14, 2017

Contributor

📌 Commit 3fb94b7 has been approved by arielb1

Contributor

bors commented Mar 14, 2017

📌 Commit 3fb94b7 has been approved by arielb1

@arielb1

This comment has been minimized.

Show comment
Hide comment
@arielb1

arielb1 Mar 14, 2017

Contributor

@bors retry

Contributor

arielb1 commented Mar 14, 2017

@bors retry

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Mar 15, 2017

Contributor

⌛️ Testing commit 3fb94b7 with merge 26ae2c0...

Contributor

bors commented Mar 15, 2017

⌛️ Testing commit 3fb94b7 with merge 26ae2c0...

@eddyb

eddyb approved these changes Apr 11, 2017

r=me with nits fixed (@nagisa, feel free to do them on your branch and I'll push here)

Show outdated Hide outdated src/librustc/session/mod.rs
Show outdated Hide outdated src/librustc/session/mod.rs
Show outdated Hide outdated src/librustc_driver/lib.rs
Show outdated Hide outdated src/librustc_trans/intrinsic.rs
@@ -386,7 +386,7 @@ fn arg_local_refs<'a, 'tcx>(bcx: &Builder<'a, 'tcx>,
let lvalue = LvalueRef::alloca(bcx, arg_ty, &format!("arg{}", arg_index));
for (i, &tupled_arg_ty) in tupled_arg_tys.iter().enumerate() {
let dst = bcx.struct_gep(lvalue.llval, i);
let (dst, _) = lvalue.trans_field_ptr(bcx, i);

This comment has been minimized.

@eddyb

eddyb Apr 11, 2017

Member

Same but here it's less worrying because we know it can't be anything other than a tuple, and those don't get packed or anything like that, and store_fn_arg doesn't take such an argument.

@eddyb

eddyb Apr 11, 2017

Member

Same but here it's less worrying because we know it can't be anything other than a tuple, and those don't get packed or anything like that, and store_fn_arg doesn't take such an argument.

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb
Member

eddyb commented Apr 11, 2017

@bors r+

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 11, 2017

Contributor

📌 Commit e18c59f has been approved by eddyb

Contributor

bors commented Apr 11, 2017

📌 Commit e18c59f has been approved by eddyb

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 11, 2017

Contributor

⌛️ Testing commit e18c59f with merge 13c909d...

Contributor

bors commented Apr 11, 2017

⌛️ Testing commit e18c59f with merge 13c909d...

bors added a commit that referenced this pull request Apr 11, 2017

Auto merge of #40377 - camlorn:optimization_fuel, r=eddyb
Implement optimization fuel and re-enable struct field reordering

See [this discussion](https://internals.rust-lang.org/t/rolling-out-or-unrolling-struct-field-reorderings/4485) for background.

This pull request adds two new compilation options: `-Z print-fuel=crate` prints the optimization fuel used by a crate and `-Z fuel=crate=n` sets the optimization fuel for a crate.

It also turns field reordering back on.  There is no way to test this feature without something consuming fuel.  We can roll this back if we want, but then the optimization fuel bits will be dead code.

The one notable absence from this PR is a test case.  I'm not sure how to do one that's worth having.  The only thing I can think of to test is `-Z fuel=foo=0`.  The problem with other tests is that either (1) they're so big that future optimizations will apply, thus breaking them or (2) we don't know which order the optimizations will be applied in, so we can't guess the message that will be printed.  If someone has a useful proposal for a good test, I certainly want to add one.
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 11, 2017

Contributor

💔 Test failed - status-travis

Contributor

bors commented Apr 11, 2017

💔 Test failed - status-travis

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Apr 11, 2017

Contributor

@bors retry

Contributor

TimNN commented Apr 11, 2017

@bors retry

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 11, 2017

Contributor

⌛️ Testing commit e18c59f with merge 0da1c20...

Contributor

bors commented Apr 11, 2017

⌛️ Testing commit e18c59f with merge 0da1c20...

bors added a commit that referenced this pull request Apr 11, 2017

Auto merge of #40377 - camlorn:optimization_fuel, r=eddyb
Implement optimization fuel and re-enable struct field reordering

See [this discussion](https://internals.rust-lang.org/t/rolling-out-or-unrolling-struct-field-reorderings/4485) for background.

This pull request adds two new compilation options: `-Z print-fuel=crate` prints the optimization fuel used by a crate and `-Z fuel=crate=n` sets the optimization fuel for a crate.

It also turns field reordering back on.  There is no way to test this feature without something consuming fuel.  We can roll this back if we want, but then the optimization fuel bits will be dead code.

The one notable absence from this PR is a test case.  I'm not sure how to do one that's worth having.  The only thing I can think of to test is `-Z fuel=foo=0`.  The problem with other tests is that either (1) they're so big that future optimizations will apply, thus breaking them or (2) we don't know which order the optimizations will be applied in, so we can't guess the message that will be printed.  If someone has a useful proposal for a good test, I certainly want to add one.
@camlorn

This comment has been minimized.

Show comment
Hide comment
@camlorn

camlorn Apr 11, 2017

Contributor

@nagisa
Thanks.

Closure arguments. Figures. This was the weird bug last time.

Hoping this merges.

Contributor

camlorn commented Apr 11, 2017

@nagisa
Thanks.

Closure arguments. Figures. This was the weird bug last time.

Hoping this merges.

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Apr 11, 2017

Member

@camlorn I'm really sorry I forgot about it, I thought it got fixed and never checked.

Member

eddyb commented Apr 11, 2017

@camlorn I'm really sorry I forgot about it, I thought it got fixed and never checked.

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 11, 2017

Contributor

💔 Test failed - status-travis

Contributor

bors commented Apr 11, 2017

💔 Test failed - status-travis

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Apr 11, 2017

Contributor

@bors retry

Contributor

TimNN commented Apr 11, 2017

@bors retry

@camlorn

This comment has been minimized.

Show comment
Hide comment
@camlorn

camlorn Apr 11, 2017

Contributor

@eddyb
Just to repeat what got said on IRC for anyone else following, we did fix stuff related to this already.

No one is really sure how in the world the compiler passed all the tests in January at this point, but, well, it did.

Contributor

camlorn commented Apr 11, 2017

@eddyb
Just to repeat what got said on IRC for anyone else following, we did fix stuff related to this already.

No one is really sure how in the world the compiler passed all the tests in January at this point, but, well, it did.

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Apr 11, 2017

Member

I figured out what was happening: in rustc_trans we used to have a few shims that proxied their arguments irrespective of their types - that means that extern "rust-call" fn shims (e.g. Fn trait objects) only saw the expanded tuples, and never had a value of the tuple type.

However, @arielb1's #39628 resulted in the shims in those cases (e.g. again, Fn trait object) being translated the same way as functions defined extern "rust-call" fn, which involved the incorrect code storing arguments to tuple fields, never have been fixed until today.

The only reason it didn't break before is because such functions are rare and require unstable Rust to write - the only semi-common example I can think of is FnBox which isn't usually used with multiple arguments.

Member

eddyb commented Apr 11, 2017

I figured out what was happening: in rustc_trans we used to have a few shims that proxied their arguments irrespective of their types - that means that extern "rust-call" fn shims (e.g. Fn trait objects) only saw the expanded tuples, and never had a value of the tuple type.

However, @arielb1's #39628 resulted in the shims in those cases (e.g. again, Fn trait object) being translated the same way as functions defined extern "rust-call" fn, which involved the incorrect code storing arguments to tuple fields, never have been fixed until today.

The only reason it didn't break before is because such functions are rare and require unstable Rust to write - the only semi-common example I can think of is FnBox which isn't usually used with multiple arguments.

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 11, 2017

Contributor

⌛️ Testing commit e18c59f with merge 9aacb72...

Contributor

bors commented Apr 11, 2017

⌛️ Testing commit e18c59f with merge 9aacb72...

bors added a commit that referenced this pull request Apr 11, 2017

Auto merge of #40377 - camlorn:optimization_fuel, r=eddyb
Implement optimization fuel and re-enable struct field reordering

See [this discussion](https://internals.rust-lang.org/t/rolling-out-or-unrolling-struct-field-reorderings/4485) for background.

This pull request adds two new compilation options: `-Z print-fuel=crate` prints the optimization fuel used by a crate and `-Z fuel=crate=n` sets the optimization fuel for a crate.

It also turns field reordering back on.  There is no way to test this feature without something consuming fuel.  We can roll this back if we want, but then the optimization fuel bits will be dead code.

The one notable absence from this PR is a test case.  I'm not sure how to do one that's worth having.  The only thing I can think of to test is `-Z fuel=foo=0`.  The problem with other tests is that either (1) they're so big that future optimizations will apply, thus breaking them or (2) we don't know which order the optimizations will be applied in, so we can't guess the message that will be printed.  If someone has a useful proposal for a good test, I certainly want to add one.
@frewsxcv

This comment has been minimized.

Show comment
Hide comment
@frewsxcv

frewsxcv Apr 11, 2017

Member

@bors retry

prioritizing #41231 since everything in the queue will fail without it

Member

frewsxcv commented Apr 11, 2017

@bors retry

prioritizing #41231 since everything in the queue will fail without it

frewsxcv added a commit to frewsxcv/rust that referenced this pull request Apr 11, 2017

Rollup merge of #40377 - camlorn:optimization_fuel, r=eddyb
Implement optimization fuel and re-enable struct field reordering

See [this discussion](https://internals.rust-lang.org/t/rolling-out-or-unrolling-struct-field-reorderings/4485) for background.

This pull request adds two new compilation options: `-Z print-fuel=crate` prints the optimization fuel used by a crate and `-Z fuel=crate=n` sets the optimization fuel for a crate.

It also turns field reordering back on.  There is no way to test this feature without something consuming fuel.  We can roll this back if we want, but then the optimization fuel bits will be dead code.

The one notable absence from this PR is a test case.  I'm not sure how to do one that's worth having.  The only thing I can think of to test is `-Z fuel=foo=0`.  The problem with other tests is that either (1) they're so big that future optimizations will apply, thus breaking them or (2) we don't know which order the optimizations will be applied in, so we can't guess the message that will be printed.  If someone has a useful proposal for a good test, I certainly want to add one.

bors added a commit that referenced this pull request Apr 12, 2017

Auto merge of #41237 - frewsxcv:rollup, r=frewsxcv
Rollup of 8 pull requests

- Successful merges: #40377, #40559, #41173, #41202, #41204, #41209, #41216, #41231
- Failed merges:
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 12, 2017

Contributor

⌛️ Testing commit e18c59f with merge da32752...

Contributor

bors commented Apr 12, 2017

⌛️ Testing commit e18c59f with merge da32752...

@bors bors merged commit e18c59f into rust-lang:master Apr 12, 2017

1 of 2 checks passed

homu Testing commit e18c59f with merge da32752...
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@phil-opp phil-opp referenced this pull request Apr 12, 2017

Closed

repr(C) is necessary #28

SimonSapin added a commit to servo/servo that referenced this pull request Apr 15, 2017

Upgrade to rustc 1.18.0-nightly (5f13a3b54 2017-04-15)
This version enables [struct field reordering][1] which brings the size
of the types for specified values of some CSS properties under the threshold
such that they shouldn’t be boxed anymore, making test unit fail.

Simly unboxing them moves the test failure to Stylo’s unit test,
since the stable compiler used in that case does not do field re-ordering.
Therefore, we manually reorder a couple fields to effectively bring this
optimization to older compilers for a few specific types.

[1]: rust-lang/rust#40377

SimonSapin added a commit to servo/servo that referenced this pull request Apr 15, 2017

Upgrade to rustc 1.18.0-nightly (5f13a3b54 2017-04-15)
This version enables [struct field reordering][1] which brings the size
of the types for specified values of some CSS properties under the threshold
such that they shouldn’t be boxed anymore, making test unit fail.

Simply unboxing them moves the test failure to Stylo’s unit test,
since the stable compiler used in that case does not do field re-ordering.
Therefore, we manually reorder a couple fields to effectively bring this
optimization to older compilers for a few specific types.

[1]: rust-lang/rust#40377

SimonSapin added a commit to servo/servo that referenced this pull request Apr 15, 2017

Upgrade to rustc 1.18.0-nightly (5f13a3b54 2017-04-15)
This version enables [struct field reordering][1] which brings the size
of the types for specified values of some CSS properties under the threshold
such that they shouldn’t be boxed anymore, making test unit fail.

Simply unboxing them moves the test failure to Stylo’s unit tests,
since the stable compiler used in that case does not do field re-ordering.
Therefore, we manually reorder a couple fields to effectively bring this
optimization to older compilers for a few specific types.

[1]: rust-lang/rust#40377

SimonSapin added a commit to servo/servo that referenced this pull request Apr 15, 2017

Upgrade to rustc 1.18.0-nightly (5f13a3b54 2017-04-15)
This version enables [struct field reordering][1] which brings the size
of the types for specified values of some CSS properties under the threshold
such that they shouldn’t be boxed anymore, making test unit fail.

Simply unboxing them moves the test failure to Stylo’s unit tests,
since the stable compiler used in that case does not do field re-ordering.
Therefore, we manually reorder a couple fields to effectively bring this
optimization to older compilers for a few specific types.

[1]: rust-lang/rust#40377

SimonSapin added a commit to servo/servo that referenced this pull request Apr 15, 2017

Upgrade to rustc 1.18.0-nightly (5f13a3b54 2017-04-15)
This version enables [struct field reordering][1] which brings the size
of the types for specified values of some CSS properties under the threshold
such that they shouldn’t be boxed anymore, making unit tests fail.

Simply unboxing them moves the test failure to Stylo’s unit tests,
since the stable compiler used in that case does not do field re-ordering.
Therefore, we manually reorder a couple fields to effectively bring this
optimization to older compilers for a few specific types.

[1]: rust-lang/rust#40377

bors-servo added a commit to servo/servo that referenced this pull request Apr 16, 2017

Auto merge of #16473 - servo:rustup, r=emilio
Upgrade to rustc 1.18.0-nightly (5f13a3b54 2017-04-15)

This version enables [struct field reordering][1] which brings the size of the types for specified values of some CSS properties under the threshold such that they shouldn’t be boxed anymore, making unit tests fail.

Simply unboxing them moves the test failure to Stylo’s unit tests, since the stable compiler used in that case does not do field re-ordering. Therefore, we manually reorder a couple fields to effectively bring this optimization to older compilers for a few specific types.

[1]: rust-lang/rust#40377

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/16473)
<!-- Reviewable:end -->

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Apr 16, 2017

servo: Merge #16473 - Upgrade to rustc 1.18.0-nightly (5f13a3b54 2017…
…-04-15) (from servo:rustup); r=emilio

This version enables [struct field reordering][1] which brings the size of the types for specified values of some CSS properties under the threshold such that they shouldn’t be boxed anymore, making unit tests fail.

Simply unboxing them moves the test failure to Stylo’s unit tests, since the stable compiler used in that case does not do field re-ordering. Therefore, we manually reorder a couple fields to effectively bring this optimization to older compilers for a few specific types.

[1]: rust-lang/rust#40377

Source-Repo: https://github.com/servo/servo
Source-Revision: c453e2ef89b32798dabbb23b22cfd5a72dddf6a5

--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 89b15d84b3f4b106d58ca90b3fd18f552d1a6633

xeonchen pushed a commit to mozilla-necko/gecko that referenced this pull request Apr 16, 2017

servo: Merge #16473 - Upgrade to rustc 1.18.0-nightly (5f13a3b54 2017…
…-04-15) (from servo:rustup); r=emilio

This version enables [struct field reordering][1] which brings the size of the types for specified values of some CSS properties under the threshold such that they shouldn’t be boxed anymore, making unit tests fail.

Simply unboxing them moves the test failure to Stylo’s unit tests, since the stable compiler used in that case does not do field re-ordering. Therefore, we manually reorder a couple fields to effectively bring this optimization to older compilers for a few specific types.

[1]: rust-lang/rust#40377

Source-Repo: https://github.com/servo/servo
Source-Revision: c453e2ef89b32798dabbb23b22cfd5a72dddf6a5

Manishearth pushed a commit to Manishearth/gecko-dev that referenced this pull request Apr 21, 2017

servo: Merge #16473 - Upgrade to rustc 1.18.0-nightly (5f13a3b54 2017…
…-04-15) (from servo:rustup); r=emilio

This version enables [struct field reordering][1] which brings the size of the types for specified values of some CSS properties under the threshold such that they shouldn’t be boxed anymore, making unit tests fail.

Simply unboxing them moves the test failure to Stylo’s unit tests, since the stable compiler used in that case does not do field re-ordering. Therefore, we manually reorder a couple fields to effectively bring this optimization to older compilers for a few specific types.

[1]: rust-lang/rust#40377

Source-Repo: https://github.com/servo/servo
Source-Revision: c453e2ef89b32798dabbb23b22cfd5a72dddf6a5

@Florob Florob referenced this pull request Jun 7, 2017

Closed

Rust 2nd Anniversary - Part II #31

8 of 11 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment