does this need to be mutable?

deserialization should work if we use init accessors instead.

Sealed

consts above everything.

sealed.

ideally name this something a little more specific. as this makes searching for types hard.

instead of asking for cached diags, why not just ask for the diags appropriate for Document. ANd if they have been cached they are returned, otherwise they are computed.

I'm very wary about this producing stale data that is then not updated properly as changed come in.

Seems plausible, I am actually wondering what would happen if we simply changed this to "get the virtual project" again, using whatever content is in the current version of the doc, which will take a second or two usually, and forward the diagnostics. Then I guess this source could be marked as live.

In the medium term I think we also want to try to forward certain msbuild diagnostics (e.g. if a bad id or version is used with#:package). But that could just be a different thing reported from a different source.

...except that run-api wants to take a file path for the file-based program, which it will read from disk. That means the diagnostics coming back would still be stale until user hits save.

For the short term I think it is going to be better to start with the "non-live" diagnostics which are essentially driven by design time build, and in medium term make the necessary adjustments to make the subset of diagnostics live, which can be made live.

this is... odd.

The dotnet run-api does not have IDs for its diagnostics, at least for the moment, so a magic diagnostic ID needs to be used. Compare with the TaskListDiagnosticSource.

Possibly an ID like FileBasedPrograms may be at least marginally more clear here.

can you doc the reasons for some of htese values?

is this true?

Currently these are errors which are essentially only updated when a design time build is performed. That is something which only happens on save. Per the interface methoddoc comment:

Non 'live' errors (aka "build errors") are recognized to potentially represent stale results from a point in the past when the computation occurred.

the staleness issue semes real here. it looks like we could return incorrect diagnostics for a solution snapshot. and it's unclear what would snap the ide out of that state.

This is updated each time a design time build occurs, which for the moment occurs whenever the file-based program is saved to disk.

The cached diagnostics would probably need to be updated in the other code paths also. e.g. if run-api completely fails, the stale diagnostics we already had in the cache are likely not useful and should be cleared out.

will these ever be warnings? Will people ever be able to suppress these errors, or configure the severity?

If not, then diagnostic source seems like an appropriate way to go, but if not we may want to consider having these come from an analyzer, so all the suppression / configuration infrastructure could come into play.

For the diagnostics we get through here today, it means something is wrong with the directives syntactically, and for exampledotnet run of the same file will fail.

this looks correct. generally the guidance I have on using the refresher is to use it as sparingly as possible because it refreshesall diagnostics. It looks like you're already checking to make sure there are changes which is good.

But the less that goes through this the better. Ideally we can get most diagnostics from the actual Roslyn snapshots, and then the normal on-type updates handle most changes.

How do we remove diagnostics? It looks really bad when we have stale diagnostics, so we definitely need to ensure we're clearing them when the file based project is deleted / renamed / otherwise changes contexts?

We also probably need to remove them from the_diagnosticsByFilePath map if the file/project is deleted, otherwise we have a small leak