You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello!
Here's a snippet of code which I believe should not compile. The program compiles and exhibits undefined behaviour (sometimes garbled output, sometimes seg-fault, and sometimes the correct output!) on recent nightlies, and beta.
The crux is in run() function, where I tried to construct a BTreeMap<&str, BTreeMap<&str, f64>>. However, it is being constructed from inside a for loop via references which clearly do not last beyond one iteration.
Here are a few different outputs obtained on the same input:
Note that in both cases, we have evidence of memory-UB because the println! statement clearly has a space between the key and the val, so output like: key=PBval=1 shouldn't be happening.
The input and the source code as a Cargo is available here. To test: cargo run < test.json from the root of repository.
A couple of observations that may be relevant:
Bug is present on 1.32.0-nightly (21f268495 2018-12-02), (9fefb6766 2018-11-13), and current beta with 2018 edition. However, 2015 editions, and the current stable compilers report error as we would expect. See playground.
The callback closure is necessary to create the bug. If I throw the code inside the closure outside, and do necessary cleanups, the borrowck indeed complains.
two-level map is also necessary: if I had used BTreeMap<&str, f64> (but similar code), then again, the checker complains about the incorrect lifetimes.
This is a contrived example, but is derived out of a reasonably common use-case (of processing a db and keeping some cumulative stats). I would be happy to help in figuring/fixing the bug here.
The text was updated successfully, but these errors were encountered:
…pnkfelix
Propagate all closure requirements to the caller
Closes#56477
This should be backported to 1.32 if it doesn't make the cut.
r? @pnkfelix
cc @nikomatsakis
Hello!
Here's a snippet of code which I believe should not compile. The program compiles and exhibits undefined behaviour (sometimes garbled output, sometimes seg-fault, and sometimes the correct output!) on recent nightlies, and beta.
The crux is in
run()
function, where I tried to construct aBTreeMap<&str, BTreeMap<&str, f64>>
. However, it is being constructed from inside a for loop via references which clearly do not last beyond one iteration.Here are a few different outputs obtained on the same input:
Output 2 (on same input)
Note that in both cases, we have evidence of memory-UB because the
println!
statement clearly has a space between thekey
and theval
, so output like:key=PBval=1
shouldn't be happening.The input and the source code as a Cargo is available here. To test:
cargo run < test.json
from the root of repository.A couple of observations that may be relevant:
Bug is present on
1.32.0-nightly (21f268495 2018-12-02), (9fefb6766 2018-11-13)
, and currentbeta
with 2018 edition. However, 2015 editions, and the current stable compilers report error as we would expect. See playground.The callback closure is necessary to create the bug. If I throw the code inside the closure outside, and do necessary cleanups, the borrowck indeed complains.
two-level map is also necessary: if I had used
BTreeMap<&str, f64>
(but similar code), then again, the checker complains about the incorrect lifetimes.This is a contrived example, but is derived out of a reasonably common use-case (of processing a db and keeping some cumulative stats). I would be happy to help in figuring/fixing the bug here.
The text was updated successfully, but these errors were encountered: