rustc_trans: reorganize CrateContext and rename context types.

[eddyb]

Firstly, the {Shared,Local}CrateContext hasn't been meaningful for a while now, and this PR resolves it by moving all their fields to CrateContext and removing redundant accessor methods.

Secondly, this PR contains the following mass-renames:

• ccx: CrateContext -> cx: CodegenCx
• mircx: MirContext -> fx: FunctionCx
• bcx: Builder -> bx: Builder

r? @nikomatsakis

[petrochenkov]

Some notes:

fx: FunctionCx

Type checking has commonly used and very similarly named fcx: FnCtxt.

ccx -> cx, bcx -> bx

tcx and fcx are still three-letter. Inconsistency! :)

[eddyb]

So the divergence is intentional but I'm not sure yet about tx: Ty(pe)Cx to propose doing this everywhere already.

[nikomatsakis]

I'm not entirely sure how I feel about bx and fx and so forth, but I'm not really opposed. I guess if we're going for obscure, might as well be really obscure?

cc @rust-lang/compiler -- anybody else care to leave their 2 cents?

[eddyb]

My line of reasoning is that using one letter with a cx suffix everywhere isn't more useful than a shorter suffix, as long as it's an unambiguous convention (which I assume x could be?).
For the context types, I also think Context or Ctxt is the least relevant part of them.

Hence, fx: FunctionCx (although in Rust, FnCx could also work). Like I said, I'm not ready to propose tx: Ty(pe)Cx, but if nobody hates it, it's on the table.

[nikomatsakis]

@eddyb I think I agree with that reasoning.

[bors]

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

[bors]

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

[michaelwoerister]

I think that ccx, fcx, and bcx work better as memnonics. But I don't have a strong opinion on it.

[nikomatsakis]

It does seem like bcx, fcx, and so forth make it more obvious that there is a pattern. That is, fx and bx are not obviously related to one another -- they could just be independent fields whose names happen to end in x. Still, both are pretty opaque.

[nikomatsakis]

Having let this sit for a bit, I feel like I'm leaning mildly against the renaming of fcx and friends to fx. It just feels like a step backwards in clarity to me for not much gain.

[nikomatsakis]

@eddyb and I were chatting on IRC and discussing the full set of names. I feel like this change wants to take all of them into account. One thought we had was that the name "tcx", while it has a lot of history in it, isn't especially meaningful -- and as we move to more and more querification, it will become increasingly inappropriate (because it's the context for more than types). We were thinking that "query context" would be a better name, and that then one might write just qx and Qx for the type (not sure what the lifetime names would be? 'qx and 'gx?). That seems like a pretty unique combination of letters. In that setting, though, I feel like things like bx and fx are more obvious. (I suppose the alternative would be to use qcx, though.)

[nikomatsakis]

@michaelwoerister@pnkfelix@petrochenkov thoughts on previous comment?

[petrochenkov]

@nikomatsakis
No thoughts :)

[michaelwoerister]

I like qcx, I'm OK with qx.

[nikomatsakis]

OK. I think I'm tired of debating about this. @eddyb do what you feel is best =)

[bors]

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

[eddyb]

@bors r=nikomatsakis

[bors]

📌 Commit 4e40a0d has been approved by nikomatsakis

[bors]

⌛ Testing commit 4e40a0d with merge da569fa...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing da569fa to master...

[Zoxc]

not sure what the lifetime names would be? 'qx and 'gx?

Just for reference, I prefer using the same lifetime name for the global interner lifetime instead of it sometimes being 'gcx and sometimes 'tcx. So for a Qx type I'd want to use 'qx everywhere to refer to the global interner lifetime (I guess we could also consider that the query engine lifetime).

[nikomatsakis]

I prefer using the same lifetime name for the global interner lifetime instead of it sometimes being 'gcx and sometimes 'tcx

I also think I would prefer that, though I've not tried it. Or at least I think it would be clearer.