Fatal Compilation Error: preprocessor directives, not placed on new line

[aabs]

Describe the bug

Getting errors after updating to Microsoft Visual Studio Professional 2022 (64-bit) - Preview
Version 17.13.0 Preview 2.0.

The error messages produced indicate malformed code generation in Vogen:

1>C:\dev\aabs\5th-related\ast-builder\src\ast-model\obj\Debug\net9.0\Vogen\Vogen.ValueObjectGenerator\ast_AssemblyName.g.cs(97,37,97,38): error CS1040: Preprocessor directives must appear as the first non-whitespace character on a line

The original code looks like this:

[ValueObject<string>]
[Instance("anonymous", "", "For things like in-memory assemblies etc")]
public partial struct AssemblyName;

The generated code contains this:

#pragma warning disable CS8767 // Nullability of reference types in type of parameter doesn't match implicitly implemented member because of nullability attributes.

        public static bool TryFrom( #if NETCOREAPP3_0_OR_GREATER
[global::System.Diagnostics.CodeAnalysis.NotNullWhen(true)] 
#endif
        System.String? value, #if NETCOREAPP3_0_OR_GREATER
 [global::System.Diagnostics.CodeAnalysis.MaybeNullWhen(false)] 
#endif
        out AssemblyName vo)
#pragma warning restore CS8767 // Nullability of reference types in type of parameter doesn't match implicitly implemented member because of nullability attributes.

        {
. . . snip
        }

Note the fragment TryFrom( #if NETCOREAPP which is invalid.

Steps to reproduce

Update VS to latest preview (17.13.0 Preview 2.0).
Rebuild the code. Build will fail with the above issue.

I tried updating to the latest version of the Nuget pkg (5.0.6) and restarting VS, but the code generated still broke.

Expected behaviour

The #if should be on a new line. Then all should be fine.

[danielcweber]

Temporary workaround: Fixate the SDK to a working version and disable rollforward in a global.json. This works for me:

{
  "sdk": {
    "version": "9.0.101",
    "rollForward": "disable"
  }
}

[aabs]

thanks for the suggestion. I tried that, and then forced a regeneration (after a VS restart) and the result still contained malformed C#.

[aabs]

I was able to temporarily suppress the generation of the TryFrom and TryParse code by adding the following to my decls, but I'm not sure what the downstream consequences would be.

[ValueObject<uint>
#if VOGEN_IS_BROKEN
    ( parsableForStrings: ParsableForStrings.GenerateNothing, 
      tryFromGeneration: TryFromGeneration.Omit, 
      parsableForPrimitives: ParsableForPrimitives.GenerateNothing )
#endif
]

[nabeelio]

I'm running into the same issue. I put the SDK version back to 9.0.100, and I'll try to keep going backwards. I updated last night, and I think I was on quite an old version.

I tried @aabs suggestion, but that parseableForStrings option would break things (I think, trying it now)

[ValueObject<string>(
    tryFromGeneration: TryFromGeneration.Omit,
    parsableForPrimitives: ParsableForPrimitives.GenerateNothing
)]
public readonly partial struct PirepId;

It's generating:

        /// <summary>
        /// </summary>
        /// <returns>
        /// True if the value passes any validation (after running any optional normalization).
        /// </returns>
        public static global::System.Boolean TryParse(
#if NETCOREAPP3_0_OR_GREATER
[global::System.Diagnostics.CodeAnalysis.NotNullWhen(true)]
#endif
        global::System.String? s, global::System.IFormatProvider? provider,
#if NETCOREAPP3_0_OR_GREATER
[global::System.Diagnostics.CodeAnalysis.MaybeNullWhen(false)]
#endif
 out PirepId result)

[nabeelio]

Damn, looks like only back to 9.0.100 is available.

[nabeelio]

Adding parsableForStrings: ParsableForStrings.GenerateNothing did work, but not sure of the side-effects

[SteveDunn]

Thanks for the report. I think the problem was, at some point, I wrapped the attribute with #if NETCOREAPP3_0_OR_GREATER; the attribute didn't need to be on a newline, but the preprocessor obviously does. Thanks for the fix and the suggestion @danielcweber . I'm just updating your PR with rebased snapshots (the trick, when changing anything that changes the output, is to just run .\RunSnapshots.ps1 -v "minimal" -reset (and then go on a short holiday while it resets 30,000+ files :/ )

[Khaos66]

I just love how I stumbled across this issue just today and an hour later it's fixed <3 THX YOU ALL! AWESOME!!!

[SteveDunn]

Yes, this is fixed in 6.0.0-beta.3. I've created a Discord thread in the Roslyn channel as something has changed (but admittedly, the source that Vogen generated was also wrong, in that it needed preprocessors on their lines)
https://discord.com/channels/732297728826277939/735233259763400715/1321845291774906368

[SteveDunn]

For reference, this is the Roslyn bug report:

dotnet/roslyn#76566

[viceroypenguin]

For reference, this is the Roslyn bug report:

dotnet/roslyn#76566

I will add that it has been, at least in conversations on the discord, the public recommendation that generated code should not be run through a formatter. This is because formatting is incredibly slow and source generators should generate code quickly. As such, it is suggested that generators generate good enough code and not use formatters at all.

[Khaos66]

https://learn.microsoft.com/en-us/dotnet/api/microsoft.entityframeworkcore.infrastructure.indentedstringbuilder?view=efcore-6.0

Not sure if you want a dependency on efcore but they're using a StringBuilder that supports indentation.
I've build one myself for my own srcgens

[SteveDunn]

Thanks @Khaos66 - I'll take a look

[SteveDunn]

For reference, this is the Roslyn bug report:
dotnet/roslyn#76566

I will add that it has been, at least in conversations on the discord, the public recommendation that generated code should not be run through a formatter. This is because formatting is incredibly slow and source generators should generate code quickly. As such, it is suggested that generators generate good enough code and not use formatters at all.

Thank you. Yes, I was in two minds whether to format or not as I anticipated some performance overhead. I really need to get around to profiling Vogen as I'm sure there's areas that could be optimised.