TL&DR: This is *how* it should be done and tested, it's not complete
(single, simple case) nor the most interesting case ;-)
The trick is to make sure each case is covered by tests so a mono
_bump_ won't give us a BCL that does not conform to what the linker
expect.
What's the impact ?
1. There is the expected reduction of metadata in mscorlib. Since both
methods don't call other API there's no indirect effect (removal).
--- before 2017-01-15 11:12:44.000000000 -0500
+++ after 2017-01-15 11:12:56.000000000 -0500
@@ -13166,9 +13166,6 @@
System.Void System.Security.SecurityException::.ctor(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext)
System.Void System.Security.SecurityException::.ctor(System.String)
System.Void System.Security.SecurityException::GetObjectData(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext)
-System.Boolean System.Security.SecurityManager::CheckElevatedPermissions()
-System.Security.SecurityManager
-System.Void System.Security.SecurityManager::EnsureElevatedPermissions()
System.Security.SecurityRulesAttribute
System.Security.SecurityRuleSet System.Security.SecurityRulesAttribute::m_ruleSet
System.Void System.Security.SecurityRulesAttribute::.ctor(System.Security.SecurityRuleSet)
2. There is no visible size change (even with #1) in mscorlib.dll due to
padding (compiler /filealign)
mscorlib.dll 793,600 793,600 0 0.00 %
3. there's a *very* small reduction of mscorlib.*.aotdata size
mscorlib.armv7.aotdata 717,264 717,216 -48 -0.01 %
mscorlib.arm64.aotdata 712,840 712,704 -136 -0.02 %
AOT data *.aotdata 6,460,064 6,459,880 -184 0.00 %
4. there's no change in executable size - normal as the AOT compiler has
_likely_ already doing the same optimization (before this commit)
Executable 29,270,272 29,270,272 0 0.00 %
Full comparison: https://gist.github.com/spouliot/0464c8fa3a92b6486dfd90595d9eb718
We're not storing selectors in fields anymore so this step does nothing
expect iterating over the code.
The step is still needed for `mmp` (for Xamarin.Mac.dll)
Simplify code a bit to avoid constant null checking and also take advantage of
the fact that HashSet.Add returns if the value was added or not (to avoid a
Contains check).
This allows mtouch to give better error message when something unexpected
occurs in the linker pipeline (at least for the sub-steps).
Practically it means fewer, contextless MT2001 errors. The replacements
error code are more precise, e.g.
* what was being done;
* what was being processed
and helps both diagnosing and, possibly, gives clues for workarounds
Build extensions and the container app in the same mtouch process, by storing
all the mtouch arguments when called to build extensions in a text file, and
then reloading those arguments when called to build the main app.
This is required if we want to share code between extensions and the
container.
This is a series of fixes to the dynamic libraries we build / create to remove
any unnecessary bloat (unused architectures, bitcode).
A brand new watchOS app with no changes goes from 35MB to 11MB with these
fixes (with incremental builds disabled, the app size is 10MB).
--------------------------------------------------------------------------------
* [runtime] Split list of architectures into simulator and device-specific lists.
* [runtime] Build separate dylibs for device and simulator.
Build separate dylibs for device and simulator, since we already install these
into different locations.
This makes both the simulator and device builds slightly faster (since the
respective dylibs are smaller, and less data to copy around).
For watchOS apps, this saves ~430kb.
* [runtime] Strip bitcode from dylibs. Fixes#51352.
We know that dylibs will never be shipped to the App Store, so we'll never
need them to have bitcode.
So just strip the bitcode from all our dylibs, since this makes apps with
fastdev significantly smaller (and thus much faster to upload to watch
devices).
For watchOS apps this is a very significant improvement: a branch new watchOS
app without any changes goes from 35MB to 17MB.
https://bugzilla.xamarin.com/show_bug.cgi?id=51352
* [mtouch] Fix dylib compilation to not embed full bitcode.
Facts
=====
a. The output from the AOT compiler is an assembly (.s) file.
b. Clang's assembler does not support -fembed-bitcode-marker (only -fembed-
bitcode), so when we ask clang to -fembed-bitcode-marker, the assembler
receives a -fembed-bitcode argument.
c. This means that the assembled object file does not contain the
__LLVM/__bitcode and __LLVM/__cmdline sections (it does however contain an
__LLVM/__asm section).
d. The native linker will create a bitcode assembly section if none of the
object files passed to the linker contain a __LLVM/__bitcode section and
there's an __LLVM/__asm section present.
e. The end result is that when we build to a dylib, we end up (unexpectedly,
because we ask Clang to -fembed-bitcode-marker) including both armv7k and
bitcode in the dylib, thus bloating the dylib size significantly.
Solution
========
We manually add the __LLVM/__bitcode and __LLVM/__cmdline sections to the .s
file Mono's AOT compiler generated. This way the .o file will have the magic
sections, and the linker will not include bitcode (only the bitcode marker) in
the final library.
An empty watchOS extension with incremental builds is now 6MB smaller (down
to 11MB from 17MB).
Don't create multiple writer streams for the same underlying file, instead
store the writer stream on the log instance, and return it whenever needed.
This fixes an issue where there would be multiple writer streams, which could
cause exceptions when creating more writer streams (access defined errors
because the file is already open).
This was changed in 1b1e345d72 since bmac.exe says --new-style is
deprecated.
However some users (MonoTouch.Hosting) manually call bmac (instead of going
through a binding project), and with 1b1e345d72 we changed the behavior when
--new-style was passed, so that it ended up trying to build Classic instead
(which is clearly not right for --new-style).
So make the bmac script understand --new-style again (to not break
compatibility), but don't forward the flag to bmac.exe (to avoid the
deprecation warning).
* [tests] Use the target directory from the loaded configuration.
* [xharness] Find the root directory based on xharness.exe's location (unless specified).
* [tests] Add makefile target to generate test config using the system XI.
Several dependency targets were not being properly run because the Condition
expressions on e.g. the _CodesignAppExtensions target depended on variables
that were empty until the dependencies set them. But dependencies are only
executed if the parent target's Conditions were met.
Also changed the _CodesignVerify target to use the _ResolvedAppExtensions
variable instead of the _AppExtensionCodesignProperties variable. This means
that the _CodesignVerify target no longer depends on the
_ReadCodesignAppExtensionProperties target being executed and thus makes it
less likely that bugs like that will slip by in the future.
* [xharness] Don't copy a ExecutionResult before executing.
The source might be an ignored test, even though the cloned task isn't, so if
we copy the ExecutionResult we might unexpectedly ignore the cloned task.
* [xharness] Provide better failure message for failing mac tests.
[msbuild] Refactor the IBTool task to be cleaner and more efficient
Besides making the IBTool task cleaner and easier to understand,
a side-effect of this refactor was also to optimize the collecting
of the compiled outputs because we now only need to scan the
obj/ibtool directory once to collect each of the outputs.
Unexpected exceptions are now caught in a more central location
(TestTask.RunInternalAsync), which means it's not necessary to catch
unexpected exceptions in other places (so those catch handlers have been
removed).
Additionally we now set the failure message when such an exception occurs, in
addition to writing the full exception details to a custom log file.
Both are our own creation and can be worked around with the `Delegate`
and `DataSource` properties (or the `Weak` ones).
We'll revisit this for `XAMCORE_4_0` as the test will fail again.
With this commit the remaining failures for tvOS should all be fixed
[FAIL] `UICollectionView.get_Source` return type `UICollectionViewSource` is a concrete type `[Model]` and not an interface `[Protocol]`
[FAIL] `UICollectionView.set_Source` includes a paramater of type `UICollectionViewSource` which is a concrete type `[Model]` and not an interface `[Protocol]`
[FAIL] `UITableView.get_Source` return type `UITableViewSource` is a concrete type `[Model]` and not an interface `[Protocol]`
[FAIL] `UITableView.set_Source` includes a paramater of type `UITableViewSource` which is a concrete type `[Model]` and not an interface `[Protocol]`
We're shipping mlaunch now, which means we have other file system locations
where it might be.
Also don't look in Xamarin Studio anymore, it will always be an old version,
instead check the system's Xamarin.iOS version.
* Existing `.ctor(object[])` now
* changed to `params` (not a breaking change);
* accept `NSString`, along with `string` and `UIImage`;
* Added `.ctor (NSArray)` (exposing the generated code to ease subclassing)
* Added `.ctor (params NSString[])`
* Added `.ctor (params string[])`
* Added `.ctor (params UIImage[])`
Also adds unit tests for all of them.
https://bugzilla.xamarin.com/show_bug.cgi?id=33163
Rolf Bjarne Kvinge
Sebastien Pouliot
Chris Hamons
Manuel de la Pena
Jeffrey Stedfast
Vincent Dondain
Sebastien Pouliot
Timothy Risi
Marek Safar