Make place projections concrete. #60441

vext01 · 2019-05-01T15:01:50Z

I'm not sure if we want this. I'm raising the PR for discussion

Whilst doing some work on our Rust fork, I noticed the following:

Once upon a time (commit 9bd35c0) there were two kinds of
projection: one for places, and one for constants. It therefore made
sense to share the Projection struct for both. Although the different
use-cases used different concrete types, sharing was made possible by
type-parameterisation of Projection.

Since then, however, the usage of projections in constants has
disappeared, meaning that (forgetting lifetimes for a moment) the
parameterised type is only every instantiated under one guise. So it may
as well be a concrete type. Right?

What do people think? This is entirely untested, although it does check.

If we don't want this, then we should at least update the incorrect comment against Projection.

Thanks

rust-highfive · 2019-05-01T15:01:54Z

r? @eddyb

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

src/librustc/mir/mod.rs

eddyb · 2019-05-01T16:17:56Z

I thought this was because the MIR borrowck needs to replace the indexing values with an "abstract value" (i.e. treating a[i] and a[j] as potentially-the-same).

cc @pnkfelix @matthewjasper @nikomatsakis

nikomatsakis · 2019-05-01T16:29:30Z

I think that capability wound up not being used

matthewjasper · 2019-05-01T17:58:49Z

There's

rust/src/librustc_mir/dataflow/move_paths/abs_domain.rs

Line 21 in 6cc24f2

pub type AbstractElem = ProjectionElem<AbstractOperand, AbstractType>;

and

rust/src/librustc/mir/mod.rs

Line 2007 in 6cc24f2

pub type ProjectionKind = ProjectionElem<(), ()>;

But both of those only use ProjectionElem.

This seems fine, but Projection will eventually be refactored away in the Place 2.0 work.

eddyb · 2019-05-01T18:10:25Z

src/librustc/mir/mod.rs

@@ -1937,16 +1937,13 @@ impl_stable_hash_for!(struct Static<'tcx> {
    kind
 });

-/// The `Projection` data structure defines things of the form `B.x`
-/// or `*B` or `B[index]`. Note that it is parameterized because it is
-/// shared between `Constant` and `Place`. See the aliases


Oh, wow, this comment has been wrong for most of MIR's existence, I think?
For reasons, Projection<...> isn't used by MIR borrowck, but ProjectionElem is (as AbstractElem).

I think that's why Projection remained parameterized as well, but I'm not sure.

vext01 · 2019-05-02T09:00:12Z

OK, so is there a concensus on this? If you'd like this to go in, then I'll run some tests and check for fallout.

Projection will eventually be refactored away in the Place 2.0 work.

Is there some reading material on this please. This is likely to influence what I'm doing in my fork ;)

vext01 · 2019-05-02T14:55:30Z

./x.py test --stage 1 src/test/{ui,compile-fail,run-pass} passes on my machine.

src/librustc/mir/mod.rs

bors · 2019-05-04T06:02:07Z

