Begin splitting middle::ty

[arielb1]

That file got way too big for its own good. It could be split more - this is just a start.

r? @nikomatsakis

[arielb1]

Let the bikeshedding commence.

[bors]

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

[bors]

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

[nikomatsakis]

I basically like this. I'm not sure about moving all the impls to a single module, but it might be nice. I've been wanting to split ty.rs into a directory for some time, for sure.

@arielb1 this is just a reorganization, right? No behavioral changes?

[arielb1]

@nikomatsakis

Right. No behavioral or (intentional) performance changes.

[arielb1]

I didn't move all impls, just Lift, HasTypeFlags, RegionEscape and TypeFoldable.

[jroesch]

I'm not a huge fan of having a redundant prefix on the name, but I guess you are doing it to disambiguate with Ivar.

[arielb1]

It is an Ivar<Ty<'tcx>>, not inline because of variance being annoying.

[jroesch]

I like this as well 👍, but after 1214, MIR, and HIR this is going to be another "fun" rebase on my branch.

[nikomatsakis]

@arielb1

I didn't move all impls, just Lift, HasTypeFlags, RegionEscape and TypeFoldable.

So I guess the interesting question is where these impls should go in general. I've sometimes regretted the current style -- I tend to think the impls should probably go with the types (though it's natural when first defining the traits to stick them with the trait). This is particularly true since in the cross-crate case they must go with the types. Note that "impls go with the types" might be loosely defined -- e.g., all types defined in the ty module might put their impls under ty::impls, but things in traits might be under traits::impls, etc.

[nikomatsakis]

r+ from me, in any case. This looks like progress to me. I second the... joyful thoughts of rebases to come.

[arielb1]

@nikomatsakis

90% of the impls are for ty and rustc dependencies (std, syntax, etc.), and therefore would go in ty::structural_impls anyway. Should I create a similar traits::structural_impls for these?

[bors]

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

[nikomatsakis]

@arielb1 I think I would prefer that, yes. The Debug impls for traits are already stashed in util.rs, they could be combined together as well (basically, all the... de rigeur impls).

[nikomatsakis]

But then I see you already did it.

[nikomatsakis]

@bors r+

[bors]

📌 Commit 5a95acb has been approved by nikomatsakis

[bors]

⌛ Testing commit 5a95acb with merge b1c9616...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt

[munyari]

Are InfrigingField and InfrigingVariant not typos?