Stream: t-compiler

Topic: Return `false` for `needs_drop::<[Box; 0]>`?


ecstatic-morse (Oct 12 2019 at 22:01, on Zulip):

#65348 is a backwards compatibility hazard in the new, dataflow-based const validator. An elegant fix for this problem (and for #64945 as well) would be to return false for the needs_drop query for all zero-sized arrays, regardless of the type contained within. Is this reasonable? I could duplicate needs_drop in qualify_consts.rs and make the modification there, but changing the result of the query proper might have ancillary benefits.

ecstatic-morse (Oct 13 2019 at 19:38, on Zulip):

See #65389. This caused 5 codegen test failures locally due to missed optimizations when iterating over slices. I have no idea why though. The generated MIR was the same for the two that I checked, so the problem must occur when generating LLVM IR?

ecstatic-morse (Oct 13 2019 at 23:03, on Zulip):

I rebased on the latest master (I was on a pretty old one) and rebuilt LLVM. The problem seems to have gone away, and my PR passes CI. No idea what the root cause was.

gnzlbg (Oct 14 2019 at 08:28, on Zulip):

return false for the needs_drop query for all zero-sized arrays, regardless of the type contained within. Is this reasonable?

Why wouldn't it be? An empty array has no fields, so why would those types need drop glue ?

gnzlbg (Oct 14 2019 at 08:29, on Zulip):

In a sense, an empty array is like a struct Foo<T>; where the generic parameter is not used for anything.

gnzlbg (Oct 14 2019 at 08:29, on Zulip):

That's different from struct Bar<T>(PhantomData<T>) where PhantomData<T> tells the compiler that Bar owns a T

Last update: Nov 22 2019 at 04:55UTC