Implement menu source generation

[dplochcoder]

Summary of Changes

This enables quick and easy generation of menus for classes intended to be serialized with Json, as opposed to data specified through BepInEx configuration files. It does not yet have feature parity with MenuElementFactory but it is close and I think the generated API is much nicer to use than runtime reflection. Attributes exist to plug in custom elements, sub menus, and to clamp numeric values to bounded ranges.

I don't know if the packaging set up will work with nuget; I copied stuff from https://github.com/BadMagic100/DataDrivenConstants/blob/main/DataDrivenConstants.Package/DataDrivenConstants.Package.csproj. I've also never written a Roslyn analyzer before so I probably have some stuff wrong, but it at least all works in the test project and the diagnostics seem to be working too.

Checklist

• No change is too small for a release, so pick one:
  • I have updated the package version following semantic versioning
  • There is another change actively WIP that will update the version (link issue or PR here)
  • This PR does not update user-facing code/config
  • I'm not sure how to set the version and would like the reviewer's help

[flibber-hk]

Suppose I have a menu generated with this procedure, and I want to modify the values of the underlying data object in code. What is the recommended way to do this? In HK.MC I believe the answer was to modify the menu elements directly - is the expectation here that they have to hold a reference to the generated menu and check if it exists before deciding whether to modify the data on the generated menu or on the data directly?

it may or may not be the case that the answer to this question is simply an article

[dplochcoder]

Suppose I have a menu generated with this procedure, and I want to modify the values of the underlying data object in code. What is the recommended way to do this? In HK.MC I believe the answer was to modify the menu elements directly - is the expectation here that they have to hold a reference to the generated menu and check if it exists before deciding whether to modify the data on the generated menu or on the data directly?

it may or may not be the case that the answer to this question is simply an article

I wrote an article. The answer depends on what sort of syncing behaviour your actually want between the menu and the underlying data; if the answer is "always in-sync" then you want to respond to every value change with menu.ExportTo(underlyingDataSource) and you want to follow-up every data change with menu?.ApplyFrom(underlyingDataSource). You shouldn't ever need to modify the menu element's values directly.

[BadMagic100]

I would really strongly recommend creating a roslyn test project to verify the generated sources as well.

For locally testing the nuget packaging, you can set the package version as a prerelease and build, then set up a local package source with dotnet nuget add source and then take the prerelease version as a dependency. If you don't need the extra assurance you can also just change the extension of the package to .zip and inspect the content (nuget has an online package browser you can use to compare against other packages)

[BadMagic100]

Using ForAttributeWithMetadataName is generally significantly more performant and makes for cleaner code than scanning every class declaration yourself

[BadMagic100]

Perhaps I should have been clearer, this will also give you access to the compilation and the symbol

[dplochcoder]

Something like this then?

[BadMagic100]

Few more comments, but on the whole I think this is nearly good, the roslyn tests give me more confidence that the implementation is sensible and correct

[BadMagic100]

Looks good, @flibber-hk I'll let you deal with the versioning w.r.t other prs

[flibber-hk]

I haven't reviewed the source gen stuff but approval for the rest of it (and obviously BadMagic's done a proper review of the source gen stuff)