EmitCompilerGeneratedFiles while output redirected back into project folder causes duplicate errors

[chismar]

I'm migrating from an old precursor of Source Generators by AArnott which I have customized a bit, to the modern Source Generators.

In my previous implementation Source Generators outputted generated code on disk which then passed compilation like normal file. It was also completely intellisensed, source controlled and debuggable.
If I'd remove the generator nothing would change as the generated code has already been created.

After migration I have lost all those QoL features like the code being properly intellisensed and especially DEBUGGABLE.
I've also placed the files adjacent to the sources. So if I had Test.cs then there'd be a Test.generated.cs next to it.
There is a similar discussion #64705, but I feel like the answer is not something I can accept.

Whatever files are outputted are unable to be matched by Rider, VS or otherwise to the symbols in the assembly, since they are not the ones who are fed to the compiler.

Instead the compiler is fed by the inmemory generated sources, while the emitted ones are just for show.

This is very frustrating, and I want to somehow get my QoL features back.

Prefferably source generator would emit the source files and those would be compiled, instead of those in memory.
Such that if I'd remove the source generator as a dependency the sources would remain.
And such that if I rebuild the project with the generator there'd be no duplication errors, since only the emitted files are used.
And such that I could place a breakpoint in those files and actually hit it.

Is there anything I can do for this to work?
Because the entire point of generating human readable sources is lost if I can't actually hit the debug breakpoints in it.

I mean, those are SOURCE generators after all, not inmemorytexts generators. One would assume you'd want the actual source files as the output, with all the features associated.

[CyrusNajmabadi]

Why did you move off of the old system?

After migration I have lost all those QoL features like the code being properly intellisensed

Can you explain what you mean by this? Intellisense should work with SG files just fine. If you're not seeing that, can you file a new issue with repro steps so we can try out your scenario?

Such that if I'd remove the source generator as a dependency the sources would remain.

This is doable. You can ask the compiler to emit the SG files to disk, then remove your generator, then only reference the generated files.

I would actually recommend this as well, as it will vastly reduce the complexity in the system here.

[chismar]

On the repro - I'd come around to that at some point in the future maybe, but as of now I need like 30 hours of daylight per day or a divine intervention to make everything in time. No time for repros.

[CyrusNajmabadi]

No time for repros.

Unfortunately, there's not a lot we can do here then. :(

[CyrusNajmabadi]

Why only support the case of embedded sources?

Because that's the use case they were intended to solve. Non-embedded sources already have lots of other tools that can support that case.

Why force specific layout of generated files?

Not sure what you mean by this.

Why can't I call AddSource with a rooted file path, save said file immediately at said file (somewhere in the ProjectDir) and expect it to just work?

It very much is not. You've now introduced untracked IO into the system. Which means things like incrementality break completely. Tools like msbuild would have no idea about these files

All of that is simply a matter of like 2 IFs in the compiler source.

I honestly recommend you try this. You'll see that thsi doesn't solve things. The IDE code, for example, could add that if to save out the files, but you'd still see all the same issues you're running into today with tooling. Why? Because none of the tooling woudl have any clue what to do with those files (as they would not be part of any project). We could do all the work to add it to the project. But that's what teh code is already doing today.

[CyrusNajmabadi]

It would work like a charm, zero IDE support (from the point of view of IDE there's only normal source files in the project, no weird temp files and such)

THis is not the case. you say "in the project", but this would not be "in the project" as the project doesn't reference that file at all. We'd have to do the work to get the generated file actually into the project system. Which is exactly what the SG infrastructure does today, just without intermediary IO ops.

[CyrusNajmabadi]

Unity won't update its code for the forseable future.

I'm going to close this discussion out. My guess is that there is something about your unity setup that is causing problems. So far, we haven't heard from anyone else about any of these issues, so it's likely a mis-authoring, or some other bug in the tools/tasks there. If you want to file a repro in the future, we'd be able to look at the logs to see what's up. Thanks!