Prevent "setting" inputs of tracked structs once exposed

[nikomatsakis]

You can set (which we may rename to override) the value of a tracked function for a tracked struct, if you created it:

#[tracked]
struct S { }

#[tracked]
fn foo(db: &dyn Db, s: S) -> u32 {
    23
}


#[tracked]
fn bar(db: &dyn Db) {
    let s = S::new(db);
    foo::set(db, s, 22);
}

This is cool, but we should prevent if it you have "exposed" the struct to another tracked function (which may have read this value...)

#[tracked]
struct S { }

#[tracked]
fn foo(db: &dyn Db, s: S) -> u32 {
    23
}

#[tracked]
fn bar(db: &dyn Db) {
    let s = S::new(db);
    baz(s);
    foo::set(db, s, 22);
}


#[tracked]
fn baz(db: &dyn Db, s: S) -> u32 {
    ...
}

[nikomatsakis]

Although, as I write this, I am thinking that maybe we could check dynamically whether a value for foo(s) exists (i.e., did baz invoke it)? Isn't that good enough?

One counter argument:

If we make it an error to invoke set once another tracked function has been invoked, we can even permit multiple updates to foo, since they're all occurring within the same execution.

[nikomatsakis]

I've been thinking about this. I think maybe the right rule is:

• An active query Q can only specify the value of a function F(K) if (a) the key K is a tracked struct that Q created, and (b) there is no value from the current revision.

In other words, you can specify the value once, but not again. Then we don't have to worry about whether something is "exposed" or not.

There are some interesting cases to watch out for like: Q or some query invoked by Q could invoke F(K) before Q attempts to specify, which would give F(K) a value in the current revision, leading to an error when Q attempts to specify it later. This seems ok.

My hesitation is that I could imagine it being useful to have a value that is continuously updated until it is "frozen". If we adopt this approach, we could still have that, but we'd have to figure out how to determine when the value is frozen, and when it is readable.

For example, we could say that it is a cycle error to read the value of a field specified by Q while Q is still active -- though it would add some overhead as we have to track that somehow. We could make it something you annotate on the tracked field.

[nikomatsakis]

The more I think about it, the more I prefer the "write at most once" rule. It's simple, and it's consistent with other tracked struct fields.

There is always the workaround of "accumulating" the value for a given field in a local hashmap and then setting the final value.