Lint unused associated types by mu001999 · Pull Request #148654 · rust-lang/rust (original) (raw)

Am I right in stating that under your PR we're now visiting both HIR types and middle::ty types (at least in some cases)?

E.g., do we now visit $ty in const <span class="katex"><span class="katex-mathml"><math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>i</mi><mi>d</mi><mi>e</mi><mi>n</mi><mi>t</mi><mo>:</mo></mrow><annotation encoding="application/x-tex">ident: </annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.6944em;"></span><span class="mord mathnormal">i</span><span class="mord mathnormal">d</span><span class="mord mathnormal">e</span><span class="mord mathnormal">n</span><span class="mord mathnormal">t</span><span class="mspace" style="margin-right:0.2778em;"></span><span class="mrel">:</span></span></span></span>ty = <span class="katex"><span class="katex-mathml"><math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo separator="true">;</mo><msub><mi mathvariant="normal">‘</mi><mi>t</mi></msub><mi>w</mi><mi>i</mi><mi>c</mi><msub><mi>e</mi><mi>i</mi></msub><mi>n</mi><mi>a</mi><mi>s</mi><mi>e</mi><mi>n</mi><mi>s</mi><mi>e</mi><mo stretchy="false">?</mo><mi>I</mi><mi mathvariant="normal">.</mi><mi>e</mi><mi mathvariant="normal">.</mi><mo separator="true">,</mo><mi>v</mi><mi>i</mi><mi>s</mi><mi>i</mi><mi>t</mi><mi>i</mi><mi>n</mi><mi>g</mi><mi>t</mi><mi>h</mi><mi>e</mi><mi>H</mi><mi>I</mi><mi>R</mi><mi>v</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mi>o</mi><mi>f</mi><mi mathvariant="normal">‘</mi></mrow><annotation encoding="application/x-tex">expr; twice in a sense? I.e., visiting the HIR version of </annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.8889em;vertical-align:-0.1944em;"></span><span class="mord mathnormal">e</span><span class="mord mathnormal">x</span><span class="mord mathnormal">p</span><span class="mord mathnormal" style="margin-right:0.02778em;">r</span><span class="mpunct">;</span><span class="mspace" style="margin-right:0.1667em;"></span><span class="mord"><span class="mord">‘</span><span class="msupsub"><span class="vlist-t vlist-t2"><span class="vlist-r"><span class="vlist" style="height:0.2806em;"><span style="top:-2.55em;margin-left:0em;margin-right:0.05em;"><span class="pstrut" style="height:2.7em;"></span><span class="sizing reset-size6 size3 mtight"><span class="mord mathnormal mtight">t</span></span></span></span><span class="vlist-s">​</span></span><span class="vlist-r"><span class="vlist" style="height:0.15em;"><span></span></span></span></span></span></span><span class="mord mathnormal" style="margin-right:0.02691em;">w</span><span class="mord mathnormal">i</span><span class="mord mathnormal">c</span><span class="mord"><span class="mord mathnormal">e</span><span class="msupsub"><span class="vlist-t vlist-t2"><span class="vlist-r"><span class="vlist" style="height:0.3117em;"><span style="top:-2.55em;margin-left:0em;margin-right:0.05em;"><span class="pstrut" style="height:2.7em;"></span><span class="sizing reset-size6 size3 mtight"><span class="mord mathnormal mtight">i</span></span></span></span><span class="vlist-s">​</span></span><span class="vlist-r"><span class="vlist" style="height:0.15em;"><span></span></span></span></span></span></span><span class="mord mathnormal">na</span><span class="mord mathnormal">se</span><span class="mord mathnormal">n</span><span class="mord mathnormal">se</span><span class="mclose">?</span><span class="mord mathnormal" style="margin-right:0.07847em;">I</span><span class="mord">.</span><span class="mord mathnormal">e</span><span class="mord">.</span><span class="mpunct">,</span><span class="mspace" style="margin-right:0.1667em;"></span><span class="mord mathnormal" style="margin-right:0.03588em;">v</span><span class="mord mathnormal">i</span><span class="mord mathnormal">s</span><span class="mord mathnormal">i</span><span class="mord mathnormal">t</span><span class="mord mathnormal">in</span><span class="mord mathnormal" style="margin-right:0.03588em;">g</span><span class="mord mathnormal">t</span><span class="mord mathnormal">h</span><span class="mord mathnormal" style="margin-right:0.08125em;">eH</span><span class="mord mathnormal" style="margin-right:0.07847em;">I</span><span class="mord mathnormal" style="margin-right:0.00773em;">R</span><span class="mord mathnormal" style="margin-right:0.03588em;">v</span><span class="mord mathnormal">ers</span><span class="mord mathnormal">i</span><span class="mord mathnormal">o</span><span class="mord mathnormal">n</span><span class="mord mathnormal">o</span><span class="mord mathnormal" style="margin-right:0.10764em;">f</span><span class="mord">‘</span></span></span></span>ty to look for non-assoc-ty defs (e.g., structs, modules, assoc consts) to mark live & visiting the middle::ty version of $ty to mark assoc tys and only assoc tys as live?

If so, "ideally" we'd cease visiting the HIR version of types whose middle::ty version we visit later. Of course that would mean duplicating a lot of code in dead_code (since we'd now need to support marking both the HIR and middle::ty version of e.g., structs, modules, assoc consts as live). However, this "ideal" approach won't actually work because it would fail to detect live modules (path segments are no more in middle::ty) and type aliases (they currently aren't represented in middle::ty, stabilizing lazy_type_alias minus its wfchecking would fix that if at all backward compatible).

Now, Boxy and I have 1:1 chatted a lot about IATs & dead_code in the past and my personal favorite solution of dealing with associated types (or rather TypeRelative paths in general) in non-bodies has always been and still is "let's somehow persist the resolution of TypeRelative paths in non-bodies that comes from HIR ty lowering in some sort of new query". It's unclear if that's easily realizable. However, that would allow us to continue visiting the HIR and the HIR only since you'd be able to obtain the DefId of a TypeRelative path by HirId without the need to visit the middle::ty IR.

For context, HIR ty lowering (hir_ty_lowering / dyn HirTyLowerer) is responsible for resolving TypeRelative paths. However, only in bodies (consts, fns) do we persist their resolution (i.e., a mapping from HirId to DefId) because FnCtxt (a HirTyLowerer) is able to write back various resolutions after typeck, cc TypeckResults & its type_dependent_defs. OTOH ItemCtxt (the other HirTyLowerer) used for lowering non-body things is transient meaning it's dropped immediately after lowering a type, etc. There's no place of storing the resolution anywhere ATM. I'm thinking of introducing a feedable query so we can feed these type_dependent_defs even in ItemCtxt.