@dotnet/roslyn-ide @dotnet/roslyn-compiler @RikkiGibson @CyrusNajmabadi ptal

It's unclear to me why we're taking this approach in this PR, especially given this comment:

The compiler constructs the full path of a source generated file from the value of CompilerGeneratedFilesOutputPath msbuild property, if set, or from output path otherwise. This path is then used to generate metadata name of file-scoped types.

What if we just...didn't do that, and used the source-generator relative path for the metadata name being generated in either case? Would that be much simpler, and also avoid having to create several public APIs in the process?

(I recognize I'm out of the loop here, but it'd be nice if we can write down somewhere what alternate approaches were considered here.)

@RikkiGibson To comment on that. The change he's made in the compiler was mainly for interceptors which also use the file path: #71879

Using full paths for generated files solves other issues. See #51998. I don't see any drawback.

The latest design of interceptors, which we are pushing all generators to move to, doesn't actually use the file path. It uses the content checksum, and a file name for error reporting.

re: generated files having full paths in general: Behavior of code differs depending on file path in a number of scenarios. It seems like a good thing to always use the same full paths that "would be used when emitting the files to disk". It seems like it is a general preference that we have the ability to take those files emitted to disk, add them to compilation, then remove the associated generators, and get an equivalent result from compilation.

API review feedback incorporated.

@jjonescz, @chsienki PTAL at compiler changes.