-
Notifications
You must be signed in to change notification settings - Fork 538
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Bump mono to 5.4.0.0 #631
Bump mono to 5.4.0.0 #631
Conversation
It would seem that the linker code doesn't like you:
...plus 8 other similar errors. |
This PR also needs to change |
…returns a Dictionary (#152) This is needed as part of [bumping xamarin-android to use mono/2017-06][0], to fix the following compilation error: Tasks/LinkAssemblies.cs(103,41): error CS1503: Argument 1: cannot convert from 'System.Collections.IDictionary' to 'System.Collections.Generic.Dictionary<string, Mono.Cecil.AssemblyDefinition>' [0]: dotnet/android#631
Updated reference to mono Fixed target branch for mono
linux build fails with:
@jonpryor how would I fix that? |
@lewurm wrote:
Talk with @directhex about getting an updated mono for Linux. |
build |
1 similar comment
build |
(working on it, ought to be up by mid weekend) |
FYI, the previously investigated unit test failures/etc. will continue to fail until PR #662 is merged. |
as a reference, #662 should (probably?) fix https://bugzilla.xamarin.com/show_bug.cgi?id=57828 |
Context: dotnet/android#723 [`corefx` removed ``Dictionary`2.GetValueOrDefault()``][cfx17275] in favor of using extension methods of the same name within `System.Collections.Generic.CollectionExtensions`, and mono/2017-06 is using the updated corefx sources. [cfx17275]: https://github.com/dotnet/corefx/issues/17275#issuecomment-291636863 @marek-safar [deems this as not a breaking change][1]: [1]: dotnet/android#631 (comment) > It breaks at binary compatibility level but not sure we made such strong promise. Update `reference/mscorlib.xml` to be consistent with mono/2017-06. Additionally, synchronize `reference/Mono.Security.xml` with mono/2017-06. We don't consider `Mono.Security.dll` to be part of our stable API.
I suspect that the current set of unit test failures, e.g.
is actually due to Bug #56436, as As such, these tests may be fixed once PR #732 is merged. |
yay: nay:
|
context: https://bugzilla.xamarin.com/show_bug.cgi?id=57828 this commit should be reverted.
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=57828 The #runtime team is attempting to update xamarin-android to use the [mono/2017-06][0] and [mono/2017-08][1] (and...) branches, and when doing so they are seeing a unit test fail in `Xamarin.Android.Build.Tests.BuildTest.GeneratorValidateMultiMethodEventName()`: no `BG850*` warnings are expected but they are produced. After much analysis, the cause of ght `BG850*` warnings is that the mono/2017-06 branch introduces a non-generic "overload" of `System.Collections.Generic.KeyValuePair`: namespace System.Collections.Generic { // New with mono/2017-06 partial class KeyValuePair { public static KeyValuePair<TKey, TValue> Create<TKey, TValue>(TKey key, TValue value); } // Existing since forever partial struct KeyValuePair<TKey, TValue> { } } Specifically, the above "`KeyValuePair` overload" type runs into a FIXME within `CodeGenerator.cs`: // FIXME: at some stage we want to import generic types. // For now generator fails to load generic types that have conflicting type e.g. // AdapterView`1 and AdapterView cannot co-exist. // It is mostly because generator primarily targets jar (no real generics land). The problem is that the check that is performed is too strict: given a type `AdapterView<T>`, we only check to see if `AdapterView` exists as well. If it does exist, then we *ignore* the `AdapterView<T>` type, and only use the `AdapterView` type for code generation. This check causes us to skip type registration for `KeyValuePair<TKey, TValue>`, which in turn causes us to invalidate e.g. `IDictionary<TKey, TValue>` -- as it implements `ICollection<KeyValuePair<TKey, TValue>>` -- and everything promply falls apart from there: warning BG8C00: For type System.Collections.Generic.IDictionary`2, base interface System.Collections.Generic.ICollection`1<System.Collections.Generic.KeyValuePair`2<TKey,TValue>> is invalid. warning BG8C00: For type System.Collections.Generic.IDictionary`2, base interface System.Collections.Generic.IEnumerable`1<System.Collections.Generic.KeyValuePair`2<TKey,TValue>> is invalid. warning BG8502: Invalidating System.Collections.Generic.IDictionary`2 and all nested types because some of its interfaces were invalid. warning BG8801: Invalid parameter type System.Collections.Generic.IDictionary`2<System.String,System.Collections.Generic.IList`1<System.String>> in method MapEquivalents in managed type Java.Util.Locale.LanguageRange. warning BG8801: Invalid parameter type System.Collections.Generic.IDictionary`2<System.String,System.Collections.Generic.IList`1<System.String>> in method Parse in managed type Java.Util.Locale.LanguageRange. warning BG8801: Invalid parameter type System.Collections.Generic.IDictionary`2<System.String,System.Object> in method NewFileSystem in managed type Java.Nio.FileNio.Spi.FileSystemProvider. warning BG8801: Invalid parameter type System.Collections.Generic.IDictionary`2<System.String,System.Object> in method NewFileSystem in managed type Java.Nio.FileNio.Spi.FileSystemProvider. warning BG8801: Invalid parameter type System.Collections.Generic.IDictionary`2<System.String,System.String> in method .ctor in managed type Java.Security.Provider.Service. warning BG8801: Invalid parameter type System.Collections.Generic.IDictionary`2<System.Object,System.Object> in method PutAll in managed type Java.Security.Provider. I still don't fully understand the scenario that the check was attempting to solve, so in lieu of actually fixing the FIXME, make the check *stricter* so that we only ignore "generically overloaded" types if they bind the *same* Java type. Since `KeyValuePair<TKey, TValue>` binds *no* Java type, it will no longer be skipped, thus removing the BG8502 and related warnings. Additionally, a bit of code cleanup for consistency: some parts of the code use `HAVE_CECIL`, and others use `USE_CECIL`. Standardize on `HAVE_CECIL` for consistency and sanity. [0]: dotnet/android#631 [1]: dotnet/android#723
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=57828 The #runtime team is attempting to update xamarin-android to use the [mono/2017-06][0] and [mono/2017-08][1] (and...) branches, and when doing so they are seeing a unit test fail in `Xamarin.Android.Build.Tests.BuildTest.GeneratorValidateMultiMethodEventName()`: no `BG850*` warnings are expected but they are produced. After much analysis, the cause of ght `BG850*` warnings is that the mono/2017-06 branch introduces a non-generic "overload" of `System.Collections.Generic.KeyValuePair`: namespace System.Collections.Generic { // New with mono/2017-06 partial class KeyValuePair { public static KeyValuePair<TKey, TValue> Create<TKey, TValue>(TKey key, TValue value); } // Existing since forever partial struct KeyValuePair<TKey, TValue> { } } Specifically, the above "`KeyValuePair` overload" type runs into a FIXME within `CodeGenerator.cs`: // FIXME: at some stage we want to import generic types. // For now generator fails to load generic types that have conflicting type e.g. // AdapterView`1 and AdapterView cannot co-exist. // It is mostly because generator primarily targets jar (no real generics land). The *intent* of the check that is that, given a type `AdapterView<T>`, we only check to see if `AdapterView` exists as well. If it does exist, then we *ignore* the `AdapterView<T>` type, and only use the `AdapterView` type for code generation. In the case of `KeyValuePair`, the same "check" is done, which cause us to *skip* type registration for `KeyValuePair<TKey, TValue>`, which in turn causes us to invalidate e.g. `IDictionary<TKey, TValue>` -- as it implements `ICollection<KeyValuePair<TKey, TValue>>` -- and everything promply falls apart from there: warning BG8C00: For type System.Collections.Generic.IDictionary`2, base interface System.Collections.Generic.ICollection`1<System.Collections.Generic.KeyValuePair`2<TKey,TValue>> is invalid. warning BG8C00: For type System.Collections.Generic.IDictionary`2, base interface System.Collections.Generic.IEnumerable`1<System.Collections.Generic.KeyValuePair`2<TKey,TValue>> is invalid. warning BG8502: Invalidating System.Collections.Generic.IDictionary`2 and all nested types because some of its interfaces were invalid. warning BG8801: Invalid parameter type System.Collections.Generic.IDictionary`2<System.String,System.Collections.Generic.IList`1<System.String>> in method MapEquivalents in managed type Java.Util.Locale.LanguageRange. warning BG8801: Invalid parameter type System.Collections.Generic.IDictionary`2<System.String,System.Collections.Generic.IList`1<System.String>> in method Parse in managed type Java.Util.Locale.LanguageRange. warning BG8801: Invalid parameter type System.Collections.Generic.IDictionary`2<System.String,System.Object> in method NewFileSystem in managed type Java.Nio.FileNio.Spi.FileSystemProvider. warning BG8801: Invalid parameter type System.Collections.Generic.IDictionary`2<System.String,System.Object> in method NewFileSystem in managed type Java.Nio.FileNio.Spi.FileSystemProvider. warning BG8801: Invalid parameter type System.Collections.Generic.IDictionary`2<System.String,System.String> in method .ctor in managed type Java.Security.Provider.Service. warning BG8801: Invalid parameter type System.Collections.Generic.IDictionary`2<System.Object,System.Object> in method PutAll in managed type Java.Security.Provider. I still don't fully understand the scenario that the check was attempting to solve, so in lieu of actually fixing the FIXME, make the check *stricter* so that we only ignore "generically overloaded" types if they bind the *same* Java type. Since `KeyValuePair<TKey, TValue>` binds *no* Java type, it will no longer be skipped, thus removing the BG8502 and related warnings. Additionally, a bit of code cleanup for consistency: some parts of the code use `HAVE_CECIL`, and others use `USE_CECIL`. Standardize on `HAVE_CECIL` for consistency and sanity. [0]: dotnet/android#631 [1]: dotnet/android#723
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=57828 The #runtime team is attempting to update xamarin-android to use the [mono/2017-06][0] and [mono/2017-08][1] (and...) branches, and when doing so they are seeing a unit test fail in `Xamarin.Android.Build.Tests.BuildTest.GeneratorValidateMultiMethodEventName()`: no `BG850*` warnings are expected but they are produced. After much analysis, the cause of ght `BG850*` warnings is that the mono/2017-06 branch introduces a non-generic "overload" of `System.Collections.Generic.KeyValuePair`: namespace System.Collections.Generic { // New with mono/2017-06 partial class KeyValuePair { public static KeyValuePair<TKey, TValue> Create<TKey, TValue>(TKey key, TValue value); } // Existing since forever partial struct KeyValuePair<TKey, TValue> { } } Specifically, the above "`KeyValuePair` overload" type runs into a FIXME within `CodeGenerator.cs`: // FIXME: at some stage we want to import generic types. // For now generator fails to load generic types that have conflicting type e.g. // AdapterView`1 and AdapterView cannot co-exist. // It is mostly because generator primarily targets jar (no real generics land). The *intent* of the check that is that, given a type `AdapterView<T>`, we only check to see if `AdapterView` exists as well. If it does exist, then we *ignore* the `AdapterView<T>` type, and only use the `AdapterView` type for code generation. In the case of `KeyValuePair`, the same "check" is done, which cause us to *skip* type registration for `KeyValuePair<TKey, TValue>`, which in turn causes us to invalidate e.g. `IDictionary<TKey, TValue>` -- as it implements `ICollection<KeyValuePair<TKey, TValue>>` -- and everything promply falls apart from there: warning BG8C00: For type System.Collections.Generic.IDictionary`2, base interface System.Collections.Generic.ICollection`1<System.Collections.Generic.KeyValuePair`2<TKey,TValue>> is invalid. warning BG8C00: For type System.Collections.Generic.IDictionary`2, base interface System.Collections.Generic.IEnumerable`1<System.Collections.Generic.KeyValuePair`2<TKey,TValue>> is invalid. warning BG8502: Invalidating System.Collections.Generic.IDictionary`2 and all nested types because some of its interfaces were invalid. warning BG8801: Invalid parameter type System.Collections.Generic.IDictionary`2<System.String,System.Collections.Generic.IList`1<System.String>> in method MapEquivalents in managed type Java.Util.Locale.LanguageRange. warning BG8801: Invalid parameter type System.Collections.Generic.IDictionary`2<System.String,System.Collections.Generic.IList`1<System.String>> in method Parse in managed type Java.Util.Locale.LanguageRange. warning BG8801: Invalid parameter type System.Collections.Generic.IDictionary`2<System.String,System.Object> in method NewFileSystem in managed type Java.Nio.FileNio.Spi.FileSystemProvider. warning BG8801: Invalid parameter type System.Collections.Generic.IDictionary`2<System.String,System.Object> in method NewFileSystem in managed type Java.Nio.FileNio.Spi.FileSystemProvider. warning BG8801: Invalid parameter type System.Collections.Generic.IDictionary`2<System.String,System.String> in method .ctor in managed type Java.Security.Provider.Service. warning BG8801: Invalid parameter type System.Collections.Generic.IDictionary`2<System.Object,System.Object> in method PutAll in managed type Java.Security.Provider. I still don't fully understand the scenario that the check was attempting to solve, so in lieu of actually fixing the FIXME, make the check *stricter* so that we only ignore "generically overloaded" types if they bind the *same* Java type. Since `KeyValuePair<TKey, TValue>` binds *no* Java type, it will no longer be skipped, thus removing the BG8502 and related warnings. Additionally, a bit of code cleanup for consistency: some parts of the code use `HAVE_CECIL`, and others use `USE_CECIL`. Standardize on `HAVE_CECIL` for consistency and sanity. [0]: dotnet/android#631 [1]: dotnet/android#723
build for 52097a1 is green!!! 🙂 |
This reverts commit 460b62a.
cc @jonpryor