This fixes a NullReferenceException when there are already paired watch devices:
[0x700009ad7000:] EXCEPTION handling: System.NullReferenceException: Object reference not set to an instance of an object
"<unnamed thread>" tid=0x0x700009ad7000 this=0x0x10b903ad8 , thread handle : 0x7f9ad49109a0, state : not waiting
at xharness.Simulators/<CreateDevicePair>d__18.MoveNext () [0x001ae] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/xharness/Simulators.cs:169
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<bool>.Start<xharness.Simulators/<CreateDevicePair>d__18> (xharness.Simulators/<CreateDevicePair>d__18&) [0x0002c] in /Users/builder/jenkins/workspace/build-package-osx-mono/2018-02/external/bockbuild/builds/mono-x64/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:471
at xharness.Simulators.CreateDevicePair (xharness.Log,xharness.SimDevice,xharness.SimDevice,string,string,bool) [0x00057] in <7c5e77efeb3146c095a26043fb517189>:0
at xharness.Simulators/<FindOrCreateDevicePairAsync>d__19.MoveNext () [0x000fc] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/xharness/Simulators.cs:206
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<TResult_REF>.Start<TStateMachine_REF> (TStateMachine_REF&) [0x0002c] in <0f9df4881040473f9da7cf6c2e2cb8c3>:0
at xharness.Simulators.FindOrCreateDevicePairAsync (xharness.Log,System.Collections.Generic.IEnumerable`1<xharness.SimDevice>,System.Collections.Generic.IEnumerable`1<xharness.SimDevice>) [0x0003f] in <7c5e77efeb3146c095a26043fb517189>:0
at xharness.Simulators/<FindAsync>d__20.MoveNext () [0x00364] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/xharness/Simulators.cs:275
* [tests] Add introspection tests to ensure there are native linking instructions for all frameworks. Fixes#3976
or a good, documented (in test code) reason for not needing it.
https://github.com/xamarin/xamarin-macios/issues/3976
* Fix failures
- static registrar failed on 32bits because one type in PhotoUI missed
its `onlyOn64: true`
- link with the top, not the sub-frameworks
* [tvos] Fix mistakes in tvOS where some extranous types triggered unrequired/unavailable (or missing) frameworks
* [watchos] Fix watchOS frameworks mapping
* Add support for building on Jenkins. (#4159)
Add support for building on internal Jenkins.
Jenkins has been configured to build every branch on xamarin/xamarin-macios that contains a `jenkins/Jenkinsfile`, which means it will start working as soon as this PR is merged.
Results will be posted as statuses on each commit, which can be viewed using the url `https://github.com/xamarin/xamarin-macios/commits/<branch>`:
* The `continuous-integration/jenkins/branch` status links to the jenkins job.
* The other two are XI and XM packages (the `Jenkins-` prefix will be removed once we officially switch from Wrench to Jenkins).
More detailed information will be added as a comment to each commit, which can be seen by clicking on the commit and scrolling to the bottom (url of the format `https://github.com/xamarin/xamarin-macios/commit/<sha1>`)
Unfortunately GitHub does not display the commit statuses when viewing a single commit, so to view those statuses you'll have to view the list of commits (the `/commits/` url). Tip: it's possible to use `<sha1>` instead of `<branch>` (and vice versa for that matter) if you're interested in the statuses of a particular commit.
Pull requests will also be built (only from contributors with write access), but by default nothing will be done (the job will exit immediately, although a green check mark will still show up). Jenkins will **not** add a comment in the pull request in this case.
However, if the label `build-package` [1] is set for a pull request, the internal jenkins job will run (it will do everything except the local xharness test run: this includes creating and publishing packages, creating various diffs, run tests on older macOS versions, test docs, etc). A detailed comment will also be added to the pull request (see below for multiple examples), which means that there will be two Jenkins comments: one for the public Jenkins which builds every PR, and one for the internal Jenkins [2].
[1] I don't quite like the name of the label, because it doesn't get even close to explain all that will actually happen, but `run-on-internal-jenkins-and-create-package` is a bit too long IMHO... Also it's non-obvious that this is the label to apply if the reason for executing on the internal jenkins is some other reason (for instance to test a maccore bump). Other ideas:
* `run-internal-jenkins`: doesn't make it obvious that a package will be created (which is probably the most common reason to want to run on internal jenkins)
* We could have multiple labels that mean the same thing: `build-package`, `internal-build`, `run-internal-jenkins`, etc, but it's redundant and I don't quite like it either.
* Any other ideas?
[2] I'm noticing now that these two look quite similar and this might end up confusing (the main difference is that the comment from the public jenkins will say **Build success/failure** and **Build comment file:** at the top. If something goes wrong the failure will also show up differently). Should this be made clearer?
* Make the Jenkins packages official.
* [Jenkins] Create artifacts.json and set a GH status as 'Jenkins: Artifacts'.
* [jenkins] Include the url in artifacts.json
* [jenkins] Add sha256 checksum to artifacts.json as well.
* [Jenkins] Enable xamarin before provisioning so that we auto-provision Xcode.
* [jenkins] Fix passing flags to configure.
Quoting empty CONFIGURE_FLAGS ends up doing this:
./configure "" --disable-ios-device
and since configure parses arguments until it finds an empty argument, it
would stop parsing at the first argument, effectively not disabling the device
build.
So don't quote CONFIGURE_FLAGS when invoking configure. shellcheck doesn't
quite like this, but the better code is much more complex, and not really
needed, so just add an exception.
Many years ago (in Xcode 7 according to code comment)
Developer/Platforms/iPhoneOS.platform/Developer/usr disappeared, and we coped
by looking at Developer/usr instead (and also the subsequent code to locate
the bin directory was based on the location of the usr directory).
Developer/Platforms/iPhoneOS.platform/Developer/usr reappeared in Xcode 10
beta 1, but it seems useless (for one it doesn't contain a bin directory), so
in order to try to keep things sane don't look for this directory in Xcode 10
and instead go directly for Developer/usr (which is what we've been using as
the usr directory for years anyway).
Fixes this problem when building apps with Xcode 10 beta 1:
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets(626,3): error : Could not locate SDK bin directory [/Users/rolf/Projects/TestApp/test-app.csproj]
Commit list for mono/mono:
* mono/mono@1c24c158b0 [bitcode] Fix the generation of invalid llvm IR for some Span code.
* mono/mono@a49a68c6d7 [interp] Fix native to interp transition (#8957)
* mono/mono@92e11812f4 [System.Runtime.Serialization] Makes more APIs work for mobile
* mono/mono@260676f948 Bump API snapshot submodule
* mono/mono@eefdf4ed31 Bump external/cecil to b6c50e3
* mono/mono@0754926394 [2018-02] Finalize merp integration (#8869)
Diff: 7bdb7dd765...1c24c158b0
* [mtouch][mmp] Have CoreResolver check for the new SymbolsNotMatchingException from Cecil
* [tests] Rebuild MX4175 in a separate .app to avoid debug symbol warnings
The newer cecil version is better at detecting incorrect .mdb, like the
test is using, resulting in warnings since the 2nd build (same location)
was done without symbols (so old ones were loaded).
Stale debug symbols is not the goal of the MX4175 test. Rebuilding the
.app in another directory solves the extra warning issue.
* [NSActionDispatcher] Remove unused class
* [NSActionDispatcher] Move selectorname and selector variable into each class
* [NSActionDispatcher] Add specialized versions of NSActionDispatcher that use SynchronizationContext parameters
* [NSObject] Add specialized overloads for *InvokeOnMainThread which use SynchronizationContext parameters
* [AppKit,UIKit] Use the synchronization context specialized versions of *InvokeOnMainThread
This finishes the PR adding the following value:
1. There is no Action wrapper being constructed on async continuations,
thus on every await call we gain: 1 less allocation (lambda capture),
1 less indirected call to the actual continuation, and possibly
Action being removed by the linker, as its no longer used.
2. NSActionDispatcher* classes might now be linked out, due to
the static selector no longer being used everywhere
3. One unused class removed
* PR feedback
* Fix build
* PR feedback 2
* Seal this class
* Fix some renames not followed because they were undef ifdef'd code
Detect if we failed to create a simulator device pair due to trying with a
watch that's already paired. We were already detecting this scenario if the
watch was a member of an available pair, but not if the watch was a member of
an _unavailable_ pair (since mlaunch doesn't list unavailable device pairs).
So detect this scenario from the error message simctl gives us instead, and in
that case create a new watch device and try to create the pair again.
Fixes https://github.com/xamarin/maccore/issues/830.
* Improve IsCustomType performance
While NSObject may now flag internally whether it is a custom type, this
still has to be looked up each time a new instance of that type is created.
The dynamic registrar has a fast lookup for whether a type is a custom type
or not, but IsCustomType first checks the static registrar regardless.
GetClassHandle already caches the class handles, so this extends it to include
whether or not the type is custom so then IsCustomType can use the cached path.
* [Class] Store 'is_custom_class' as the least significant bit in our Class dictionary.
For the api diff for this PR we now show:
* `🔥 breaking changes 🔥`: If there are any breaking changes in the api diff (for this PR).
* `please review changes`: If there are any non-breaking changes in the api diff.
* `no change`: If the api diff is empty.
For the generator diff we show:
* `only version changes`: If there were only changes related to version numbers (since the XI/XM version number is added to the generator, that version number will always show up as a diff when comparing the generated source code)
* `please review changes`: If anything other that version numbers changed in the generated source code.
* [xharness] Create simulators if they don't already exist.
Create any needed simulators, instead of relying on them already existing (or
someone manually creating them).
A nice side effect is that it will become possible to delete all simulators on
a bot (to reclaim space), and they'll be re-created when needed.
* [xharness] If a watch device is already paired, create a new watch device and pair that instead.
Added the missing exclamation mark
New lines in the comments seemed to break the comment, so I removed them
This should prevent the template from appearing in the final issue when the user posts it
In my test project 969828 instances (67MB) of `ReaderParameters` were
created by `CoreResolver.Resolve`, which always allocated a new one.
Since we already create them, most of the time*, we can reuse the
instances when additional members requires resolving.
* only 14 additional instances are now required
* Share the stopwatch code between `mtouch` and `mmp`;
* Add more details on linker steps. Sadly substeps are executed on the
metadata so they can't be reported individually;
* Add a few places where timestamps where missing to get better precision
on the linking part;
We write 'No change detected' to [platform]-api-diff.html, which means that
checking for an empty file to detect no changes when generating the container
api-diff.html doesn't work as intended.
So change the logic to check for the 'No change detected' string instead.
On my test project we were calling `IsArchEnabled` 334,713 times which
made the enumerator called enough to show on the memory usage (13MB),
even if each instance is only 40 bytes.
Caching the result makes the method called only 5 times.
A few general categories of fixes:
* Sprinkle lots of quotes everywhere.
* Don't use environment variables in the format string to printf, instead pass them as arguments.
* Don't use backticks to execute commands (it's deprecated), use the new "$(...)" syntax instead.
* [ObjCRuntime] Improve MarkDirty speed by caching the IsCustomType value in our flags byte.
This makes calling MarkDirty for custom types ~60x times faster.
Reference: https://xamarinhq.slack.com/archives/C03CCJHCF/p1527194568000197
* We only have one bit left to use for IsCustomType.
* Fix build and make enums between native and managed match.
Chris Hamons
Xamarin Release Engineering
Rolf Bjarne Kvinge
Sebastien Pouliot
Manuel de la Pena
Matt Sylvia
Marius Ungureanu
Eric Maupin
Alex Soto
Vincent Dondain
John Miller
Sebastien Pouliot
