Description

This PR evaluates the approach of relying on Roslyn source generators to generate code for auto-registration of extendible Input System types. Existing auto-registration code has been raised as problematic since it drives memory usage and generates run-time overhead.

Completed issues:

• Add a Roslyn source generators to Input System that detect and generate source code to register interaction, processor and binding composite type registrations for user-defined types.
• Make sure Roslyn source generators have automated-test coverage to avoid regressions or unexpected behaviour.
• Document how to build and test the source generator project.
• Moved enabling Project-wide input actions out ofSubsystemInitialization hook (Input System initialisation) toBeforeSceneLoad hook (directly after initial update), to allow type registration to happen as part of initialisation hooks prior toBeforeSceneLoad but afterSubsystemInitialization, e.g.AssembliesLoaded orBeforeSplashScreen. This allows actions to resolve since devices are known from initial update and custom type registrations have a chance of executing before enabling project-wide-input-actions.

Open issues:

• Investigate why changes to initialisation order works in practise but not withInputTestFixture.
• Add an analyser and add a diagnostic warning message that suggests to users that implicit automatic registration is deprecated and will be removed in a future version. Provide suggestion to explicitly allow auto-registration via tag types. This converts source generated registration into an optional opt-in without directly breaking this behaviour which allows users to migrate. This way both manual (recommended) and auto-registration can work in parallel with minimal overhead when tag types aren't used.
• A/B test differences to compile time and/or memory usage.

Testing status & QA

Please describe the testing already done by you and what testing you request/recommend QA to execute. If you used or created any testing project please link them here too for QA.

Overall Product Risks

Please rate the potential complexity and halo effect from low to high for the reviewers. Note down potential risks to specific Editor branches if any.

• Complexity:
• Halo Effect:

Comments to reviewers

Please describe any additional information such as what to focus on, or historical info for the reviewers.

Checklist

Before review:

• Changelog entry added.
  • Explains the change inChanged,Fixed,Added sections.
  • For API change contains an example snippet and/or migration example.
  • JIRA ticket linked, example (case %%). If it is a private issue, just add the case ID without a link.
  • Jira port for the next release set as "Resolved".
• Tests added/changed, if applicable.
  • Functional testsArea_CanDoX,Area_CanDoX_EvenIfYIsTheCase,Area_WhenIDoX_AndYHappens_ThisIsTheResult.
  • Performance tests.
  • Integration tests.
• Docs for new/changed API's.
  • Xmldoc cross references are set correctly.
  • Added explanation how the API works.
  • Usage code examples added.
  • The manual is updated, if needed.

During merge:

• Commit message for squash-merge is prefixed with one of the list:
  • NEW: ___.
  • FIX: ___.
  • DOCS: ___.
  • CHANGE: ___.
  • RELEASE: 1.1.0-preview.3.