Breaking changes we want to make

[arielb1]

What kinds of currently-working semantics are we OK with breaking?

[arielb1]

Description

Dropping a value of type Box<ZST> twice, where ZST is a zero-sized type,

Reason for breakage

We may want to add debuginfo for all allocations.

Example that will become UB

fn main() {
    let mut b = Box::new(());
    drop(unsafe { Box::from_raw(&mut *b) });
    drop(unsafe { Box::from_raw(&mut *b) });
}

This is more of a library issue, but I am afraid people are already abusing it.

[Amanieu]

Description

1. The ordering of fields in a non-repr(C) struct may change.

2. We may want to exclude alignment padding from the size of a type (Separate size and stride for types rfcs#1397)

Reason for breakage

Better struct packing, lower cache usage.

Problems

1. This will break any code that makes assumptions about the layout of non-repr(C) types.

2. This will break code that overwrite a value by writing to mem::size_of::<T> bytes. As far as I know the only affected crate is atomic-rs, which needs to use mem::size_of_inner::<T> instead.

[strega-nil]

@Amanieu number 2 is unlikely to change, afaik. It would result in slower, more complicated code. However, it is possible.

[nikomatsakis]

I feel like collecting these in a single issue will quickly become annoying. I propose that we create a tag ("proposed-breaking-change") and then just create issues for each of them.

[RalfJung]

Closing for now. non-repr(C) field order has indeed changed; for the "tail padding" of a type see rust-lang/unsafe-code-guidelines#176 and rust-lang/unsafe-code-guidelines#306; and the Box change should probably have its own thread if someone wants to pursue this.