-Zdump-mir does not dump all the MIR: drop glue missing

[RalfJung]

There seems to be no way currently to dump at least some of the MIR that rustc generates itself, e.g. for drop.

In the following code

struct Bar(u16); // ZSTs are tested separately

static mut DROP_COUNT: usize = 0;

impl Drop for Bar {
    fn drop(&mut self) {
        assert_eq!(self.0 as usize, unsafe { DROP_COUNT }); // tests whether we are called at a valid address
        unsafe { DROP_COUNT += 1; }
    }
}

fn main() {
    let b = [Bar(0), Bar(1), Bar(2), Bar(3)];
    assert_eq!(unsafe { DROP_COUNT }, 0);
    drop(b);
    assert_eq!(unsafe { DROP_COUNT }, 4);

    // check empty case
    let b : [Bar; 0] = [];
    drop(b);
    assert_eq!(unsafe { DROP_COUNT }, 4);
}

I can clearly see miri execute an Offset binop (a binop which is only ever emitted by the auto-generated drop glue), but grepping the entire dump directory for Offset shows no hit.

[RalfJung]

From Zulip:

I'd guess we're not running any passes on shims and thus they don't get their mir dumped, either

So... instance_mir calls make_shim (transitively), which does run a few passes, but it runs them manually instead of via the regular run_passes scheme

[RalfJung]

I got started on this, wrote https://github.com/RalfJung/rust/commits/mir-shim-dump/. Now it tries to dump MIR for shims. The problem is, in

rust/src/librustc_mir/util/pretty.rs

Lines 196 to 198 in dae6c93

	let item_name = tcx.hir
	.def_path(source.def_id)
	.to_filename_friendly_no_crate();

we call def_path, which asserts that the DefId comes from the local crate, but for shims that is not always true (it could be core::ptr::drop_in_place).

@oli-obk @eddyb any suggestions?

[eddyb]

@RalfJung Use the method on tcx that works cross-crate.

[RalfJung]

@eddyb Thanks! Now it gets a bit further and panics at

rust/src/librustc_mir/util/pretty.rs

Lines 571 to 573 in dae6c93

	fn write_mir_sig(tcx: TyCtxt, src: MirSource, mir: &Mir, w: &mut dyn Write) -> io::Result<()> {
	let id = tcx.hir.as_local_node_id(src.def_id).unwrap();
	let body_owner_kind = tcx.hir.body_owner_kind(id);

because, well, this is not a local node.

I wonder if I should approach this differently -- special case the drop shim for printing?

[eddyb]

I'd say it's worth fixing these. Instead of checking the body owner kind, could it check tcx.describe_def? Only Def::Fn and Def::Method should have method arguments and Def::Static would make it print static.

[RalfJung]

Dumping MIR of another crate works now. However, MIR dumping expects to dump polymorphic MIR, meaning (a) all drop shims get the same filename, overwriting one another, and (b) in the dumped MIR, you cannot even see which type this is dropping.

I guess I have to adjust to_filename_friendly_no_crate at the least?

[eddyb]

@RalfJung What about appending instead of overwriting if the file is one that was created by the current MIR dumping? (i.e. by keeping a set of used file names)

[RalfJung]

That sounds like a real bad hack. :/ Not to mention that it'd require some global state.

[eddyb]

Oh the printing is a side-effect of building MIR? Oops, I forgot.
Well then, put a (type) hash in the file name (cc @michaelwoerister)

[RalfJung]

I hear @matthewjasper has a branch where dumping shims at least somewhat works. Could you point me to that branch?

(EDIT: It's https://github.com/matthewjasper/rust/tree/dump-mir-shims)

[RalfJung]

I rebased the branch to see if I can make some more progress, but what used to work doesn't work any more. I am now getting a panic in this line when dumping the MIR for DefId(0/1:11 ~ test[317d]::main[0]::{{constant}}[0]) (using the code from the OP).

Any idea why that DefId cannot be described?

[RalfJung]

Ah, turns out this DefId is an AnonConst, and describe does not like those. But why?

Cc @oli-obk