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

[Mono.Android] Print type & member remapping info (#7844) #7847

Merged
merged 1 commit into from
Mar 2, 2023

Conversation

jonpryor
Copy link
Member

@jonpryor jonpryor commented Mar 2, 2023

Context: f6f11a5
Context: f99fc81

How do we diagnose type & member remapping issues? If (when) things don't work as anticipated, what do we do?

If a method is remapped and the remapped-to method cannot be found, then Java.Interop will write a message to stderr:

warning: For declared method `java/lang/Object.remappedToToString.()Ljava/lang/String;`, could not find requested method `java/lang/Object.toString.()Ljava/lang/String;`!

which is a scenario we think/assume Shouldn't Happen™. If it does happen, we believe that the above message will be sufficient to fix the problem.

However, in the "happy" path in which the replacement method is found or the "less-happy" path in which nothing happens, how do we get insight to check or verify what's going on?

Update AndroidTypeManager.GetStaticMethodFallbackTypesCore() and AndroidTypeManager.GetReplacementMethodInfoCore() so that they print out successful type & member remapping when the "assembly" log category is enabled:

adb shell setprop debug.mono.log default,assembly

When the assembly log category is enabled, invocations of AndroidTypeManager.GetStaticMethodFallbackTypesCore() will print messages such as the following to adb logcat:

D monodroid-assembly : Remapping type `com/xamarin/interop/RenameClassBase1` to one of { `com/xamarin/interop/DesugarRenameClassBase1`, `com/xamarin/interop/RenameClassBase1$-CC` }

When the assembly log category is enabled, invocations of AndroidTypeManager.GetReplacementMethodInfoCore() will print messages such as the following to adb logcat
when a replacement method will be attempted:

D monodroid-assembly : Remapping method `java/lang/Object.remappedToToString()Ljava/lang/String;` to `java/lang/Object.toString.()Ljava/lang/String;`; param-count: 0; instance-to-static? false

This will hopefully provide enough information to reason through type and member remapping behavior.

Additionally, as this is a cherry-pick of a983fbb to the release/7.0.2xx branch, apply a small subset of 77678eb:

updat[e] AndroidRuntime.GetStaticMethodFallbackTypesCore() to
support type remapping (f6f11a5) -- which was overlooked/not
considered -- such that the types returned are after calling
AndroidRuntime.GetReplacementTypeCore(), which looks up
<replace-type/> values. This allows us to remap
AndroidInterface to DesugarAndroidInterface$_CC, allowing the
DesugarInterfaceStaticMethod() test to pass.

Context: f6f11a5
Context: f99fc81

How do we diagnose type & member remapping issues?  If (when) things
don't work as anticipated, what do we do?

If a method is remapped *and* the remapped-to method cannot be found,
then [Java.Interop will write a message to stderr][0]:

	warning: For declared method `java/lang/Object.remappedToToString.()Ljava/lang/String;`, could not find requested method `java/lang/Object.toString.()Ljava/lang/String;`!

which is a scenario we think/assume Shouldn't Happen™.  If it *does*
happen, we believe that the above message will be sufficient to fix
the problem.

However, in the "happy" path in which the replacement method is found
*or* the "less-happy" path in which *nothing happens*, how do we get
insight to check or verify what's going on?

Update `AndroidTypeManager.GetStaticMethodFallbackTypesCore()` and
`AndroidTypeManager.GetReplacementMethodInfoCore()` so that they
print out *successful* type & member remapping when the
"assembly" log category is enabled:

	adb shell setprop debug.mono.log default,assembly

When the assembly log category is enabled, invocations of
`AndroidTypeManager.GetStaticMethodFallbackTypesCore()` will print
messages such as the following to `adb logcat`:

	D monodroid-assembly : Remapping type `com/xamarin/interop/RenameClassBase1` to one of { `com/xamarin/interop/DesugarRenameClassBase1`, `com/xamarin/interop/RenameClassBase1$-CC` }

When the assembly log category is enabled, invocations of
`AndroidTypeManager.GetReplacementMethodInfoCore()` will print
messages such as the following to `adb logcat`
*when a replacement method will be attempted*:

	D monodroid-assembly : Remapping method `java/lang/Object.remappedToToString()Ljava/lang/String;` to `java/lang/Object.toString.()Ljava/lang/String;`; param-count: 0; instance-to-static? false

This will hopefully provide enough information to reason through
type and member remapping behavior.

Additionally, as this is a cherry-pick of a983fbb to the
release/7.0.2xx branch, apply a small subset of 77678eb:

> updat[e] `AndroidRuntime.GetStaticMethodFallbackTypesCore()` to
> support type remapping (f6f11a5) -- which was overlooked/not
> considered -- such that the types returned are *after* calling
> `AndroidRuntime.GetReplacementTypeCore()`, which looks up
> `<replace-type/>` values.  This allows us to remap
> `AndroidInterface` to `DesugarAndroidInterface$_CC`, allowing the
> `DesugarInterfaceStaticMethod()` test to pass.

[0]: https://github.com/xamarin/java.interop/blob/77800dda83c2db4d90b501c00069abc9880caaeb/src/Java.Interop/Java.Interop/JniPeerMembers.JniInstanceMethods.cs#L123
@jonpryor jonpryor merged commit 0857ad1 into dotnet:release/7.0.2xx Mar 2, 2023
@github-actions github-actions bot locked and limited conversation to collaborators Jan 23, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant