Stream: t-compiler/wg-incr-comp

Topic: implementing the expect RFC


view this post on Zulip nikomatsakis (May 21 2021 at 15:13):

Hey @mw -- I'm thinking about how to implement https://github.com/rust-lang/rust/issues/85549 (cc @xFrednet).

view this post on Zulip nikomatsakis (May 21 2021 at 15:13):

It doesn't fit especially well with our incremental system.

view this post on Zulip nikomatsakis (May 21 2021 at 15:14):

What we need to do is to be able to tell:

view this post on Zulip nikomatsakis (May 21 2021 at 15:14):

of course, those lints could be generated at any point in compilation

view this post on Zulip nikomatsakis (May 21 2021 at 15:15):

I think this is a case where I would really want a model more like the adapton model

view this post on Zulip nikomatsakis (May 21 2021 at 15:15):

where you can "push writes" to a bit of "mutable state"

view this post on Zulip nikomatsakis (May 21 2021 at 15:15):

(a collection of "seen lints")

view this post on Zulip nikomatsakis (May 21 2021 at 15:15):

I've thought about how to model that within salsa

view this post on Zulip nikomatsakis (May 21 2021 at 15:15):

I was going to setup a method that generates "side effects"

view this post on Zulip nikomatsakis (May 21 2021 at 15:15):

which basically get collected in a side-vector along the main result

view this post on Zulip nikomatsakis (May 21 2021 at 15:15):

and accumulated by the (transitive) set of queries that a query Q performs

view this post on Zulip nikomatsakis (May 21 2021 at 15:15):

so that you can say "what side effects were part of Q"

view this post on Zulip nikomatsakis (May 21 2021 at 15:15):

and you get all the side-effects from Q and any queries that it transitively executed

view this post on Zulip nikomatsakis (May 21 2021 at 15:16):

that way the lint pass could ask "what expect lints were seen" (for example)

view this post on Zulip nikomatsakis (May 21 2021 at 15:16):

I've yet to come up with a better idea, maybe that's just the thing to do ?

view this post on Zulip Wesley Wiser (May 21 2021 at 15:17):

nikomatsakis said:

I think this is a case where I would really want a model more like the adapton model

What is the adapton model?

view this post on Zulip nikomatsakis (May 21 2021 at 15:18):

http://adapton.org/

view this post on Zulip nikomatsakis (May 21 2021 at 15:18):

I dont' actually think we want that

view this post on Zulip nikomatsakis (May 21 2021 at 15:18):

I like the query system, it can be explained relatively easily

view this post on Zulip nikomatsakis (May 21 2021 at 15:18):

the side-effects that I describe are a nice fit

view this post on Zulip mw (May 25 2021 at 11:47):

@nikomatsakis I'll let you know when I had time to think about this is some detail

view this post on Zulip nikomatsakis (May 25 2021 at 16:33):

I might prototype my proposal in salsa, @mw

view this post on Zulip cjgillot (May 25 2021 at 19:07):

Diagnostics are already saved and replayed by the incr. comp. engine. Adding a source_lint: (HirId, Lint) to the Diagnostic struct may provide with the necessary information. Then, an iteration over all the emitted diagnostics would have the necessary information to mark the expect attribute as used.

view this post on Zulip cjgillot (May 25 2021 at 19:13):

Another possibility would be to create some kind of mark_attribute query, and verify at the end of a compilation whether a DepNode for mark_attribute(my_attr) exists. The query engine will attempt to mark this query green, so it will create a DepNode in the current session with it. At the end of the compilation session, we just need to check the query's cache for filled/empty buckets.

view this post on Zulip xFrednet (May 25 2021 at 20:11):

cjgillot said:

Diagnostics are already saved and replayed by the incr. comp. engine. Adding a source_lint: (HirId, Lint) to the Diagnostic struct may provide with the necessary information. Then, an iteration over all the emitted diagnostics would have the necessary information to mark the expect attribute as used.

Interesting, after reading this comment I've found a query called store_diagnostics with a corresponding load_diagnostics query. I'll investigate that lead for a bit :upside_down:

view this post on Zulip mw (May 26 2021 at 09:48):

Yes, we do record diagnostics for each query and store them so they can be replayed in a subsequent compilation session without actually re-executing the query. This is safe because there is no way to access the value of the diagnostics from a query, so no query result can depend on these "side effects". Extending that to also record data about lints being produced seems fine as long as we guarantee that that data is only accessed after the last query has been executed, right?

We could think about an adapton-like extension to the query system where we have "queries" that can be written to and that panic if a write occurs after their result has been read for the first time. As long as the writes a query are completely determined by its inputs that should work too. However, I'd like to keep the query system as simple as possible, so unless this is really necessary I'd rather not go that route.


Last updated: Oct 21 2021 at 21:20 UTC