☔ The latest upstream changes (presumably #59897) made this pull request unmergeable. Please resolve the merge conflicts.

vext01 · 2019-05-04T10:56:14Z

Folks, before I go down the path of resolving those conflicts, do you want this change?

eddyb · 2019-05-04T14:31:00Z

Yes, sorry for not being clearer. This is an accidental leftover that everyone forgot about because of the ProjectionElem parametrization.

18: Implement more TIR lowerings. r=ltratt a=vext01 This is a whole load more TIR lowerings. The TIR graphs are starting to look more complete, although there's still a lot more to do. I only stopped here because the changes are getting large, and more edits can come in later PRs. There's one part of this code (which I will point out), which i'm likely to change. It involves a type-parameterised MIR struct, which I think ultimately we will make concrete in TIR. However, I want to see the outcome of this upstream PR first: rust-lang/rust#60441 There's a ykpack change to accompany this: ykjit/yk#3 Co-authored-by: Edd Barrett <vext01@gmail.com>

vext01 · 2019-05-07T19:02:41Z

synced. OK for me to squash?

vext01 · 2019-05-08T15:27:00Z

I think we should prefer the name Projection.

Oops, I missed this. Leave it with me.

vext01 · 2019-05-09T10:35:17Z

That last commit does the renaming. Quite a lot of churn.

OK to squash?

oli-obk · 2019-05-10T09:49:03Z

lgtm now, squashing would be good, yes

src/librustc/mir/mod.rs

bors · 2019-05-24T06:01:32Z

☔ The latest upstream changes (presumably #60984) made this pull request unmergeable. Please resolve the merge conflicts.

vext01 · 2019-05-24T09:32:52Z

If everyone is OK with a4ba4fa, I'll squash.

rust-highfive · 2019-05-24T09:38:53Z

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

travis_time:end:0ac0be40:start=1558690454608116148,finish=1558690540971523343,duration=86363407195
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
[00:01:09] 
######################################################################## 100.0%
[00:01:09] extracting /checkout/obj/build/cache/2019-04-11/cargo-beta-x86_64-unknown-linux-gnu.tar.gz
[00:01:09]     Updating crates.io index
[00:01:27] error: the lock file /checkout/Cargo.lock needs to be updated but --locked was passed to prevent this
[00:01:27] Build completed unsuccessfully in 0:00:31
[00:01:27] make: *** [prepare] Error 1
[00:01:27] Makefile:69: recipe for target 'prepare' failed
[00:01:28] Command failed. Attempt 2/5:
[00:01:28] Command failed. Attempt 2/5:
[00:01:29] error: the lock file /checkout/Cargo.lock needs to be updated but --locked was passed to prevent this
[00:01:29] Build completed unsuccessfully in 0:00:00
[00:01:29] make: *** [prepare] Error 1
[00:01:29] Makefile:69: recipe for target 'prepare' failed
[00:01:31] Command failed. Attempt 3/5:
[00:01:31] Command failed. Attempt 3/5:
[00:01:31] error: the lock file /checkout/Cargo.lock needs to be updated but --locked was passed to prevent this
[00:01:31] Build completed unsuccessfully in 0:00:00
[00:01:31] Makefile:69: recipe for target 'prepare' failed
[00:01:31] make: *** [prepare] Error 1
[00:01:34] Command failed. Attempt 4/5:
[00:01:34] Command failed. Attempt 4/5:
[00:01:35] error: the lock file /checkout/Cargo.lock needs to be updated but --locked was passed to prevent this
[00:01:35] Build completed unsuccessfully in 0:00:00
[00:01:35] make: *** [prepare] Error 1
[00:01:35] Makefile:69: recipe for target 'prepare' failed
[00:01:39] Command failed. Attempt 5/5:
[00:01:39] Command failed. Attempt 5/5:
[00:01:39] error: the lock file /checkout/Cargo.lock needs to be updated but --locked was passed to prevent this
[00:01:39] Build completed unsuccessfully in 0:00:00
[00:01:39] Makefile:69: recipe for target 'prepare' failed
[00:01:39] make: *** [prepare] Error 1
[00:01:39] The command has failed after 5 attempts.
---
travis_time:end:019a811a:start=1558690650708242223,finish=1558690650714068415,duration=5826192
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:04cf2ea0
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:08ab9816
travis_time:start:08ab9816
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:1e673699
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

vext01 · 2019-05-24T09:41:37Z

Sorry, I screwed up the last commit.

oli-obk · 2019-05-24T12:54:03Z

@vext01 yes, this is looking good now. So a rebase + squash is all that is necessary to get it merged

r? @oli-obk

Once upon a time (commit 9bd35c0) there were two kinds of projection: one for places, and one for constants. It therefore made sense to share the `Projection` struct for both. Although the different use-cases used different concrete types, sharing was made possible by type-parameterisation of `Projection`. Since then, however, the usage of projections in constants has disappeared, meaning that (forgetting lifetimes for a moment) the parameterised type is only every instantiated under one guise. So it may as well be a concrete type.

vext01 · 2019-05-24T13:24:32Z

Squashed.

oli-obk · 2019-05-24T14:04:01Z

@bors r+

bors · 2019-05-24T14:04:02Z

📌 Commit 123a456 has been approved by oli-obk

bors · 2019-05-25T01:20:16Z

⌛ Testing commit 123a456 with merge 5245803...

Make place projections concrete. **I'm not sure if we want this. I'm raising the PR for discussion** Whilst doing some work on our Rust fork, I noticed the following: Once upon a time (commit 9bd35c0) there were two kinds of projection: one for places, and one for constants. It therefore made sense to share the `Projection` struct for both. Although the different use-cases used different concrete types, sharing was made possible by type-parameterisation of `Projection`. Since then, however, the usage of projections in constants has disappeared, meaning that (forgetting lifetimes for a moment) the parameterised type is only every instantiated under one guise. So it may as well be a concrete type. Right? What do people think? This is entirely untested, although it does check. If we *don't* want this, then we should at least update the incorrect comment against `Projection`. Thanks

bors · 2019-05-25T04:10:01Z

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

rust-highfive assigned eddyb May 1, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 1, 2019

vext01 commented May 1, 2019

View reviewed changes

src/librustc/mir/mod.rs Outdated Show resolved Hide resolved

vext01 mentioned this pull request May 1, 2019

Implement more TIR lowerings. softdevteam/ykrustc#18

Merged

eddyb reviewed May 1, 2019

View reviewed changes

vext01 marked this pull request as ready for review May 3, 2019 09:10

eddyb reviewed May 4, 2019

View reviewed changes

src/librustc/mir/mod.rs Outdated Show resolved Hide resolved

eddyb reviewed May 13, 2019

View reviewed changes

src/librustc/mir/mod.rs Outdated Show resolved Hide resolved

eddyb approved these changes May 13, 2019

View reviewed changes

rust-highfive unassigned eddyb May 24, 2019

rust-highfive assigned oli-obk May 24, 2019

vext01 force-pushed the try-to-kill-projection-params branch from 1bbff00 to 123a456 Compare May 24, 2019 13:17

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 May 24, 2019

bors added the merged-by-bors This PR was explicitly merged by bors. label May 25, 2019

bors merged commit 123a456 into rust-lang:master May 25, 2019

This was referenced May 25, 2019

Changes the type mir::Mir into mir::Body #60928

Merged

Fact generation for liveness calculations in Polonius #60266

Merged

Move path for iterate #61102

Merged

Rollup of 5 pull requests #61153

Closed

pnkfelix mentioned this pull request Jun 14, 2019

ICE from const item in lifetime-parametric impl #56445

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make place projections concrete. #60441

Make place projections concrete. #60441

vext01 commented May 1, 2019

rust-highfive commented May 1, 2019

eddyb commented May 1, 2019

nikomatsakis commented May 1, 2019

matthewjasper commented May 1, 2019

eddyb May 1, 2019

vext01 commented May 2, 2019

vext01 commented May 2, 2019

bors commented May 4, 2019

vext01 commented May 4, 2019

eddyb commented May 4, 2019

vext01 commented May 7, 2019

vext01 commented May 8, 2019

vext01 commented May 9, 2019

oli-obk commented May 10, 2019

bors commented May 24, 2019

vext01 commented May 24, 2019

rust-highfive commented May 24, 2019

vext01 commented May 24, 2019

oli-obk commented May 24, 2019

vext01 commented May 24, 2019

oli-obk commented May 24, 2019

bors commented May 24, 2019

bors commented May 25, 2019

bors commented May 25, 2019

Make place projections concrete. #60441

Make place projections concrete. #60441

Conversation

vext01 commented May 1, 2019

rust-highfive commented May 1, 2019

eddyb commented May 1, 2019

nikomatsakis commented May 1, 2019

matthewjasper commented May 1, 2019

eddyb May 1, 2019

Choose a reason for hiding this comment

vext01 commented May 2, 2019

vext01 commented May 2, 2019

bors commented May 4, 2019

vext01 commented May 4, 2019

eddyb commented May 4, 2019

vext01 commented May 7, 2019

vext01 commented May 8, 2019

vext01 commented May 9, 2019

oli-obk commented May 10, 2019

bors commented May 24, 2019

vext01 commented May 24, 2019

rust-highfive commented May 24, 2019

vext01 commented May 24, 2019

oli-obk commented May 24, 2019

vext01 commented May 24, 2019

oli-obk commented May 24, 2019

bors commented May 24, 2019

bors commented May 25, 2019

bors commented May 25, 2019