Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More clone shim cleanups #48063

Closed
wants to merge 4 commits into from

Conversation

Manishearth
Copy link
Member

@Manishearth
Copy link
Member Author

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
Copy link
Member

eddyb commented Feb 8, 2018

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

Copy link
Contributor

@nikomatsakis nikomatsakis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

let self_ty = substs.type_at(0);
let mut builder = CloneShimBuilder::new(tcx, def_id, self_ty);
builder.copy_shim();
builder.into_mir()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And what does this DefId refer to anyhow?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@@ -291,7 +300,16 @@ fn resolve_associated_item<'a, 'tcx>(
if let Some(_) = tcx.lang_items().clone_trait() {
let name = tcx.type_of(def_id);
let def = if name == "clone" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

///`<T as Clone>::clone` shim for arrays and tuples
CloneStructuralShim(DefId, Ty<'tcx>),
///`<T as Clone>::clone` shim for closures
CloneNominalShim(DefId, Ty<'tcx>),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this not CloneClosureShim?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@@ -47,7 +47,7 @@ pub enum InstanceDef<'tcx> {
///`<T as Clone>::clone` shim for arrays and tuples
CloneStructuralShim(DefId, Ty<'tcx>),
///`<T as Clone>::clone` shim for closures
CloneNominalShim(DefId, Ty<'tcx>),
CloneNominalShim { clone: DefId, ty: DefId },
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@arazabishov arazabishov added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Feb 8, 2018
@Manishearth
Copy link
Member Author

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
Copy link
Member

eddyb commented Feb 9, 2018

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

@Manishearth
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Contributor

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

@nikomatsakis nikomatsakis dismissed their stale review February 14, 2018 19:50

Waiting to figure out what is going on =)

@Manishearth
Copy link
Member Author

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
Copy link
Member

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

@Manishearth
Copy link
Member Author

Still haven't had the time.

@shepmaster
Copy link
Member

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

@Manishearth
Copy link
Member Author

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

(@eddyb ?)

@bors
Copy link
Contributor

bors commented Mar 8, 2018

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

@pietroalbini
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants