Virtual functions should not capture the environment.

[mihaibudiu]

No description provided.

[ChrisDodd]

Virtual functions need to be able to access arguments of the control instance that contains the extern instance defining the virtual function. The extern types themselves are generally defined at the global scope and so have no access to things like headers and metadata (instances). There's generally no fixed set of values/types that could be used as extra paramters to the virtual function; to pass things that way we'd need something like C++ template parameter packs.

[mihaibudiu]

We can perhaps allow such function access read-only information, like in parameters. But I don't see how we can let them access values that can change at runtime.

[ChrisDodd]

Pretty much all the uses we've come up with for virtual functions so far involve them accessing dynamic information available in the static context, so I think forbidding that is a non-starter.

[mihaibudiu]

What this means is that we need to have two kinds of abstract functions: some that can be analyzed, and which can capture the environment, and some which can do anything, and thus cannot. An annotation is a way to distinguish them.

extern Virtual { 
    @synchronous abstract bit f(in bit x);
    @calls(f) void method();
}

This promises that all calls to f are made from method and that all calls to method are where the user writes them.

[mihaibudiu]

This cannot handle something like action profile selection, because the call does not show up as P4 code.

[antoninbas]

This is an old thread but it seems to be relevant to the discussion in #1468
@mbudiu-vmw for action profile selection, could the @calls annotation go on the apply statement for the table? Wouldn't that be enough?

[mihaibudiu]

The problem is that the table execution is done in several steps. For example, key evaluation, key lookup, selector evaluation, action execution, etc. The question is: at which moment is a specific function executed?

[antoninbas]

That's no different from an extern function calling multiple virtual function implementations though. Or would the @calls annotation tell you the exact order in which virtual functions or called and how many times?

[mihaibudiu]

We need enough information to allow the compiler to conservatively bound the side-effects that will happen for each statement. At least for external calls that are invoked explicitly we know all the statements where the effects could happen. Tables are more complicated, for example we know the key and the actions, and we probably would need to know whether a virtual call is happening before or after the actions. We could also conservatively assume that it may happen either before or after.