Ah, thanks for clearing that up. That makes much more sense now :) On Jun 28, 2013 10:04 PM, "Björn Steinbrink" <bstei...@gmail.com> wrote:
> Hi, > > On 2013.06.28 13:27:57 +0200, Michael Woerister wrote: > > I hope this question is not too specific for the mailing list, but I > > stumbled upon something I don't understand today and thought I'd > > better ask. > > In librustc/middle/ty.rs there is the mk_t() function which creates > > and caches objects of type "t" from values of type "sty". However, > > the way it uses the cache seems kind of strange, especially the key > > creation at the beginning: > > > > fn mk_t(cx: ctxt, st: sty) -> t { > > // Check for primitive types. > > // ... omitted here ... > > > > let key = intern_key { sty: to_unsafe_ptr(&st) }; > > match cx.interner.find(&key) { > > Some(t) => unsafe { return cast::transmute(&t.sty); }, > > _ => () > > } > > > > The intern_key is created by taking a pointer to "st", which in > > effect is the address of the argument slot on the stack. That can't > > be right, can it? > > The IterBytes implementation for intern_key, which is used to generate > the key for the hashmap, derefs the stored pointer, so it's using the > actual value on the stack. And when actually interning, the interned > value has a "sty" field, which is referenced by the key for that value, > so the pointer in the intern_key stays valid as long as the value is in > the interner. > > HTH > Björn >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev