-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How should source generators emit newlines? #51437
Comments
For reference, see dotnet/roslyn-analyzers#4749. The main issue is that |
/cc @chsienki |
My source generator uses buffer.Append(@"
"); With P.S. Appending new lines with |
Tagging @jasonmalinowski. This is solved in the IDE and we woudl want the same solution to work for the compiler layer. Note that there are potentially many options in play here, including (but not limited to):
|
Does this also matter for deterministic builds, so that embedded source in binaries doesn't fluctuate between line ending types depending on the OS of the CI machine that compiled it? Or are source generator outputs already considered out of scope for the purposes of determinism? |
So yeah, this might just be a prioritization thing:
We obviously hope that generators are well-behaved, but we can't guarantee it depending on how it's written. This in some sense is no different than analyzers, in that an analyzer may be non-deterministic too. We obviously hope that's not the case (the user experience is then crap) but there's nothing we can do to specifically prevent it. |
That probably isn't a good solution, for the reasons I mentioned above. If there is an existing file on disk, it should match to that first. |
In the IDE we have a service (provided by the platform) to perform those heuristics. Sounds like you may need to port this to the compiler as well and expose through a well-known api for generators to consume. |
Don't think that dotnet/roslyn-analyzers#4749 is a good reference point here. That is a discussion about how new lines should be inserted into an existing file. Essentially it's a discussion about new line consistency. There is no issue with consistency in a source generated file because it's a blank state, it's all about what should the default be.
Generators always emit new files.
This does not impact deterministic builds because determinism does not exist across OS. By that I mean if you compile a fully deterministic build on Windows and Linux you will get different binaries. The OS contributes to the signature of the binaries in a number of unintuitive and essentially unavoidable ways |
They do not. If the write to disk flag is set, then there exists a copy of the file on disk, and if a generator uses different lines endings, then it will look to git like a problem. Yes, they don't read from the existing file today, but the end effect is not a new file, the end effect is an edited file. |
That is still a new file, not an edit from the perspective of the generator. It is explicitly not an input to the process. |
I'll just throw 2-cents in here. A silly request that .Trim() just magically gets called Selfishly, I want my code generated files to "look nice". Whether they're on disk or not, I also want to see them in visual studio, even if it was just some virtual magic that makes it work and they're never emitted to disk. So, if those requests are ever a thing, then the CRLF debate may have an impact on it. |
@joshlang I know you mentioned this a little while ago, but in case you are still looking for it: you can view the generated files in VS. Whether or not you actually persist them to disk the IDE will show them to you here. See this link and CTRL-F for "view the generated code" https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes#NET-Productivity |
…e line ending differences between platforms. Ref dotnet/roslyn#51437 (comment)
There's a source generator that always emits CRLF, whether running on Windows or not. Is there a guideline for what source generators should do?
@333fred says there should likely be a helper to prevent mistakes such as source generators writing to disk and changing line endings in source-controlled files.
The text was updated successfully, but these errors were encountered: