Mitigate binary size impact of implicit caller location

[anp]

Once we've measured the size impact of implicit caller location, we need to decide what (if any) knobs to offer users to mitigate that impact.

The RFC originally proposed a -Zlocation-detail-control flag for rustc which would allow users to control which fields of Location were preserved.

On the tracking issue I also proposed an all-or-nothing flag like -Zredact-caller-location which would either preserve Locations or rewrite them all to be the same.

Note that both of these options are limited to controlling the locations reported by user code -- unless a user recompiles std with whatever flag we offer, there will always be "unredacted" locations in their binary.

I'm fond of ideas that would allow us to replace Locations with something smaller that can be "symbolized" similarly to the way a debugger for an embedded device can identify the source location for a program counter value in a stacktrace. I think most options in this direction require help from the linker that isn't available, but I'd love to be wrong.

[anp]

cc @eddyb @tmandry

[anp]

For reference, I think the place to branch would probably be in

rust/src/librustc_mir/interpret/intrinsics/caller_location.rs

Lines 54 to 81 in 1fb612b

	crate fn alloc_caller_location(
	&mut self,
	filename: Symbol,
	line: u32,
	col: u32,
	) -> MPlaceTy<'tcx, M::PointerTag> {
	let file = self.allocate_str(&filename.as_str(), MemoryKind::CallerLocation);
	let line = Scalar::from_u32(line);
	let col = Scalar::from_u32(col);
	// Allocate memory for `CallerLocation` struct.
	let loc_ty = self
	.tcx
	.type_of(self.tcx.require_lang_item(PanicLocationLangItem, None))
	.subst(*self.tcx, self.tcx.mk_substs([self.tcx.lifetimes.re_erased.into()].iter()));
	let loc_layout = self.layout_of(loc_ty).unwrap();
	let location = self.allocate(loc_layout, MemoryKind::CallerLocation);
	// Initialize fields.
	self.write_immediate(file.to_ref(), self.mplace_field(location, 0).unwrap().into())
	.expect("writing to memory we just allocated cannot fail");
	self.write_scalar(line, self.mplace_field(location, 1).unwrap().into())
	.expect("writing to memory we just allocated cannot fail");
	self.write_scalar(col, self.mplace_field(location, 2).unwrap().into())
	.expect("writing to memory we just allocated cannot fail");
	location
	}

where the actual values are allocated. I don't think we want to modify the ABI of track_caller functions since that will make things more complicated for dylibs but I could be wrong.

[anp]

Also worth noting that if we leave the ABI unaffected then a libstd without track_caller would only be needed for users who really need to squeeze the size, rather than a requirement for anyone compiling without the locations.

[hudson-ayers]

I am interested in taking on this issue. I took some basic measurements for an embedded binary here, and based on my findings I am interested in implementing -Zlocation-detail-control as described in the original RFC, since keeping filenames but not line/column numbers removes about 70% of the code size overhead while still providing the most useful piece of information for debugging.