Skip to content
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

C#: Move GodotSharp to .NET8 #92131

Merged
merged 2 commits into from
Dec 13, 2024
Merged

C#: Move GodotSharp to .NET8 #92131

merged 2 commits into from
Dec 13, 2024

Conversation

paulloz
Copy link
Member

@paulloz paulloz commented May 19, 2024

This is to prepare the EOS of .NET6 in November.

Would need to be more thoroughly tested. There are probably a bunch of other spots where we could mark things as scoped.

@paulloz paulloz added this to the 4.4 milestone May 19, 2024
@Delsin-Yu
Copy link
Contributor

As we are upgrading the SDK version, should the end of support for Windows 7 and 8.1 on .Net 8 be documented?

Copy link
Member

@raulsntos raulsntos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you again for doing all this work!

This is only a partial review, I still have to review the massive scoped changes but I thought it'd be better to comment on the parts I've already reviewed than to keep you waiting until I'm done with everything.


namespace Godot.SourceGenerators.Tests;

public static class Constants
{
public static Assembly GodotSharpAssembly => typeof(GodotObject).Assembly;

// Can't find what needs updating to be able to access ReferenceAssemblies.Net.Net80, so we're making our own one.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this can stay like this for now, I guess. Do you want me to update the comment?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Version 1.1.2 of Microsoft.CodeAnalysis.Analyzer.Testing has been released which should contain Net80.

modules/mono/glue/GodotSharp/GodotSharp/Core/Array.cs Outdated Show resolved Hide resolved
<ItemGroup>
<PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="3.10.0" PrivateAssets="all" />
<PackageReference Include="Microsoft.CodeAnalysis.Analyzers" Version="3.3.3" PrivateAssets="all" />
<PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="4.9.2" PrivateAssets="all" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This bumps the minimum supported Visual Studio version to Visual Studio 2022 version 17.9. I think it's fine since .NET 8.0 is only officially supported in Visual Studio 17.8+ anyway, but I wanted to mention it for the record.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll double check this is necessary, it might come from me struggling to find the reference assembly and updating packages like a maniac x)

modules/mono/glue/GodotSharp/GodotSharp/Core/Dictionary.cs Outdated Show resolved Hide resolved
modules/mono/glue/GodotSharp/GodotSharp/Core/Dictionary.cs Outdated Show resolved Hide resolved
Comment on lines +399 to +403
(RefKind.Out, _) => source.Append("out"),
(RefKind.In, ScopedKind.ScopedRef) => source.Append("scoped in"),
(RefKind.In, _) => source.Append("in"),
(RefKind.Ref, ScopedKind.ScopedRef) => source.Append("scoped ref"),
(RefKind.Ref, _) => source.Append("ref"),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of basically duplicating every entry in the switch, why not append the scoped keyword before the switch?

Also, this only handles ScopedRef but not ScopedValue. Although I guess there are no such cases in our partial method declarations.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kinda like this syntax because it visually lays out all the possibilities. But I can rewrite this if it feels too weird.

@@ -172,7 +172,7 @@ void AppendPartialContainingTypeDeclarations(INamedTypeSymbol? containingType)
{
var parameter = callback.Parameters[i];

AppendRefKind(source, parameter.RefKind);
AppendRefKind(source, parameter.RefKind, parameter.ScopedKind);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if using the scoped keyword makes sense for these interop methods. Isn't it a lie? Once we cross to the C++ side, there's nothing stopping these values from escaping the scope and C# would not be aware at all.

Because of ref safety changes in the languages, all methods that return an interop struct have to have all other reference parameters marked as scoped to signal the the method does not capture that reference.

The variant change is necessary, because for some reason a type of the exact shape godot_variant is in, crashes the .NET 7 JIT, but when changing it to be sequential with the same effective layout it works.
@paulloz paulloz marked this pull request as ready for review December 12, 2024 18:15
@paulloz paulloz requested review from a team as code owners December 12, 2024 18:15
@paulloz
Copy link
Member Author

paulloz commented Dec 12, 2024

Rebased and up to date. There are a few new places I'm not sure whether we should use scoped or not (e.g. new NativeFuncs methods introduced in #98545). But otherwise it should be good to test.

Copy link
Member

@raulsntos raulsntos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've taken another look at the changes and tested them again. Everything looks great and seems to be working as expected.

I think it's good to merge now, and we can get some extra testing before the stable release. We can always improve upon this with subsequent PRs.

Thank you so much for your hard work and patience in seeing this through.

@paulloz
Copy link
Member Author

paulloz commented Dec 13, 2024

I forgot to squash commits. Is it fine to keep two separate commits here? I don't want to erase the large contribution of the previous PR.

@akien-mga
Copy link
Member

akien-mga commented Dec 13, 2024

Yeah keeping two separate commits seems fine to me.

Note that there are a number of C# warnings raised by the CI in a non-obvious way: they're visible if you view the last commit and scroll all the way down:

1c7ecfb

I don't see those on other PRs so they must be introduced by this change, and should ideally be fixed now otherwise all future PRs (even non C# related) will have these warnings.

- Change TFM and LangVersion
- Better exception throwing (CA1510, CA1512, CA1513)
- Better exception utility method definition (CA1859)
- Prefer comparing `.Count` over calling `.Any()` (CA1860)
- Prefer `.AsSpan()` over `.Substring()` (CA1846)
- Add a few more `scoped`
- Use `RuntimeHelpers.GetUninitializedObject()` instead of `FormatterServices.GetUninitializedObject()`
- Use delegate instead of delegate pointer in variant generic conversions
- Enable EnforceExtendedAnalyzerRules in source generator projects
- Disable CS8981 on structs named movable in Godot.NativeInterop
@paulloz
Copy link
Member Author

paulloz commented Dec 13, 2024

Good catch, thank you. Those are warning introduced in waves 6 and up.

@akien-mga akien-mga merged commit 7f5c469 into godotengine:master Dec 13, 2024
20 checks passed
@akien-mga
Copy link
Member

Great work @paulloz and @RedworkDE!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants