Borrow checker allows "place mention"-dereferencing an uninitialized reference

@Amanieu

@Amanieu found this fun example:

fn main() {
    let x: &'static String;
    let _ = *x;
}

The borrow checker accepts this code. Miri says it has UB. Who is right?^^

The UB arises because let _ = place compiles to a "place mention", and PlaceMention(*x) still tries to construct the place *x which is ill-defined as x is uninitialized. (If you remove the *, it's fine because the place x exists and can be computed, it just denotes memory that hasn't been initialized yet. But *x describes a place that has no meaning.)

Cc @Nadrieril @rust-lang/types

Another variant (UB in miri):

enum Thing {
    Wut
}

fn main() {
    let x: &Thing;
    let Thing::Wut = *x else { panic!() };
}

This, however, is apparently not UB according to miri.

enum Thing {
    Wut
}

fn main() {
    let x: &Thing;
    let &Thing::Wut = x else { panic!() };
}

miri, why do you think this is ok???

#[repr(u8)]
enum Thing {
    Wut,
}

fn main() {
    let x: &mut &mut Thing;
    let Thing::Wut = x else { panic!() };
}

@theemathas

@theemathas I think that is a different bug. All your examples bisect to this:

Regression in nightly-2023-10-28

  commit[0] 2023-10-26: Auto merge of #116581 - Kobzol:bootstrap-cmd-run, r=onur-ozkan
  commit[1] 2023-10-26: Auto merge of #117249 - matthiaskrgr:rollup-h4og5rv, r=matthiaskrgr
  commit[2] 2023-10-27: Auto merge of #113183 - estebank:redundant-sized-errors, r=davidtwco
  commit[3] 2023-10-27: Auto merge of #116035 - lqd:mcp-510-target-specs, r=petrochenkov
  commit[4] 2023-10-27: Auto merge of #117260 - okaneco:ascii_branchless, r=thomcc
  commit[5] 2023-10-27: Auto merge of #116205 - WaffleLapkin:stabilize_pointer_byte_offsets, r=dtolnay
  commit[6] 2023-10-27: Auto merge of #117272 - matthiaskrgr:rollup-upg122z, r=matthiaskrgr
  commit[7] 2023-10-27: Auto merge of #116858 - estebank:issue-22488, r=petrochenkov
  commit[8] 2023-10-27: Auto merge of #116751 - Nadrieril:lint-overlap-per-column, r=davidtwco
  commit[9] 2023-10-27: Auto merge of #117166 - oli-obk:mir_const_qualif_perf, r=petrochenkov
  commit[10] 2023-10-27: Auto merge of #103208 - cjgillot:match-fake-read, r=oli-obk,RalfJung
  commit[11] 2023-10-27: Auto merge of #117294 - matthiaskrgr:rollup-xylsec7, r=matthiaskrgr

My guess is #103208, before that nightly your examples encounter a compile error:


error[E0381]: used binding `x` isn't initialized
 --> <source>:8:22
  |
7 |     let x: &mut &mut Thing;
  |         - binding declared here but left uninitialized
8 |     let Thing::Wut = x else { panic!() };
  |                      ^ `x` used here but it isn't initialized

The original example has always compiled.

This compiles since 1.0.0:

enum Thing {
    Wut,
}

fn main() {
    let x: &mut &mut Thing;
    let &mut &mut Thing::Wut = x;
}

Current miri thinks this is OK.

@Nadrieril

@Nadrieril I think we have a bug somewhere about such & patterns not being represented in MIR, don't we?

This also works for Boxes that have been dropped:

let x = Box::new(1);
drop(x);
_ = *x; // miri sad :c

I suspect we will find this in more existing code than the version that does it on an uninit local.

Do we have any other types with builtin dereference logic? Other than references, raw pointers, and Box?

@Nadrieril I think we have a bug somewhere about such & patterns not being represented in MIR, don't we?

Hmmm, unsure if that bit is a bug: the place being tested would have derefs in it so nothing is missing, it's just that the enum has a single variant so we don't emit any read/read_discriminant of that place. Would we want to make sure that "we could read the discriminant" maybe, by adding a PlaceMention of the place being not-tested?

The OP however is very much a borrow-checker bug imo, since *x reads a pointer fromn *x and there is none. Not unrelated to rust-lang/reference#2121.

I found an unsound miscompile based on this: #164738

I think we should just fix this by making all of these examples fail to compile outright.

it's just that the enum has a single variant so we don't emit any read/read_discriminant of that place.

I do feel like we had an issue for that, since IMO we totally should emit such a read -- in particular for repr(C) enums where there can be actual data that has to be valid even for single-variant enums...

I think it was this issue: #147722

With my types hat on I don't really have much of a mental model about the validity requirements of places. I would be more than happy for opsem to just figure that out and then someone can implement whatever makes sense.

My mental model here was that wildcard patterns just let you write whatever you want for the place expr being matched on. Given that we support let _ = *null, *uninit doesn't seem particularly different to me and would find it kind of subtle and surprising if there was a difference (though I think it would be fine language design wise to say there is a difference). let &Foo = *uninit working is surprising to me though 😅

Opsemwise places are memory locations, so place evaluation should produce something that has a known address. Then let _ just means "do nothing with that place". That's the criterion I'd want: borrow-checking should ensure that all places can be evaluated enough to know their address. This concretely means that:

If the place is projections on a local, the local must be allocated (so with the move elimination work either let _ = uninit; causes the local to be allocated, or let _ = uninit; is statically rejected, I don't care);
If the place is projections on a pointer dereference, that pointer value must be readable, so the place that contains it must be initialized.

This allows let _ = *null; (the null pointer has a known address) and rejects let _ = *uninit;.

Seems reasonable

Navigation Menu

Borrow checker allows "place mention"-dereferencing an uninitialized reference #164705

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Borrow checker allows "place mention"-dereferencing an uninitialized reference #164705

Description

Activity

theemathas commented on Oct 21, 2026

theemathas commented on Oct 21, 2026

theemathas commented on Oct 22, 2026

saethlin commented on Oct 22, 2026

theemathas commented on Oct 22, 2026

RalfJung commented on Oct 22, 2026

maxdexh commented on Oct 22, 2026

Nadrieril commented on Oct 22, 2026

maxdexh commented on Oct 22, 2026

RalfJung commented on Oct 22, 2026

BoxyUwU commented on Oct 27, 2026

Nadrieril commented on Oct 27, 2026

BoxyUwU commented on Oct 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions