[generator-Tests] Provide more context when errors happen #48
Conversation
This file contains 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
A unit test failure is being reported, which unfortunately doesn't contain enough useful context: 1) generatortests.NormalMethods.GeneratedOK : error : .../Java.Interop/bin/TestDebug/SupportFiles/JavaObject.cs(78,17): (Location of the symbol related to previous warning) Expected: 0 But was: 1 It's a very odd "error", in that there's no error reported, just a mention of a "previous warning", which isn't shown. The *cause* of this useless output is that `Compiler` "trims out" all the "non-error" output from the compilation. This *seems* good, except in this case it's the "useless output" that we need to make sense of anything at all! Revise `Compiler.Compile()` so that instead of extracting "errors" it instead provides *all* compiler output and an indicator of whether or not errors occurred. (This still depends on `CompilerResults.Errors` having correct output -- and I'm starting to wonder if I'm actually dealing with a CodeDom bug here -- but at least with more output I can better rationalize about what's going on.)
radekdoulik
added a commit
to radekdoulik/java.interop
that referenced
this pull request
Aug 27, 2018
Changes in xamarin-android-tools between 75530565b6aa903b3a0e52b61df4dd94475a19fc and 9e78d6ee586b498d0ea082b3bc00432c23583dd1: 9e78d6e (HEAD, origin/master, origin/HEAD, master) [tests] fix test failures on Windows (dotnet#47) bdf0158 Better support no installed JDKs on macOS (dotnet#48) 6353659 Log what is happening during path selection (dotnet#46) 3ef860b Take BUILD_NUMBER into consideration for Version sorting (dotnet#45) d3de054 Allow an optional locator to be provided to JdkInfo (dotnet#43) 917d3b3 Don't require quotes around `release` values (dotnet#41) 7427692 [tests] Unit tests for finding NDK location based on $PATH (dotnet#40) dbc517b Merge pull request dotnet#38 from jonpryor/jonp-ndk-via-path 511d580 Allow finding NDK location based on $PATH b42c217 [tests] Fix DetectAndSetPreferredJavaSdkPathToLatest() test (dotnet#37) a4aad18 Add AndroidSdkInfo.DetectAndSetPreferredJavaSdkPathToLatest() (dotnet#35) fae7e0a [tests] Remove temporary directories (dotnet#36) 07c4c2b [Xamarin.Android.Tools.AndroidSdk] Revert JDK validation (dotnet#34)
radekdoulik
added a commit
that referenced
this pull request
Aug 27, 2018
Changes in xamarin-android-tools between 75530565b6aa903b3a0e52b61df4dd94475a19fc and 9e78d6ee586b498d0ea082b3bc00432c23583dd1: 9e78d6e (HEAD, origin/master, origin/HEAD, master) [tests] fix test failures on Windows (#47) bdf0158 Better support no installed JDKs on macOS (#48) 6353659 Log what is happening during path selection (#46) 3ef860b Take BUILD_NUMBER into consideration for Version sorting (#45) d3de054 Allow an optional locator to be provided to JdkInfo (#43) 917d3b3 Don't require quotes around `release` values (#41) 7427692 [tests] Unit tests for finding NDK location based on $PATH (#40) dbc517b Merge pull request #38 from jonpryor/jonp-ndk-via-path 511d580 Allow finding NDK location based on $PATH b42c217 [tests] Fix DetectAndSetPreferredJavaSdkPathToLatest() test (#37) a4aad18 Add AndroidSdkInfo.DetectAndSetPreferredJavaSdkPathToLatest() (#35) fae7e0a [tests] Remove temporary directories (#36) 07c4c2b [Xamarin.Android.Tools.AndroidSdk] Revert JDK validation (#34)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
A unit test failure is being reported, which unfortunately doesn't
contain enough useful context:
It's a very odd "error", in that there's no error reported, just a
mention of a "previous warning", which isn't shown.
The cause of this useless output is that
Compiler"trims out" allthe "non-error" output from the compilation. This seems good, except
in this case it's the "useless output" that we need to make sense of
anything at all!
Revise
Compiler.Compile()so that instead of extracting "errors" itinstead provides all compiler output and an indicator of whether or
not errors occurred. (This still depends on
CompilerResults.Errorshaving correct output -- and I'm starting to wonder if I'm actually
dealing with a CodeDom bug here -- but at least with more output I can
better rationalize about what's going on.)