[Mono.Android] Print type & member remapping info #7844
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. [0]: https://github.com/xamarin/java.interop/blob/77800dda83c2db4d90b501c00069abc9880caaeb/src/Java.Interop/Java.Interop/JniPeerMembers.JniInstanceMethods.cs#L123
jonathanpeppers
approved these changes
Mar 2, 2023
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
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][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
added a commit
that referenced
this pull request
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][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
grendello
added a commit
to grendello/xamarin-android
that referenced
this pull request
Mar 6, 2023
* main: Bump to dotnet/installer@632ddca 8.0.100-preview.3.23128.1 (dotnet#7836) LEGO: Merge pull request 7852 [ci] Reduce overhead for MSBuildIntegration unit test jobs. (dotnet#7832) [ci] Allow dynamic`$(NuGetArtifactName)` values (dotnet#7848) [Xamarin.Android.Build.Tasks] guard `AutoImport.props` against empty values (dotnet#7837) [Mono.Android] Print type & member remapping info (dotnet#7844) [Mono.Android] Tweak AndroidMessageHandler behavior for WCF support (dotnet#7785) LEGO: Merge pull request 7845 Localized file check-in by OneLocBuild Task (dotnet#7842) [ci] Use compliance stage template (dotnet#7818) [build] pass `--skip-sign-check` to `dotnet workload` (dotnet#7840)
grendello
added a commit
to grendello/xamarin-android
that referenced
this pull request
Mar 6, 2023
* main: Bump to dotnet/installer@632ddca 8.0.100-preview.3.23128.1 (dotnet#7836) LEGO: Merge pull request 7852 [ci] Reduce overhead for MSBuildIntegration unit test jobs. (dotnet#7832) [ci] Allow dynamic`$(NuGetArtifactName)` values (dotnet#7848) [Xamarin.Android.Build.Tasks] guard `AutoImport.props` against empty values (dotnet#7837) [Mono.Android] Print type & member remapping info (dotnet#7844) [Mono.Android] Tweak AndroidMessageHandler behavior for WCF support (dotnet#7785) LEGO: Merge pull request 7845 Localized file check-in by OneLocBuild Task (dotnet#7842) [ci] Use compliance stage template (dotnet#7818) [build] pass `--skip-sign-check` to `dotnet workload` (dotnet#7840) Replace K4os.Hash.xxHash with System.IO.Hashing (dotnet#7831) $(AndroidPackVersionSuffix)=preview.3; net8 is 34.0.0-preview.3 (dotnet#7839)
grendello
added a commit
to grendello/xamarin-android
that referenced
this pull request
Mar 6, 2023
* main: (22 commits) Bump to dotnet/installer@632ddca 8.0.100-preview.3.23128.1 (dotnet#7836) LEGO: Merge pull request 7852 [ci] Reduce overhead for MSBuildIntegration unit test jobs. (dotnet#7832) [ci] Allow dynamic`$(NuGetArtifactName)` values (dotnet#7848) [Xamarin.Android.Build.Tasks] guard `AutoImport.props` against empty values (dotnet#7837) [Mono.Android] Print type & member remapping info (dotnet#7844) [Mono.Android] Tweak AndroidMessageHandler behavior for WCF support (dotnet#7785) LEGO: Merge pull request 7845 Localized file check-in by OneLocBuild Task (dotnet#7842) [ci] Use compliance stage template (dotnet#7818) [build] pass `--skip-sign-check` to `dotnet workload` (dotnet#7840) Replace K4os.Hash.xxHash with System.IO.Hashing (dotnet#7831) $(AndroidPackVersionSuffix)=preview.3; net8 is 34.0.0-preview.3 (dotnet#7839) [Xamarin.Android.Build.Tasks] Remove support for mkbundle (dotnet#7772) [Xamarin.Android.Build.Tasks] `unable to open file as zip archive`? (dotnet#7759) [monodroid] Properly process satellite assemblies (dotnet#7823) Bump to xamarin/java.interop/main@77800dda (dotnet#7824) [ci] Use AZDO built-in parallelization strategy. (dotnet#7804) Bump to dotnet/installer@e3ab0b5 8.0.100-preview.2.23123.10 (dotnet#7813) [ci] Run nunit tests with stable .NET version (dotnet#7826) ...
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
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.
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:
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()andAndroidTypeManager.GetReplacementMethodInfoCore()so that they print out successful type & member remapping when the "assembly" log category is enabled:When the assembly log category is enabled, invocations of
AndroidTypeManager.GetStaticMethodFallbackTypesCore()will print messages such as the following toadb logcat:When the assembly log category is enabled, invocations of
AndroidTypeManager.GetReplacementMethodInfoCore()will print messages such as the following toadb logcatwhen a replacement method will be attempted:
This will hopefully provide enough information to reason through type and member remapping behavior.