On at least one of my devices I get MACaptionAppearanceDisplayType.AlwaysOn,
while the locale is 'en'.
So just allow all valid enum values for the return type.
When we process P/Invokes to add support for exception marshaling, we may
change P/Invokes to be __Internal. This means that we need to move the check
for __Internal P/Invokes to after processing P/Invokes for exception
marshaling.
https://bugzilla.xamarin.com/show_bug.cgi?id=57833
Previously the assumption was that if an assembly not using dlsym references a
native symbol, it's not a required symbol. This is true as far as the native
linker goes: the native linker will see that the native symbol is referenced
by the AOT-compiled code, and it won't be removed.
However, we use also this exact logic to create the list of functions we ask
the native strip command to preserve, and in this case we need to include all
symbols needed in all assemblies that looks up native functions using dlsym.
https://bugzilla.xamarin.com/show_bug.cgi?id=57826
Some Quote implementations quoted backslashes, some didn't. When selecting a
common implementation, one of the implementations that didn't quote
backslashes won, and the rest were forgotten. Almost. Except for the MT0106
test, which started failing, thus exposing the winner's deficiencies.
So dethrone the implementation that won and reinstante the importance of the
backslash.
https://bugzilla.xamarin.com/show_bug.cgi?id=57768
* [registrar] BindAs uses Nullable types so allow them to be registered as NSObjects
BindAsAttribute allows to bind NSValue and NSNumber into more
accurate C# types lyke bool?, int? etc. so we must teach registrar
about this.
* [tests][introspection] Teach intro about BindAs and Nullable types
Introspection will currently fail if BindAs is used, introspection
will report that the incorrect type is registered so we need to skip
this check if Nullable type is found in the signature
* [introspection] Add better type checking instead of totally skipping the type when Nullable type is encountered
Introspection will currently fail if BindAs is used. Introspection
will report that the incorrect type is registered so we need verify
if a Nullable type is found in the signature and check against of
a withelist of BindAs supported types
* Revert "[registrar] BindAs uses Nullable types so allow them to be registered as NSObjects"
This reverts commit 911eab97b7.
* [tests] Add comment about where to find BindAs types
Very occasionally this may happen:
/bin/sh: /Users/builder/data/lanes/5024/08614af6/source/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/Frameworks/Xamarin-debug.framework/Info.plist: No such file or directory
make[4]: *** [/Users/builder/data/lanes/5024/08614af6/source/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/Frameworks/Xamarin-debug.framework/Info.plist] Error 1
which is fixed by using the right dependencies for the Info.plist target.
This was due to an integer overflow. The original value was based on Int32
1 << 40 == 256
The correct value should be based on a UInt64.
1UL << 40 == 1099511627776
HFS normalizes filenames to Form D when files are stored. This means that an
assembly whose assembly name is stored in Form C might be stored in a file
whose filename is Form D (which you'll get if you use the Form C filename).
However, this is a problem when we've already loaded an assembly and if we
doesn't take normalization into account: we check the cache based on the
filename, but store in the cache based on the assembly name. If those two uses
different normalization schemes, bad things (bug #57266) happen.
So in these scenarios normalize strings before comparing them.
https://bugzilla.xamarin.com/show_bug.cgi?id=57266
This allows things to work on both xbuild and msbuild.
In xbuild, both lists are exactly the same and on msbuild,
only @(ReferencePath) exists.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=55147
Rolf Kvinge [8:59 AM]
@dalexsoto the fix is to not strip the executable please PR that
(it should probably go into master as well). This probably started
happening when Jeff implemented support for stripping debug builds
(previously the setting was ignored)
* [Foundation] Set 'sentRequest' when sending a request in NSUrlSessionHandler.
Fixes this compiler warning:
> [..]/external/mono/mcs/class/System.Net.Http/HttpClientEx.cs(50,8): warning CS0649: Field `Foundation.NSUrlSessionHandler.sentRequest' is never assigned to, and will always have its default value `false'
However it changes the runtime behavior, and we'll now throw an exception in
cases that we accepted before:
* `sentRequest` is only read in `EnsureModifiability ()`, which throws an
exception if `sentRequest` is true.
* Previously `sentRequest` was never set (thus the compiler warning), which
meant `EnsureModifiability` would never throw an exception.
* Looking at the similar `CFNetworkHandler` (which has the identical field and
methods), it seems that the intended behavior is to set `sentRequest` in
`SendAsync`, and then `EnsureModifiability` is called whenever a property is
set to ensure the property isn't set too late (and any change would be
ignored because the request was already sent).
* This means that previously setting any property after the request was sent
would not throw any exceptions (even though the change would be ignored),
while with this change we'd start throwing exceptions.
* Add missing tests for the setRequest var.
* Redesign tests to make sure that all handlers run the same code.
* Fix failing test.
* Add the managed handler to the HttpClient tests.
* Fix minor style issues.
* [mtouch] Improve how we make sure native symbols aren't stripped away. Fixes#51710 and #54417.
* Refactor required symbol collection to store more information about each
symbol (field, function, Objective-C class), and in general make the code
more straight forward.
* Implement support for generating source code that references these symbols,
and do this whenever we can't ask the native linker to keep these symbols
(when using bitcode). Additionally make it possible to do this manually, so
that the source code can be generated for non-bitcode platforms too (which
is useful if the number of symbols is enormous, in which case we might
surpass the maximum command-line length).
* Also make it possible to completely ignore native symbols, or ignore them on
a per-symbol basis. This provides a fallback for users if we get something
right and we try to preserve something that shouldn't be preserved (for
instance if it doesn't exist), and the user ends up with unfixable linker
errors.
* Don't collect Objective-C classes unless they're in an assembly with
LinkWith attributes. We don't need to preserve Objective-C classes in any
other circumstances.
* Implement everything for both Xamarin.iOS and Xamarin.Mac, and share the
code between them.
* Remove previous workaround for bug #51710, since it's no longer needed.
* Add tests.
https://bugzilla.xamarin.com/show_bug.cgi?id=54417https://bugzilla.xamarin.com/show_bug.cgi?id=51710
* [mtouch] Make sure to only keep symbols from the current app when code sharing.
This fixes a build problem with the interdependent-binding-projects test when
testing in Today Extension mode.
We already create dSYMs for Mono.framework when apps are built, but this will
now become redundant and removed at a later stage. This will make app builds
slightly faster (yay) at the cost of a somewhat bigger XI package (and our
build will be equivalently slower).
We never created dSYMs for libmonosgen-2.0.dylib, which means that anybody
symbolicating crash reports will now get file name and line number information
in stack traces (it also makes debugging using lldb possible).
* [registrar] Detect more invalid characters in selectors so that we can report better errors. Fixes#55568.
https://bugzilla.xamarin.com/show_bug.cgi?id=55568
* [mtouch] Add a few comments about duplicated data between mtouch and tests.
In 11390f119c we stopped setting the force flag
when the cache was invalid, because we'd delete the cache anyway, and it was
determined that deleting the cache was enough.
Unfortunately it's not, because some output is not in the cache, and might not
get correctly updated.
Scenario:
* User builds app.
* User changes some build option (for instance switching off incremental
builds).
* User does an insignificant change in a source file for the executable
process.
* User builds app again (without cleaning). This will rebuild the exe, but
since the change was insignificant, all the IL, except the MVID, would
remain identical.
* mtouch would see that the command-line options changed, and invalidate the
cache. This would delete the cache, and everything would be rebuilt,
including AOT-compiling the assemblies again.
* When the time came for mtouch to copy assemblies to the app directory,
mtouch would realize that the existing .exe in the app (which was not
deleted because it's not in the cache, but the actual output directory) was
only insignificantly different (only the MVID was different, which our cache
logic knows to ignore when comparing assemblies), so it wouldn't copy the
.exe to the .app.
* At runtime we'd assert, because the MVID in the aot-compiled code was
different from the MVID in the assembly:
error: Failed to load AOT module '(null)' while running in aot-only mode: doesn't match assembly.
* The exact assert varies depending on which build option changed. Other
variations:
Failed to load AOT module '(null)' while running in aot-only mode: compiled against GC (4, while the current runtime uses GC sgen)
* Assertion at /Users/builder/data/lanes/4691/0719ced1/source/xamarin-macios/external/mono/mono/metadata/metadata.c:1118, condition `idx < t->rows' not met
Because of this I'm reverting 11390f119c, and
once again setting the force flag when the cache is invalid. It might be
overkill, but it's the safest option (cache invalidation is after all the only
hard problem in computer science), and bugs are very annoying and
timeconsuming to track down.
https://bugzilla.xamarin.com/show_bug.cgi?id=54973
This change introduces the export of create_classes methods as objc compatible, without enforcing Objective-C++ as the development language for custom registrar embedders by moving the stringbuilder flushing inside the extern "C" block.
Mark the generated linking code as extern "C" too and also change the return type of xamarin_create_classes_Xamarin_Mac to void in mmp generation, as it was mistakenly set to int.
When converting strings to a sequence of bytes, we can't just cast chars to
ints, and write that, because non-ascii characters will resulting values
outside the byte range.
Instead explicitly convert the string to a UTF8 byte array, and process that.
https://bugzilla.xamarin.com/show_bug.cgi?id=56876
Previously:
obj/iPhone/Ad-Hoc/mtouch-cache/64/registrar.m:4402:12: error: expected identifier
@interface register : UITableViewController {
^
obj/iPhone/Ad-Hoc/mtouch-cache/64/registrar.m:4402:21: error: expected unqualified-id
@interface register : UITableViewController {
error : Failed to compile the generated registrar code. Please file a bug report at http://bugzilla.xamarin.com
Now:
error MT4168: Cannot register the type 'register' because its Objective-C name 'register' is an Objective-C keyword. Please use a different name.
https://bugzilla.xamarin.com/show_bug.cgi?id=51776
Rolf Bjarne Kvinge
Jeffrey Stedfast
Andy Martin
Bernhard Urban
Alex Soto
James Clancey
Nick Berardi
Timothy Risi
Chris Hamons
Miguel de Icaza
Marius Ungureanu