Flag source generator I/O

[chsienki]

Describe the problem you are trying to solve

We know that potentially bad-things™ happen when generators perform I/O, so we should flag any generators that do so.

Describe suggestions on how to achieve the rule

We'll look for obvious uses of File.Write etc. from within any class marked with [Generator].

Additional context

We won't be able to get all instances, but it should be enough to dissuade authors from doing so, along with a link to more info to explain why they shouldn't.

[jaredpar]

We'll look for obvious uses of File.Write etc. from within any class marked with [Generator].

Is there a reason we shouldn't just look for the use of I/O in any type in a generator / analyzer DLL? I'm struggling to think of a valid reason why you would be using I/O anywhere in a generator. Assuming there was such a valid reason that particular file could disable the analyzer.

We won't be able to get all instances, but it should be enough to dissuade authors from doing so, along with a link to more info to explain why they shouldn't.

100% agree we can't catch everything. Anyone who wants to deliberately subvert the system can do so. The intent here should be to educate and dissuade developers who want to be on the green path here. Also it's a concrete item we can use in discussions when we find mis-behaving analyzers / generators in the wild.

[AraHaan]

Ok, what if they Process.Start a program (like git) to retrieve information (where git does I/O to look at stuff like commit information)? Would that be considered I/O for an analyzer/source generator?

I do think it should be possible to process.start a program within generators if the sole purpose of it is to retrieve information to use with the generated code. But then again what would the point be in also having Exec in msbuild to try to "obtain" that information before any generators get ran that can obtain that data within a target within their generator.

[Youssef1313]

Fixed with #6115