Detect nullable marker parameters in constructor arguments. #2773
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This draft seeks to introduce a
nullableMarker
flag to theParameter
abstraction. If set, it is safe skip andnull
the parameter value right away.The
PreferredConstructorDiscoverer
for Kotlin will use this flag when detecting aDefaultConstructorMarker
argument within the java constructor which is there (as the name indicates) to solely mark the constructor to use but does not map to any parameter from the source Kotlin type, resulting in an unresolvable parameter name/target property for the parameter.This change will allow the
ClassGeneratingEntityInstantiator
to operate types using Kotlin inline classes.I think it would also make sense to discuss if the usage of the newly introduced method makes sense in the
ParameterValueProvider
implementations likePersistentEntityParameterValueProvider
to shortcut the value lookup by simply returningnull
Closes: #1947