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
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
