Symbol.Locations has indeterministic ordering of locations between compilations with same inputs

[mavasani]

See #8067 (comment) for a repro.

This will cause inconsistent analyzer diagnostics across command builds (most symbol analyzers will report diagnostic on the first location of the symbol). Additionally, it is already causing a race condition in IDE diagnostic engine, that uses different compilations to compute open file and full project diagnostics, to miss out on reporting some analyzer diagnostics.

[jaredpar]

Is this in the analyzer layer or compiler?

[mavasani]

This is compiler layer (symbol.Locations API) - but the impact seems to be for the end users that install analyzers.

[jaredpar]

Is this just an error presentation problem? The mention of a "race in the IDE" seems like it could be bad (crashes scary) or just changes order of errors (punt to next version).

[mavasani]

End user will see different set of diagnostics based on which files are open/closed. Additionally, the location (file path) for analyzer diagnostics reported on partial types will vary every time the intellisense build kicks off (say editing any top level declarations). I think we ought to fix this for Update3.

[mavasani]

Also tagging @heejaechang @srivatsn for discussion.

[jaredpar]

@mavasani unfortunately diagnostics don't meet the bar for Update 3 right now.

[mavasani]

@heejaechang @srivatsn - I think we need to put a workaround in the IDE diagnostic engine until compiler fixes this bug. Intellisense diagnostics from full solution analysis are essentially broken if we do nothing here.

[heejaechang]

just talked with @mavasani , I think it might not possible to workaround it in IDE side.

[mavasani]

@jaredpar I am willing to work on a fix in the compiler layer, if the compiler team will take this for Update3.

[jaredpar]

@mavasani it's less about who does the work and more about we're avoiding any changes to the compiler that don't meet our bar for stability reasons. As explained here it just seems like this is a diagnostic ordering issue which is well below our bar. Is there something I'm missing that makes it more compelling?

[mavasani]

Yes, there seems to be a misunderstanding. This is not an ordering issue, its a functionality issue. You will see different number of intellisense diagnostics in the error list based on which files are open/closed. Additionally, the file path/location of reported diagnostics will vary from compilation to compilation - i.e. basically as you type, analyzer diagnostic reported on a partial type can jump from one partial definition to another, and squiggles will come and go. Essentially, error list and squiggles will be indeterministic for all analyzer diagnostics from symbol analyzers.

[srivatsn]

Full solution analysis being off by default exacerbates this. Before, at least if the error list was open, you'd see the error from the other partials - just the squiggles would be different . Now with fsd off, if the other partial definition is not open, the error will come and go seemingly randomly.

[jaredpar]

Gotcha. I agree the scenario meets the bar for U3

[mavasani]

#3748 is also affected due to this bug.

[weltkante]

@cston @mavasani this issue being closed, whats the status of original issue #8067 (which is still on blocked) ?

[mavasani]

I'll verify it tomorrow

[mavasani]

@weltkante I have verified that #8067 is now fixed on latest bits.