More clone shim cleanups

[Manishearth]

r? @nikomatsakis

cc @eddyb

[Manishearth]

Bear in mind, I've done these patches at the instruction of @eddyb and don't yet 100% understand what's going on with the substs here. Please direct complex questions to him :)

[eddyb]

I'm just betting/hoping that everything lines up correctly 😅.

[nikomatsakis]

I left some comments. But in general I am confused about the "overall direction" of these changes -- they seem to be eliding type information when generating the clone impl, but don't we need that type information to know how big thing are and so forth? What am I missing?

[nikomatsakis]

I..don't understand this. How can we have just one shim for all monomorphizations? Don't their sizes depend on the specific types in use?

[nikomatsakis]

And what does this DefId refer to anyhow?

[eddyb]

Shims are not per-monomorphization, they're pretty generic (look at some of the other ones). CloneShim (and now the CloneStructuralShim) was incorrectly too monomorphic (but the array/tuple cases are harder to fix).

What's happening now is that there's only one MIR body forreturn *self; and one per closure definition, which you monomorphize just like you'd monomorphize a generic closure definition.

[Manishearth]

"One shim for all monomorphizations" is the reason behind this PR. As for how it works, ask @eddyb

[nikomatsakis]

Wait, pre-existing but... how .. does this work? name = tcx.type_of(def_id); if name == "clone"?? Isn't name a Ty<'tcx>?

[nikomatsakis]

I guess that the travis failure answers that question (i.e., it doesn't work).

[Manishearth]

lol I broke this in a rebase by accident. It used to be item_name

[nikomatsakis]

Why is this not CloneClosureShim?

[nikomatsakis]

And (in all cases) can you comment what the DefId refers to? (If you're feeling heroic, do the same for the other variants)

[Manishearth]

It used to be CloneClosureShim and eddyb had me change it to use a more generic name 😄

[eddyb]

It's literally Clone::clone - all of the variants (have to) record the original DefId that was passed to Instance::resolveor something more specific (mostly for InstanceDef::Item.

[nikomatsakis]

comment about what ty is the def-id of...

[eddyb]

The nominal type definition (closure, ADT, etc. - @Manishearth has a branch where enums also want this). Could use a better field name.

[Manishearth]

Fails on run-pass/clone-closure.rs

@eddyb any idea what's going on?

[01:06:53] error: internal compiler error: librustc/ty/layout.rs:2184: TyLayout::field_type(TyLayout { ty: i16, details: LayoutDetails { variants: Single { index: 0 }, fields: Union(0), abi: Scalar(Scalar { value: Int(I16, true), valid_range: 0..=65535 }), align: Align { abi: 1, pref: 1 }, size: Size { raw: 2 } } }): not applicable

[eddyb]

@Manishearth You need a backtrace, I have no idea.

[Manishearth]

error: internal compiler error: librustc/ty/layout.rs:2184: TyLayout::field_type(TyLayout { ty: i16, details: LayoutDetails { variants: Single { index: 0 }, fields: Union(0), abi: Scalar(Scalar { value: Int(I16, true), valid_range: 0..=65535 }), align: Align { abi: 1, pref: 1 }, size: Size { raw: 2 } } }): not applicable
thread 'rustc' panicked at 'Box<Any>', librustc_errors/lib.rs:535:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.25.0-dev running on x86_64-apple-darwin
[08:30:53] मanishearth@ligo ~/mozilla/sand O_o
$ RUST_BACKTRACE=1 rustc +x1 test.rs
error: internal compiler error: librustc/ty/layout.rs:2184: TyLayout::field_type(TyLayout { ty: i16, details: LayoutDetails { variants: Single { index: 0 }, fields: Union(0), abi: Scalar(Scalar { value: Int(I16, true), valid_range: 0..=65535 }), align: Align { abi: 1, pref: 1 }, size: Size { raw: 2 } } }): not applicable
thread 'rustc' panicked at 'Box<Any>', librustc_errors/lib.rs:535:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
1: std::sys_common::backtrace::print
2: std::panicking::default_hook::{{closure}}
3: std::panicking::default_hook
4: std::panicking::rust_panic_with_hook
5: std::panicking::begin_panic
6: rustc_errors::Handler::bug
7: <std::thread::local::LocalKey<T>>::with
8: rustc::ty::context::tls::with_opt
9: rustc::session::opt_span_bug_fmt
10: rustc::session::bug_fmt
11: rustc::ty::layout::TyLayout::field
12: rustc_trans::mir::place::PlaceRef::project_field
13: rustc_trans::mir::place::<impl rustc_trans::mir::FunctionCx<'a, 'tcx>>::trans_place
14: rustc_trans::mir::rvalue::<impl rustc_trans::mir::FunctionCx<'a, 'tcx>>::trans_rvalue_operand
15: rustc_trans::mir::trans_mir
16: rustc_trans::base::trans_instance
17: rustc_trans::trans_item::MonoItemExt::define
18: rustc_trans::base::compile_codegen_unit
19: rustc::ty::maps::<impl rustc::ty::maps::queries::compile_codegen_unit<'tcx>>::compute_result
20: rustc::dep_graph::graph::DepGraph::with_task_impl
21: rustc_errors::Handler::track_diagnostics
22: rustc::ty::maps::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::cycle_check
23: rustc::ty::maps::<impl rustc::ty::maps::queries::compile_codegen_unit<'tcx>>::force
24: rustc::ty::maps::<impl rustc::ty::maps::queries::compile_codegen_unit<'tcx>>::try_get
25: rustc::ty::maps::TyCtxtAt::compile_codegen_unit
26: rustc::ty::maps::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::compile_codegen_unit
27: rustc_trans::base::trans_crate
28: <rustc_trans::LlvmTransCrate as rustc_trans_utils::trans_crate::TransCrate>::trans_crate
29: rustc::util::common::time
30: rustc_driver::driver::phase_4_translate_to_llvm
31: rustc_driver::driver::compile_input::{{closure}}
32: <std::thread::local::LocalKey<T>>::with

[Manishearth]

If I make the closure not capture variables, I get

Function return type does not match operand type of return inst!
ret %"main::{{closure}}" undef
i8LLVM ERROR: Broken function found, compilation aborted!

[nikomatsakis]

I've kind of lost the thread here. What is the status? @Manishearth do you need guidance?

Waiting to figure out what is going on =)

[Manishearth]

I haven't had the time to investigate the crash, but if you have a guess as to where it's coming from I'd love to know.

[arazabishov]

@Manishearth friendly ping from (release team) triage :) What is the status of this PR?

[Manishearth]

Still haven't had the time.

[shepmaster]

It's PR triage time again, @Manishearth! How's it going?

[Manishearth]

Nope. Feel free to close if you wish, but if someone else wants to take it over that works too

(@eddyb ?)

[bors]

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

[emilyalbini]

Closing for inactivity. @Manishearth, if you find the time to work on this again feel free to reopen this PR!