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
Analyzing the test failure in hashmap.rs revealed we have a problem with lifetime-based subtyping.
In insert_hashed_nocheck, _9 has type core::option::Option<collections::hash::map::Entry<ReScope(Remainder(BlockRemainder { block: NodeId(9681), first_statement_index: 0 })), K, V>> but then we have _17 = ((((_9 as Some).0 as Vacant).0, and _24 = _17, and _17 has type collections::hash::map::VacantEntry<ReScope(Misc(NodeId(9719))), K, V>. The lifetime changed.
The text was updated successfully, but these errors were encountered:
Actually it turns out that this is the same problem as the more fundamental "we can't identify write locks by their lifetime". Which is a problem in the model, not the implementation.
RalfJung
changed the title
Trouble with lifetime subtyping in validation
Lifetimes are unsuited as write lock identifiers
Aug 10, 2017
Analyzing the test failure in hashmap.rs revealed we have a problem with lifetime-based subtyping.
In insert_hashed_nocheck, _9 has type
core::option::Option<collections::hash::map::Entry<ReScope(Remainder(BlockRemainder { block: NodeId(9681), first_statement_index: 0 })), K, V>>
but then we have_17 = ((((_9 as Some).0 as Vacant).0
, and_24 = _17
, and _17 has typecollections::hash::map::VacantEntry<ReScope(Misc(NodeId(9719))), K, V>
. The lifetime changed.The text was updated successfully, but these errors were encountered: