Expose a public API to tell whether Document/SyntaxTree is likely a generated file

[KirillOsenkov]

There is an IGeneratedCodeRecognitionService, but it's internal: http://source.roslyn.io/#Microsoft.CodeAnalysis.Workspaces/GeneratedCodeRecognition/IGeneratedCodeRecognitionService.cs,da8ecea861634562

My scenario: I don't want the diagnostic produced by my analyzer to show up in the Error List and I don't want fixes offered in files such as g.i.cs etc. I should be able to either declaratively specify this on my diagnostic provider (via attribute, optional param etc) or imperatively during analysis ask the Document or the SyntaxTree whether it was likely generated (either by making the interface above public or by exposing a property "LooksLikeGeneratedCode" or something).

[pharring]

CSharpEssentials (@DustinCampbell) had the same problem. Ended up copying the source code.
Note that it's just a heuristic based on the document's filename.

You might also want something that works on a SyntaxNode that looks for "compiler generated" attributes. See DustinCampbell/CSharpEssentials#26

[KirillOsenkov]

Yeah. Imagine every analyzer out there having an outdated copy of that list :) I think that language service should be made public and extensible by MEF so you could export your own criteria to extend the hardcoded list.

[paul1956]

+1 I had to clone from CSharpEssentials (@DustinCampbell https://github.com/DustinCampbell ) and then change for VB.

From: Kirill Osenkov [mailto:notifications@github.com]
Sent: Thursday, August 13, 2015 11:46 AM
To: dotnet/roslyn roslyn@noreply.github.com
Subject: Re: [roslyn] Expose a public API to tell whether Document/SyntaxTree is likely a generated file (#4530)

Yeah. Imagine every analyzer out there having an outdated copy of that list :) I think that language service should be made public and extensible by MEF so you could export your own criteria to extend the hardcoded list.

—
Reply to this email directly or view it on GitHub #4530 (comment) . https://github.com/notifications/beacon/AMMmeYJ6otsd0A6aD7h8qUAfR_Na1chBks5onN1PgaJpZM4Fqv8W.gif

[srivatsn]

We would likely have to tackle this when we get to #3705.

[giggio]

We had to manually solve this on CodeCracker: code-cracker/code-cracker#260
This should really be on the Roslyn platform, not on the analyzer project themselves.

[giggio]

BTW, is this a duplicate of #1751?

[srivatsn]

It's not a duplicate but it's related. The codeanalysis property page for a project today has a switch called "Suppress issues in generatedcode" and FxCop knows to not analyze things marked with that attribute. I think to implement #3705 we'd want a similar treatment for roslyn analyzers where analyzers aren't even called by the compiler on generated code. However what is generated code is very heuristic driven and making an API for problematic unless there was either some clear definition or a way to customize that definition.

[DustinCampbell]

FWIW, I just submitted DustinCampbell/CSharpEssentials#31 to do a better job than just looking at file names. Now, C# Essentials also looks for <auto-generated> in a file's comment header, which StyleCop supports.

[bkoelman]

I'm doing similar checks. it would be great to have an API within the compiler for that.

[srivatsn]

We discussed this in a design meeting recently and exposing the current API as is doesn't seem to be wise because it is a small set of heuristics. We need a configuration file that can extend these heuristics. We'll use #3705 to track that work. However, even when we have that, for analyzers atleast, the default should be that issues shouldn't be reported in generated code because users cannot fix them in most cases and requiring analyzers authors to remember to call this API wouldn't lead to a pit of success. So we want to instead implement #6998 to make it easy for analyzer authors to say they do\don't care about reporting issues in generated code and have the users override them.

[srivatsn]

Closing this issue to expose a generic API given #6998.