Distinguish `Place` and `PlaceWithHirId`

[nikomatsakis]

As part of refactoring to the new HIR place, we want to introduce a PlaceWithHirId that separates out the hir_id field from the rest of Place.

We can do this by:

• rename the existing struct to PlaceWithHirId, get that to build
• refactor to extract a few fields out of PlaceWithHirId into a new struct, Place, get that to build
• Split projections into another structure, adding type information will be done as part of Store Type Information within projections #5

[arora-aman]

Outside of typechk Places are only used within clippy, so far:

tools/clippy/clippy_lints/src/escape.rs
tools/clippy/clippy_lints/src/loops.rs
tools/clippy/clippy_lints/src/utils/usage.rs

Search details: sexxi-goose/rust#14 (comment)

[nikomatsakis]

That might be true, not sure. The compiler I think is mostly interested in finding the root variable at the moment, as those HIR places are (afaik) only used for the closure upvar analysis (within the compiler itself).

[arora-aman]

That might be true, not sure. The compiler I think is mostly interested in finding the root variable at the moment, as those HIR places are (afaik) only used for the closure upvar analysis (within the compiler itself).

Sorry that was meant to be outside of typechk, the module it is defined in.

[arora-aman]

The markdown suggests using PlaceReference this might lead to someone confusing it for PlaceRef.

My suggestion is PlaceUnique, PlaceSpecific. These aren't great so might need to come up with something better 😂

[nikomatsakis]

Ah, so that is what you meant by PlaceUnique on Zulip. =)

I think I like Place and PlaceWithHirId best. Or perhaps PlaceAccess?

[nikomatsakis]

I found the "unique" terminology pretty confusing, and somehow assumed it was related to unique/mutable borrows or something else like that.

[arora-aman]

That is fair. PlaceWithHirId is quite descriptive, I like that. I just remember you suggesting coming up with something better on Zulip, that's why I suggested something else.