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

do not normalize all non-scalar constants to a ConstValue::ScalarPair #54693

Merged
merged 2 commits into from
Oct 2, 2018

Conversation

RalfJung
Copy link
Member

We still need ConstValue::ScalarPair for match handling (matching slices and strings), but that will never see anything Undef. For non-fat-ptr ScalarPair, just point to the allocation like larger data structures do.

Fixes #54387

r? @eddyb

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 30, 2018
@RalfJung
Copy link
Member Author

RalfJung commented Oct 1, 2018

Cc @oli-obk

@oli-obk oli-obk added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Oct 1, 2018
@oli-obk
Copy link
Contributor

oli-obk commented Oct 1, 2018

@bors r+

@bors
Copy link
Contributor

bors commented Oct 1, 2018

📌 Commit d62aa3e has been approved by oli-obk

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 1, 2018
@oli-obk oli-obk assigned oli-obk and unassigned eddyb Oct 1, 2018
@RalfJung
Copy link
Member Author

RalfJung commented Oct 1, 2018

A less risky variant for beta might be to just backport the changes in const_eval to normalize fewer things, but not get rid of the ScalarMaybeUndef in ConstValue entirely.

@bors
Copy link
Contributor

bors commented Oct 1, 2018

⌛ Testing commit d62aa3e with merge 7cbcdae...

bors added a commit that referenced this pull request Oct 1, 2018
do not normalize all non-scalar constants to a ConstValue::ScalarPair

We still need `ConstValue::ScalarPair` for match handling (matching slices and strings), but that will never see anything `Undef`. For non-fat-ptr `ScalarPair`, just point to the allocation like larger data structures do.

Fixes #54387

r? @eddyb
@bors
Copy link
Contributor

bors commented Oct 2, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: oli-obk
Pushing 7cbcdae to master...

@bors bors merged commit d62aa3e into rust-lang:master Oct 2, 2018
@rust-highfive
Copy link
Collaborator

📣 Toolstate changed by #54693!

Tested on commit 7cbcdae.
Direct link to PR: #54693

💔 clippy-driver on windows: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).
💔 clippy-driver on linux: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).
💔 miri on windows: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).
💔 miri on linux: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).
💔 rls on windows: test-pass → build-fail (cc @nrc, @rust-lang/infra).
💔 rls on linux: test-pass → build-fail (cc @nrc, @rust-lang/infra).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Oct 2, 2018
Tested on commit rust-lang/rust@7cbcdae.
Direct link to PR: <rust-lang/rust#54693>

💔 clippy-driver on windows: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).
💔 clippy-driver on linux: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).
💔 miri on windows: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).
💔 miri on linux: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).
💔 rls on windows: test-pass → build-fail (cc @nrc, @rust-lang/infra).
💔 rls on linux: test-pass → build-fail (cc @nrc, @rust-lang/infra).
@eddyb
Copy link
Member

eddyb commented Oct 2, 2018

So the argument here is that anything that doesn't need an allocation should be fully initialized?
(I expected ScalarMaybeUndef to be used more, but I see why you'd want the opposite)

@RalfJung RalfJung deleted the ctfe-scalar-pair-undef branch October 2, 2018 06:27
@RalfJung
Copy link
Member Author

RalfJung commented Oct 2, 2018

So the argument here is that anything that doesn't need an allocation should be fully initialized?

Yes. We have those variants only because pattern matching and some code around array lengths need them. No reason they should have to handle Undef.

Everything gets an allocation anyway from the way const_eval works, it's just for some types we decide to get stuff out of the allocation earlier. It's a bit messy, and I'd prefer if these were different types and we had one query that always returns an allocation and another than always returns an immediate (and is only used in a few places).

@RalfJung
Copy link
Member Author

RalfJung commented Oct 2, 2018

Also see #54738

@RalfJung RalfJung mentioned this pull request Oct 2, 2018
@pietroalbini pietroalbini added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Oct 2, 2018
@RalfJung
Copy link
Member Author

RalfJung commented Oct 2, 2018

I made a beta backport at #54759

@RalfJung
Copy link
Member Author

RalfJung commented Oct 2, 2018

Oh dang. Now I see @oli-obk already did that. oops^^

@pnkfelix pnkfelix removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Oct 4, 2018
@pnkfelix
Copy link
Member

pnkfelix commented Oct 4, 2018

T-compiler accepted #54759 for the backport.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants