How are virtual function calls specced?

[JakobDegen]

To make the question more precise, consider this code:

trait A {
    fn foo(&self, u32) -> i32;
}

fn nameless(r: &dyn A, x: u32) -> i32 {
    (&dyn A)::foo(r, x)
}

What does the spec say happens at the (&dyn A)::foo(r, x) call?

Whatever we choose must be strict enough to disallow inserting an extra println!("AAAAA"); that the user did not write, but also permissive enough to not stabilize the layout of vtables.

This is forked off from #328 .

[JakobDegen]

I suggest: Abstract machine devirtualization tables. The r: &dyn A, consists of too parts, p: ptr and metadata: ptr. When calling (&dyn A)::foo(r, x), the metadata is separated out and the AM consults an AM devirtualization table that is unique to (&dyn A)::foo. This table maps metadata values to function pointer with signature fn(ptr, u32) -> i32. Once the function pointer has been retrieved for the given metadata, it is called with the parameters that were passed to (&dyn A)::foo.

Importantly, these devirtualization tables are not located anywhere in AM memory. Compilers can implement this pattern via vtables, justified by the as-if rule. This has the advantage of making the behavior of virtual calls completely explicit, while allowing compilers the full flexibility of implementing their vtables using whatever representation they like. The meaning of the metadata pointer remains 100% implementation defined, to the extent that it would even be correct for the pointer to be dangling (assuming the required functionality could still be implemented).

[chorman0773]

The way I'd define it is

The metadata produced by unsizing to a pointer to a trait object is an unspecified pointer that identifies the dynamic type of the value that was unsized, and is sufficient to determine the properties of the dynamic type, including its size and alignment requirement, and the functions corresponding to each trait method that can be called on the trait object.

with

The result of calling a trait method on a trait object pointer is the same as calling that trait method on the static value as the type of the unsized value. The behaviour is undefined if the metadata of the trait object pointer does not identify any type or if the data pointed to by the trait object pointer does not satisfy the type identified by the metadata.
[Example: given the following trait definition and trait impl, <i32 as Foo>::foo(&x) and (&x as &dyn Foo).foo() shall be equivalent-expressions:

pub trait Foo{
    fn foo(&self);
}
impl Foo for i32{
    fn foo(&self){println!("Foo");}
}

]

[JakobDegen]

Yeah, I believe our definitions are functionally equivalent, except that I consider (maybe unreasonably much) the operational-ness of my definition to be a significant benefit that we should try and retain wherever possible

[chorman0773]

True - mine is a better prose spec, yours is a better description of the operational semantics (w/o exposing impl-details).

[digama0]

Does the metadata pointer have guaranteed static lifetime? Is it guaranteed to be usize large?

Regarding the difference between Jakob's and Connor's specs: Connor's mentions that it is UB to call <&dyn A>::foo((ptr, metadata)) if metadata is not a dyn metadata pointer ("does not identify any type or if the data pointed to by the trait object pointer does not satisfy the type identified by the metadata"). Operationally, how is this tracked? Is there a provenance specific to dyn metadata? How are types distinguished? (Are we going to have a spec-version of rust-lang/rust#10389?)

---

My answers to these questions:

• Yes, the metadata pointer produced by unsizing has static lifetime. Metadata pointers in general are not required to have static lifetime, and calling a dyn function works as long as the metadata pointer is valid (which, like Jake said, does not necessarily entail that the pointer is pointing at allocated memory)

• The metadata is guaranteed to have the same size as *const () (which is the same as usize; the uptr stuff might rewrite this line later).

• Each dyn metadata pointer is in its own address domain which has access to zero bytes (so you are not allowed to read directly through it). The pointer tags are stored in the AM devirtualization table as described by Jakob, which also maps the tag to the address of that pointer (the base of the allocation). Calling <&dyn A>::foo((value, metadata), arg) checks that the metadata tag exists in the table and has the correct pointer value (else UB), and then it calls the foo: fn(ptr, u32) -> i32 function pointer stored in the table as foo(value, arg), which can subsequently cause UB if value has the incorrect type.

• It is not otherwise UB to call a pointer with the incorrect metadata type, unless one of the above mechanisms signals UB. In particular, unsizing, which creates dyn metadata, uses the lifetime-erased type to create the metadata, so punning the lifetimes is explicitly allowed. (Type equality questions don't really appear here because unsizing is not guaranteed to produce the same dyn metadata value even if used on the same type. It simply has to produce some dyn metadata value which is valid to subsequently call with a value of that type.)

[chorman0773]

Operationally, how is this tracked? Is there a provenance specific to dyn metadata?

Presumaby. though it's fun. Mostly it would just spec-in that if you call a &i32 trait method on a &dyn Any, the actual pointee of the dyn Any can't be a u8 because there isn't a full i32 in that u8.

[chorman0773]

Yes, the metadata pointer produced by unsizing has static lifetime. Metadata pointers in general are not required to have static lifetime, and calling a dyn function works as long as the metadata pointer is valid (which, like Jake said, does not necessarily entail that the pointer is pointing at allocated memory)

I'd wonder if there is a benefit to specifying that calls don't care about the dynamic lifetime if, for the purposes of the spec, all operations that can validly produce the metadata pointer produce something with a 'static dynamic lifetime. Of course, with compiler specific knowledge, you could magic up a vtable with less than static lifetime but as you need to know the implementation, that could merely require the compiler "OK"ing the metadata.

[digama0]

That's a fair point. Given that we want to be able to use "anything Rust code could do" as a way to spec unknown functions and FFI, I think we need to add an intrinsic for creating non-static dyn metadata even if there isn't anything in the surface language to invoke it, if only to say "FFI or other unknown calls, or compiler intrinsics, can maybe do this".

[digama0]

Operationally, how is this tracked? Is there a provenance specific to dyn metadata?

Presumaby. though it's fun. Mostly it would just spec-in that if you call a &i32 trait method on a &dyn Any, the actual pointee of the dyn Any can't be a u8 because there isn't a full i32 in that u8.

To be more concrete, let's consider some cases with the following code:

trait Foo {
  fn foo(&self);
}
impl Foo for i32 {
  fn foo(&self) {}
}
impl Foo for u8 {
  fn foo(&self) {}
}

(I will use <A as dyn Trait>::metadata to mean the dyn metadata you obtain by unsizing some value of type A as a &dyn Trait.)

• Calling <dyn Foo>::foo((&0u8, <i32 as dyn Foo>::metadata)) results in a call to <i32 as dyn Foo>::foo(&0u8), which implicitly transmutes the &0u8 to a &i32. This is immediate UB if the reference is not aligned, but otherwise it is not UB unless the value is read in the function (this one doesn't use the value). This is UB because of retagging, as Jake points out.

• Calling <dyn Foo>::foo((&0i16, <u8 as dyn Foo>::metadata)) results in a call to <i32 as dyn Foo>::foo(&0i16), again implicitly transmuting the type, which here would be fine and would read the low 8 bits on a little endian system.

• Calling <dyn Foo>::foo((&0u8, <u8 as dyn Any>::metadata)) is UB, because the devirtualization table for <u8 as dyn Any>::metadata does not contain an entry for <dyn Foo>::foo.

---

Here's another fun thing: is it legal for the compiler to not create any dyn metadata for ! and consider <! as dyn Any>::metadata to be uninhabited? The only way to make calls into the vtable is using a trait object, which needs a &! or &mut ! even though some things like the size and align don't actually need this data, so it seems like it would be valid to just never create such things. Personally I'm leaning toward requiring that <! as dyn Any>::metadata exists in the same way as non-static dyn metadata: a thing that could possibly exist but for which there is no mechanism in the language to construct them other than implementation-defined things.

[JakobDegen]

This is immediate UB if the reference is not aligned, but otherwise it is not UB unless the value is read in the function (this one doesn't use the value).

It is immediate UB anyway, because the &self argument is retagged on function entry. Because of this, I don't think we should be inserting any additional rules regarding the validity requirements; <dyn A>::foo((value, metadata), arg) should have the same exact validity requirements (modulo metadata) as <ActualType>::foo(value, arg).

[JakobDegen]

Regarding the remaining questions: Generally, I agree with Mario. That being said, I would like to clarify something though: I believe that the devirtualization tables should map pointer values to function pointer values. Importantly, this means that the domain is (allocation_id, sb_tag, address) triples. Otherwise we run the risk of allowing code like this:

let d: &dyn A = something();
let (val, metadata): (_, *const ()) = d;
let metadata_new = &mut *(metadata as *mut ()) as *const (); // Reborrow the `metadata` through a `&mut ()`
let d = (val, metadata_new);
d.foo(5);

As soon as we lower virtual function calls to an IR in which there are vtable pointers instead of devirtualization tables, this will read outside of metadata_new's provenance. That seems like a mess. It forces all relevant IRs to choose between having explicit versions of virtual function calls, or having SB information.

With that worked out, specifying the behavior of dyn upcasting is easy: Create a metadata = alloca(0);, which yields a new pointer with the desired uniqueness properties (address is not unique, alloc id and tag is). This metadata is then inserted into the global devirtualization table (never to be removed) and the function pointer it maps to is the appropriate one from the concrete type impl. The obvious value is returned from the expression.

[digama0]

Regarding the remaining questions: I think they can all be answered simultaneously by specifying the behavior of (val: &Concrete) as &dyn A. Before I do that, I would like to clarify something about my previous proposal though. I believe that the devirtualization tables should map pointer values to function pointer values. Importantly, this means that the domain is (allocation_id, sb_tag, address) triples.

• Are allocation_id and sb_tag not the same thing? I thought we can make one tag do both jobs.
• In my variation, the table is just taking the allocation_id/sb_tag and asserting the address, instead of taking both. I think there is not much difference, since presumably each tag is only going to have an entry in the table for exactly one address, but if you have some reason to allow for multiple pointer values at the same tag to work please speak up.

Otherwise we run the risk of allowing code like this:

I don't see the issue: Reborrowing creates a new tag, so it would be rejected as a legal metadata value. Or do you want to accept that code?

With that worked out, specifying the behavior of dyn upcasting is easy: Create a metadata = alloca(0);, which yields a new pointer with the desired uniqueness properties (address is not unique, alloc id and tag is). This metadata is then inserted into the global devirtualization table (never to be removed) and the function pointer it maps to is the appropriate one from the concrete type impl. The obvious value is returned from the expression.

Ah, I don't think this one is quite right. I don't think we want to promise that metadata acquired through unsizing is unique or a fresh id, and in fact we might want to promise the opposite. It also looks like another interesting application of NB. I would say that the compiler is allowed to return nondeterministically any metadata value valid for the type and trait (which was already in the map beforehand). It's not entirely clear to me whether the "allocation" of a new entry in the map would be observable, but it seems like a safe bet to not allow such a thing.

Put another way, I think that metadata values should already exist at program start in the same way as function pointer values. (Dyn unsizing has a lot in common with casting fn() {foo} to fn()).

[JakobDegen]

Are allocation_id and sb_tag not the same thing? I thought we can make one tag do both jobs.

Ralf had mentioned at some point that they might not be. It seems possible to make them the same thing, but that's off-topic here, so just for safety I'm including both.

Besides that, I think I had misread your original proposal. Re-reading it now, I agree that ours are actually the same, and both correctly disallow the code I posted above

[RalfJung]

What's wrong with saying that basically what Miri does is the spec? I assume it is the concern I raised about wanting to change vtable layout in the future?

Seeing all this extra complication here, I wonder if we cannot carefully delineate some part of this as being a part of the spec that might change in the future -- like how exactly the fn ptr is determined given the vtable ptr and trait?

[digama0]

I believe the purpose of the complication here is precisely to allow the compiler freedom to do other things, in particular devirtualization. I think it is right that even beyond simply assuming that a vtable pointer is in unspecified layout like a repr(Rust) struct, it can also simply not be at the address it purports to live at - this is an observable property since you could hand-code an offset pointer access to get at the function pointer, and this apparatus allows us to say that accessing vtable data yourself is UB, which is necessary if the table isn't actually there because it was devirtualized but you've hacked together another access of the function manually to fool the compiler's devirtualization analysis.

Seeing all this extra complication here, I wonder if we cannot carefully delineate some part of this as being a part of the spec that might change in the future -- like how exactly the fn ptr is determined given the vtable ptr and trait?

I think the operative question is: is the determination of fn ptr from vtable ptr and trait something that well-defined rust code could do? Assuming it knew the compiler's layout. The thing the Jakob's (and Connor's) models allow you to do is say "no this function is magic and you cannot fake it with rust code" which seems like the maximally conservative choice if we want to consider the possibility of compilers being clever and reading a lot into the structure of virtual calls.

Another thing: you say determination of the "fn ptr" from the vtable ptr, but AFAIK the fn ptr itself is not something you have access to with non-weird rust code: you can only call the function, not observe its location. An explicit (but unspecified) repr for vtables would presumably imply that this fn ptr is accessible, which might limit what a compiler can do with inlining and deleting the function.

What's wrong with saying that basically what Miri does is the spec?

What exactly does Miri do? I assume it just has a concrete vtable layout. One issue with this is that the vtable layout has to match rustc's or else it could miss UB in user code. With this abstract approach, you can "naturally" model vtables directly (i.e. in actual data structures instead of in simulated memory) in Miri and you only need to know spec stuff to write it, which seems like a plus.