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
