Create a table of interface -> protocol in the static registrar, since we need
to be able to look up a protocol given a managed type without looking at the
(possibly linked away) [Protocol] attribute.
* [tests] Fix relative paths in mmptest and make cloned XM nunit projects work properly.
Fixes this build problem with mmptest:
/Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/mmptest/CustomBuildActions.targets: error : Command 'make bin/SimpleClassDylib.dylib bin/SimpleClassStatic.a bin/Mobile-static/MobileBinding.dll' exited with code: 255.
Fixes https://github.com/xamarin/maccore/issues/633.
* [mmp] Improve Driver.IsDefaultMarshalingManagedExceptionMode to work before MarshalManagedException has been initialized.
Fixes this test failure:
1) Failed : Xamarin.MMP.Tests.MMPTests.UnifiedDebugBuilds_ShouldLinkToPartialStatic_UnlessDisabled
Debug build should use partial static registrar
Expected: True
But was: False
This regressed in 0561618460, where we wouldn't
properly select the partial static registrar because the initialization order
changed and we'd do it before selecting the default exception marshaling mode.
Changing Driver.IsDefaultMarshalingManagedExceptionMode to work before
MarshalManagedException has been initialized to its default value fixes the
problem.
Those were missed because xtro did not scan ObjC categories for
`objc_requires_super` attributes.
Fixing the naming mapping (to consider inlined categories) also
uncovered a few API with extraneous [DesignatedInitializer] attributes
Those were deprecated (API) and moved into categories so xtro missed
the designated initializer was removed.
All your `base`, well `super` in ObjC, now belong to us :)
https://github.com/xamarin/xamarin-macios/issues/3253
* [tests][xammac] Fix a few path calculations to not be hardcoded.
* [xharness] Clone XM projects.
Cloning projects before building them will also clone project references,
which will make it possible to build multiple projects in parallel, when those
projects have common project references.
Fixes https://github.com/xamarin/maccore/issues/624.
* [xharness] Fix XM project cloning
* Don't clone Classic projects (they're solutions, and xharness doesn't understand them).
* Clonee projects properly when cloning execution tasks.
* [xharness] GuiUnit needs specialized cloning.
The GuiUnit project uses relative paths to write to files outside the project
directory, which means that multiple GuiUnit project files may write to the
same location.
So special-case GuiUnit cloning to make those paths subdirectories of the
project's directory instead.
* [xharness] Process imported targets when cloning projects.
Also make the msbuild-mac's custom targets file independent of the location of
the project file by making all paths relative to the custom targets file.
Two constants with `__IPHONE_NA` were changed to `__IPHONE_11_3`.
Also decorate with [TV] and [Watch] attributes since they are implicit,
i.e. not in the headers but available in tvOS 11.3+ and WatchOS 4.3+
and, without our attributes, would seems to have been available much
earlier
* [linker] Optimize calls to BlockLiteral.SetupBlock to inject the block signature.
Optimize calls to BlockLiteral.SetupBlock[Unsafe] to calculate the block
signature at build time, and inject it into the call site.
This makes block invocations 10-15x faster (I've added tests that asserts at
least an 8x increase).
It's also required in order to be able to remove the dynamic registrar code in
the future (since calculating the block signature at runtime requires the
dynamic registrar).
* [mtouch/mmp] Add support for reporting errors/warnings that point to the code line causing the error/warning.
Add support for reporting errors/warnings that point to the code line causing
the error/warning by adding ErrorHelper overloads that take the exact
instruction to report (previously we defaulted to the first line/instruction
in a method).
* [tests] Add support for asserting filename/linenumber in warning messages.
* Make all methods that manually create BlockLiterals optimizable.
* [tests] Create a BaseOptimizeGeneratedCodeTest test that's included in both XI's and XM's link all test.
* [tests] Add link all test (for both XI and XM) to test the BlockLiteral.SetupBlock optimization.
* [tests] Add mtouch/mmp tests for the BlockLiteral.SetupBlock optimization.
* [tests][linker] Make the base test class abstract, so tests in the base class aren't executed twice.
* [tests][linker] Don't execute linkall-only tests in linksdk.
The optimization tests only apply when the test assembly is linked, and that
only happens in linkall, so exclude those tests in linksdk.
* [tests][mmptest] Update test according to mmp changes.
Fixes these test failures:
1) Failed : Xamarin.MMP.Tests.MMPTests.MM0132("inline-runtime-arch")
The warning 'MM0132: Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.' was not found in the output:
Message #1 did not match:
actual: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
Message #2 did not match:
actual: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
2) Failed : Xamarin.MMP.Tests.MMPTests.MM0132("foo")
The warning 'MM0132: Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.' was not found in the output:
Message #1 did not match:
actual: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
Message #2 did not match:
actual: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
* [tests][linker] Fix typo.
Fixes this test failure:
1) SetupBlock_CustomDelegate (Linker.Shared.BaseOptimizeGeneratedCodeTest.SetupBlock_CustomDelegate)
Counter
Expected: 1
But was: 2
* [registrar] Minor adjustment to error message to match previous (and better) behavior.
Fixes this test failure:
1) Failed : Xamarin.Registrar.GenericType_WithInvalidParameterTypes
The error 'MT4136: The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1<U>' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1<U>)'' was not found in the output:
Message #1 did not match:
actual: 'The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1<Foundation.NSObject>' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1<U>)''
expected: 'The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1<U>' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1<U>)''
* [docs] mmp shows MM errors/warnings.
* [docs] Improve according to reviews.
* [tests] Fix merge failure causing test duplication.
* [generator] Teach generator about WrapAttribute on Getters and Setters
https://bugzilla.xamarin.com/show_bug.cgi?id=57870
`WrapAttribute` can now be used in property getters and setters,
this allows to Wrap virtually anything the way you need, for example
smart enums, consider the following API definition:
```csharp
// Smart enum.
enum PersonRelationship {
[Field (null)]
None,
[Field ("FMFather", "__Internal")]
Father,
[Field ("FMMother", "__Internal")]
Mother
}
```
```csharp
// Property definition.
[Export ("presenceType")]
NSString _PresenceType { get; set; }
PersonRelationship PresenceType {
[Wrap ("PersonRelationshipExtensions.GetValue (_PresenceType)")]
get;
[Wrap ("_PresenceType = value.GetConstant ()")]
set;
}
```
* Fix Feedback
* Fix doc error
* Update error message
Moving to reference sources added a few, new converters so the existing
logic to preserve them was not complete.
This update the list of converters, sorted like the reference sources
(RS) for easier reviews.
It also adds:
* a canary test in "dont link" that will fail it the RS code change
or is replaced;
* more complete unit tests to ensure all cases works
https://github.com/xamarin/xamarin-macios/issues/3372
* [registrar] Register models in the static registrar.
This also means we need to quiet a few types of warnings:.
* Models declares virtual methods of required protocol members. We don't
export virtual methods (only when they're overridden are they exported),
which results in numerous warnings about protocol members not being
implemented:
Xamarin.Mac.registrar.mobile.x86_64.m:37827:17: warning: method 'deviceBrowserView:selectionDidChange:' in protocol 'IKDeviceBrowserViewDelegate' not implemented [-Wprotocol]
@implementation ImageKit_IKDeviceBrowserView__IKDeviceBrowserViewDelegate {
^
/Applications/Xcode92.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Quartz.framework/Frameworks/ImageKit.framework/Headers/IKDeviceBrowserView.h:29:1: note: method 'deviceBrowserView:selectionDidChange:' declared here
- (void)deviceBrowserView: (IKDeviceBrowserView *)deviceBrowserView selectionDidChange: (ICDevice *)device;
* These two are the same as above, just for properties instead of methods.
Xamarin.Mac.registrar.mobile.x86_64.m:31988:17: warning: auto property synthesis will not synthesize property 'boundingMapRect' declared in protocol 'MKOverlay' [-Wobjc-protocol-property-synthesis]
@implementation MKOverlay {
^
/Applications/Xcode92.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/MapKit.framework/Headers/MKOverlay.h:24:43: note: property declared here
@property (nonatomic, readonly) MKMapRect boundingMapRect;
^
Xamarin.Mac.registrar.mobile.x86_64.m:32002:1: note: add a '@synthesize' directive
@end
^
Xamarin.Mac.registrar.mobile.i386.m:28957:17: warning: property 'repeatCount' requires method 'repeatCount' to be defined - use @synthesize, @dynamic or provide a method implementation in this class implementation [-Wobjc-property-implementation]
@implementation CAMediaTiming {
^
/Applications/Xcode92.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/QuartzCore.framework/Headers/CAMediaTiming.h:58:17: note: property declared here
@property float repeatCount;
^
* [AVFoundation] Special-case AVCaptureDataOutputSynchronizer[Delegate] in the registrar for macOS.
This class and protocol were incorrectly added to our macOS bindings, but
since we can't remove them because it would break backwards compatibility, we
must skip them manually in the registrar, since the registrar would otherwise
produce uncompilable code:
In file included from Xamarin.Mac.registrar.full.x86_64.m:2:
./Xamarin.Mac.registrar.full.x86_64.h:2929:63: error: 'AVCaptureDataOutputSynchronizerDelegate' is unavailable: not available on macOS
@interface AVCaptureDataOutputSynchronizerDelegate : NSObject<AVCaptureDataOutputSynchronizerDelegate> {
^
/Applications/Xcode92.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/AVFoundation.framework/Headers/AVCaptureDataOutputSynchronizer.h:101:11: note: 'AVCaptureDataOutputSynchronizerDelegate' has been explicitly marked unavailable here
@protocol AVCaptureDataOutputSynchronizerDelegate <NSObject>
^
In file included from Xamarin.Mac.registrar.mobile.x86_64.m:2:
./Xamarin.Mac.registrar.mobile.x86_64.h:3370:63: error: 'AVCaptureDataOutputSynchronizerDelegate' is unavailable: not available on macOS
@interface AVCaptureDataOutputSynchronizerDelegate : NSObject<AVCaptureDataOutputSynchronizerDelegate> {
* [AVFoundation] Stub out AVCaptureDataOutputSynchronizer[Delegate] on macOS.
AVCaptureDataOutputSynchronizer[Delegate] were incorrectly added to our macOS
bindings, which makes the static registrar's life difficult. So remove those
bindings, and re-implemented them as normal classes, without any attributes,
which makes the static registrar ignore them (to a certain extent: enough to
not generate uncompilable code at least).
* [registrar] Remove more model exclusion code.
* [xtro] Update ignored entries.
* [tests] Move linker tests to match introspection directory layout.
Move linker tests to match introspectio directory layout: tests/linker/ios and
tests/linker/mac instead of tests/linker-ios and tests/linker-mac.
This creates a logical place for shared linker files (tests/linker).
* [tests] Fix path to GuiUnit_NET_4_5.csproj in sln as well.
This is the path used to find referenced projects when building Classic.
Fixes this build problem:
warning: Referenced project 'GuiUnit_NET_4_5' not found in the solution.
/Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/common/mac/MacTestMain.cs(11,7) : error CS0246: The type or namespace name `GuiUnit' could not be found. Are you missing an assembly reference?
/Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/common/mac/MacTestMain.cs(64,42) : error CS0246: The type or namespace name `IMainLoopIntegration' could not be found. Are you missing an assembly reference?
/Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/common/mac/MacTestMain.cs(75,34) : error CS0246: The type or namespace name `InvokerHelper' could not be found. Are you missing an assembly reference?
* [tests] Build the native test library for macOS and create a binding project for it.
Also add the new binding project to the xammac and link all XM test projects,
which allows us to stop excluding tests that require the native library and
the corresponding bindings.
* [tests] Include more tests in xammac_tests.
* [tests] Correctly ignore the ObjC exception tests in release mode.
* [tests] Share supporting code between the mtouch and mmp tests.
Create a new class 'BundlerTool', which now contains most of the code in
MTouchTool that's also applicable to mmp (and the new MmpTool class).
This will make it easier to share tests between the mtouch and mmp tests.
Some tweaks are still probably required, but this should get us most of the
way.
* [tests] Fix generator tests after changes in shared test code.
* [tests] Add new file to the MSBuild/XM tests.
This file is included in several projects, some projects use property, some
don't (and report the warning). There's no harm in not setting this property
(it's expected), ignore the warning.
This won't affect device tests on the bots (because those already set LLVM
manually when testing Release), but it becomes less confusing when trying to
reproduce any problems locally, since now the project configuration on disk
matches the tested configuration.
Fixes this:
tests/common/mac/ProjectTestHelpers.cs(154,22): warning CS0436: The type 'StringUtils' in 'tests/mmptest/../../tools/common/StringUtils.cs' conflicts with the imported type 'StringUtils' in 'mmp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/mmptest/../../tools/common/StringUtils.cs'.
tests/common/Configuration.cs(162,53): warning CS0436: The type 'StringUtils' in 'tests/mmptest/../../tools/common/StringUtils.cs' conflicts with the imported type 'StringUtils' in 'mmp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/mmptest/../../tools/common/StringUtils.cs'.
* [Foundation] Simplify NSValue code to use [No*] instead of ifdefs.
Also enable the MKCoordinateSpan and CLLocationCoordinate2D values for NSValue
in macOS, since they're now available (since macOS 10.9).
Type Changed: Foundation.NSValue
Added properties:
public virtual MapKit.MKCoordinateSpan CoordinateSpanValue { get; }
public virtual CoreLocation.CLLocationCoordinate2D CoordinateValue { get; }
* [Foundation] Mark the new NSValue selectors as 64-bit only.
* [xharness] Add support for running XI projects with different platform configurations.
* [xharness] Run dont link, link all and link sdk tests in both Debug and Release in the simulator. Fixes#53181.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=53181.
* [tests] Fix dont link to always optimize C# code in release mode.
* [tests] No need to weak link GameController anymore in dont link.
This was removed long ago from the Debug configurations, so remove it from the
Release configuration as well.
- Obsolete `ARFaceAnchor`'s default constructor because it's marked as unavailable.
- Obsolete `CreateFaceGeometry` in `ARSCNFaceGeometry` in favor of `Create` (same as `ARSCNPlaneGeometry`).
* [xharness] Ask mono to not attach gdb/ldb when XM tests crash.
Attaching gdb/ldb usually hangs, thus causing the test run to time out instead
of finishing early (due to the crash).
Also bump the timeout for finding crash reports to 60 seconds when the tests
crash, since macOS can be quite slow to create the crash report.
* [xharness] Timestamp mac logs to aid diagnostics.
We must call VerifyRun for each subtest in the aggregated simulator test run
in order to mark those subtests as failed if there's no available device.
Fixes https://github.com/xamarin/maccore/issues/623.
This class and protocol were incorrectly added to our macOS bindings.
The catch is that we can't remove them because it would break backwards
compatibility, so mark them for removal in XAMCORE_4_0.
* [ObjCRuntime] Add a BindingImplAttribute.
* [linker] Make ProviderToString an extension method on ICustomAttributeProvider to make it more discoverable.
* [generator] Use [BindingImpl] instead of [CompilerGenerated].
The entire diff is big (89MB), so it can't be gisted. However, most of it is
either removal of `using System.Runtime.CompilerServices;` or the change from
`[CompilerGenerated]` to `[BindingImpl (...)]` like this:
https://gist.github.com/rolfbjarne/8bfda3ed37b956d0342a1c1e9b079244
If I remove those parts of the diff, there's nothing significant left:
https://gist.github.com/rolfbjarne/4156164d6bdb1376366200394eb8a091
* [linker] Teach the linker about the new [BindingImpl] attribute.
In addition to the existing logic where the linker would optimize some
[CompilerGenerated] code (sometimes with additional requirements), it will now
also optimize all [BindingImpl (Optimizable)] code (without any additional
requirements).
* [tests] Add tests to make sure [BindingImpl (Optimizable)] works as expected.
* [linker] Check for [BindingImpl] before [CompilerGenerated] and stop checking for [CompilerGenerated] in XAMCORE_4_0.
Check for [BindingImpl] before checking for [CompilerGenerated], since the
former is more common.
Also stop checking for [CompilerGenerated] (at least to mean that code is
optimizable) in our next non-compatible evolutionary leap (XAMCORE_4_0):
* [introspection] Impl a better typo check.
Fixes this test failure:
1) Failed : Xamarin.MMP.Tests.MMPTests.UnifiedWithLinking_ShouldHaveFewFrameworkClangLines
Found more framework entries in clang invocation then expected - Foundation AppKit QuartzCore CoreData Quartz CoreFoundation CoreServices Security Carbon CloudKit
xcrun -sdk macosx clang -mmacosx-version-min=10.7 -arch x86_64 -fobjc-runtime=macosx -Wno-unguarded-availability-new -ObjC -framework Foundation -framework AppKit -framework QuartzCore -framework CoreData -framework Quartz -framework CoreFoundation -framework CoreServices -framework Security -framework Carbon -weak_framework CloudKit -u _xamarin_timezone_get_data -u _xamarin_get_block_descriptor /work/maccore/master/xamarin-macios/_mac-build/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/lib/libxammac.a -o /work/maccore/master/xamarin-macios/tests/mmptest/bin/Debug/tmp-test-dir/Xamarin.MMP.Tests.MMPTests.RunMMPTest/bin/Debug/UnifiedExample.app/Contents/MacOS/UnifiedExample -D_THREAD_SAFE -I/work/maccore/master/xamarin-macios/_mac-build/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/lib/pkgconfig/../../include/mono-2.0 /work/maccore/master/xamarin-macios/_mac-build/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/lib/pkgconfig/../../lib/libmonosgen-2.0.a -liconv -x objective-c++ -I/work/maccore/master/xamarin-macios/_mac-build/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/include /work/maccore/master/xamarin-macios/tests/mmptest/bin/Debug/tmp-test-dir/Xamarin.MMP.Tests.MMPTests.RunMMPTest/obj/Debug/mmp-cache/registrar.m -fno-caret-diagnostics -fno-diagnostics-fixit-info -isysroot /Applications/Xcode92.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk /work/maccore/master/xamarin-macios/tests/mmptest/bin/Debug/tmp-test-dir/Xamarin.MMP.Tests.MMPTests.RunMMPTest/obj/Debug/mmp-cache/main.m
Expected: less than 10
But was: 10
This regressed in 4da8016db4, where new API is
partially unremovable by the linker, and as such causes XM to link with more
frameworks at build time.
This is expected, so change the test to accept more frameworks (11).
Fixes https://github.com/xamarin/maccore/issues/615.
Fixes this test failure on High Sierra:
Xamarin.Mac.Tests.EveryFrameworkSmokeTests.ExpectedLibrariesAreLoaded: CoreSpotlightLibrary (/System/Library/Frameworks/CoreSpotlight.framework/CoreSpotlight) failed to load but this was not expected
Make sure to package the linker tests when packaging XM tests (this broke
recently because the dontlink tests were moved).
Fixes this problem when running the packaged tests:
make[2]: linker-mac/dont link/bin/x86/Debug/dont link.app/Contents/MacOS/dont link: No such file or directory
make[2]: *** [exec-mac-classic-dont link] Error 1
make[2]: linker-mac/dont link/bin/x86/Debug-unified/dont link.app/Contents/MacOS/dont link: No such file or directory
make[2]: *** [exec-mac-unified-dont link] Error 1
make[2]: linker-mac/dont link/bin/x86/Debug-unifiedXM45/dont link.app/Contents/MacOS/dont link: No such file or directory
make[2]: *** [exec-mac-unifiedXM45-dont link] Error 1
make[2]: linker-mac/dont link/bin/x86/Debug-unified-32/dont link.app/Contents/MacOS/dont link: No such file or directory
make[2]: *** [exec-mac-unified32-dont link] Error 1
make[2]: linker-mac/dont link/bin/x86/Debug-unifiedXM45-32/dont link.app/Contents/MacOS/dont link: No such file or directory
make[2]: *** [exec-mac-unifiedXM4532-dont link] Error 1
exec-mac-classic-dont\ link failed
exec-mac-unified-dont\ link failed
exec-mac-unifiedXM45-dont\ link failed
exec-mac-unified32-dont\ link failed
exec-mac-unifiedXM4532-dont\ link failed
make[1]: *** [exec-mac-dontlink] Error 1
* [mtouch/mmp] Give users more control over optimizations, and share more code between mtouch and mmp.
1. Add an --optimize flag to mtouch/mmp that allows users to select which
optimizations to apply (or not). This makes it easier to add future
optimizations, and allow users to disable any optimization that causes
problems without having to disable many other features.
2. Share as much optimization code as possible between mtouch and mmp. This
immediately gives a benefit to mmp, which has three new optimizations only
mtouch had: NSObject.IsDirectBinding inlining, IntPtr.Size inlining and
dead code elimination.
This results in ~6kb of disk space saved for a linked Xamarin.Mac app:
* link sdk: [Debug][1], [Release][2]
* link all: [Debug][3], [Release][4]
Testing also verifies that monotouchtest ([Debug][5], [Release][6]) has not
changed size at all, which means that no default optimizations have changed
inadvertedly.
[1]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-sdk-mac--debug
[2]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-sdk-mac--release
[3]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-all-mac--debug
[4]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-all-mac--release
[5]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#monotouchtest-iphonedebug64
[6]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#monotouchtest-iphonerelease64
* [tools] Don't enable the IsDirectBinding optimization by default for Xamarin.Mac apps, it's not safe.
* Fix whitespace issues.
* [doc] Document optimizations.
* Officially support optimizations by adding them to the Versions.plist.
* [linker] Improve IntPtr.Size inliner + dead code eliminatior and add tests.
* Properly handle operands for the ldc_i4_s instruction (they're sbyte).
* Fix less-than condition to actually do a less-than comparison.
* Make sure to look up the bitness in the Target, not the Application, since
the Application's value will be incorrect when building fat apps (both
Is32Build and Is64Build will be true).
* Remove unnecessary checks for the IntPtr.Size inliner: this optimization
does not depend on other instructions than the IntPtr.get_Size call, so
remove the checks that verify surrounding instructions. This makes the
IntPtr.Size inliner kick in in more scenarios (such as the new tests).
* Add tests.
* [tests] Add mmp tests for optimizations.
* [tests] Fix XM optimization tests.
* [tests] Fix test build error.
* [mtouch] Make sure the xamarin_localized_string_format* functions are available in simlauncher. Fixes#3265.
Fixes https://github.com/xamarin/xamarin-macios/issues/3265.
* [mtouch] Add test for simlauncher symbols, add add more missing symbols.
Fixes this rather puzzling build problem when building monotouch-test using xharness:
obj/iPhoneSimulator/Debug-unified/Xamarin.iOS,Version=v1.0.AssemblyAttribute.cs(2,12): error CS0579: Duplicate 'global::System.Runtime.Versioning.TargetFrameworkAttribute' attribute
It happens only on Wrench (where it consistently fails), but it didn't happen
in the PR when this broke, nor could I reproduce it locally at first.
Initial investigation proved frustrating (searching for the file name
`Xamarin.iOS,Version=v1.0.AssemblyAttribute.cs` in the build log confirmed
that it was included multiple times on Wrench, but not locally), but after a
while I realized that there were multiple files with the same file name in the
build log:
/Users/builder/data/lanes/1381/daf07005/source/xamarin-macios/tests/monotouch-test/obj/iPhone/Release64-unified/Xamarin.iOS,Version=v1.0.AssemblyAttribute.cs
obj/iPhoneSimulator/Debug-unified/Xamarin.iOS,Version=v1.0.AssemblyAttribute.cs
One full path, and one relative, and one is obviously wrong.
Even more so once I realized that the full path's Platform/Configuration
(`iPhone/Release64-unified`) doesn't match the relative path's
Platform/Configuration (`iPhoneSimulator/Debug-unified`).
It's not even a test configuration we execute on Wrench, so how come the file
got there in the first place?
But it made it possible to reproduce locally: I just had to build monotouch-
test for device first, using tests.sln. Then I could reproduce the build error
when executing monotouch-test from xharness, since now I had the extraneous
file on my file system.
xharness will clone project files (to avoid parallel issues when building
multiple projects in parallel, all projects are built in their own
directories), and it turns out we didn't properly fixup all paths.
In particular the following:
<Compile Include="**\*.cs" Exclude="obj\**">
<Link>%(RecursiveDir)%(Filename).cs</Link>
</Compile>
would be transformed into:
<Compile Include="\Users\builder\data\lanes\1381\daf07005\source\xamarin-macios\tests\monotouch-test\**\*.cs" Exclude="obj\**">
<Link>%(RecursiveDir)%(Filename).cs</Link>
</Compile>
which meant that we'd include all files recursively in the monotouch-test
directory, excluding files from the project file's obj sub directory. And
since the project file was cloned, it would be in a different directory, and
thus not able to exclude files from the original monotouch-test/obj directory.
And with this knowledge the simple oneliner to fix it was trivial.
One mystery remained though: how was the extraneous
`Xamarin.iOS,Version=v1.0.AssemblyAttribute.cs` file generated when we don't
execute device tests on Wrench? After a while I remembered that the MTouch
tests build monotouch-test for device, even though they're not executed.
And this explains why the problem happens on wrench only: Jenkins didn't
execute the MTouch tests.
The original, now obsoleted, `LocalizedString` API returned a .net
`string` which does not work in most cases.
Different versions of iOS seems to return different (public or internal)
subclasses of `NSString` that are understood by other API (like NSString
`localizedStringWithFormat:`) for further customization.
Our logic to convert NSString to string is correct but it cannot
recreate the custom, required subclass to continue the localization.
So the new API return an `NSString` publicly (which is actually a
subclass) that can do the required job.
Adding a test in monotouch-test is presently blocked by #3265 [2]
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=41292
[2] https://github.com/xamarin/xamarin-macios/issues/3265
* Add tests for new (and old) NSBundle API and adjust old ones since adding a Base.lproj directories changes things
* Add localization to xammac_tests since it shares the same, updated tests
When determining the color for a collection of tests, first check if the
execution result is identical for all tests in the collection, in which case
just use the corresponding color for a single test.
- Fixes bug #59272: [xtro] Report !missing-protocol-conformance! when protocols are defined in categories
(https://bugzilla.xamarin.com/show_bug.cgi?id=59272)
- Implemented missing protocol conformances based on tool's new data.
- Remove Internal check from VisitObjCCategoryDecl and VisitObjCInterfaceDecl
- Ignore previewItemTitle failure (normal since it's optional)
- Only skip UIStateRestoring for subclasses of UIViewController
- Ignore UIStateRestoring test on watchOS (UIViewController not available)
- Remove protocol conformances that generated wrong availability attributes (https://github.com/xamarin/xamarin-macios/issues/3213)
- Avoid new virtual or virtual when adding protocol conformance (https://github.com/xamarin/xamarin-macios/issues/3217)
xharness needs a solution in order to ask for a nuget restore, so make sure to
provide the path to the solution.
This fixes a build issue where the install source tests would fail to build
due to picking up the system's nunit.framework.dll because the nuget one
wasn't found/restored:
MonoPathManglerTest.cs(8,3): error CS0619: 'TestFixtureAttribute' is obsolete: 'The NUnit framework shipped with Mono is deprecated and will be removed in a future release. It was based on NUnit 2.4 which is long outdated. Please move to the NUnit NuGet package or some other form of acquiring NUnit.'
XamarinSourcesPathManglerTest.cs(8,3): error CS0619: 'TestFixtureAttribute' is obsolete: 'The NUnit framework shipped with Mono is deprecated and will be removed in a future release. It was based on NUnit 2.4 which is long outdated. Please move to the NUnit NuGet package or some other form of acquiring NUnit.'
OpenTKManglerTest.cs(8,3): error CS0619: 'TestFixtureAttribute' is obsolete: 'The NUnit framework shipped with Mono is deprecated and will be removed in a future release. It was based on NUnit 2.4 which is long outdated. Please move to the NUnit NuGet package or some other form of acquiring NUnit.'
PathManclerFactoryTests.cs(8,3): error CS0619: 'TestFixtureAttribute' is obsolete: 'The NUnit framework shipped with Mono is deprecated and will be removed in a future release. It was based on NUnit 2.4 which is long outdated. Please move to the NUnit NuGet package or some other form of acquiring NUnit.'
OpenTKManglerTest.cs(29,4): error CS0616: 'TestCase' is not an attribute class
OpenTKManglerTest.cs(30,4): error CS0616: 'TestCase' is not an attribute class
MonoPathManglerTest.cs(29,4): error CS0616: 'TestCase' is not an attribute class
MonoPathManglerTest.cs(30,4): error CS0616: 'TestCase' is not an attribute class
MonoPathManglerTest.cs(31,4): error CS0616: 'TestCase' is not an attribute class
XamarinSourcesPathManglerTest.cs(33,4): error CS0616: 'TestCase' is not an attribute class
XamarinSourcesPathManglerTest.cs(35,4): error CS0616: 'TestCase' is not an attribute class
XamarinSourcesPathManglerTest.cs(37,4): error CS0616: 'TestCase' is not an attribute class
OpenTKManglerTest.cs(36,4): error CS0616: 'TestCase' is not an attribute class
OpenTKManglerTest.cs(37,4): error CS0616: 'TestCase' is not an attribute class
MonoPathManglerTest.cs(37,4): error CS0616: 'TestCase' is not an attribute class
MonoPathManglerTest.cs(38,4): error CS0616: 'TestCase' is not an attribute class
MonoPathManglerTest.cs(39,4): error CS0616: 'TestCase' is not an attribute class
XamarinSourcesPathManglerTest.cs(47,4): error CS0616: 'TestCase' is not an attribute class
These targets will already be properly escaped (using backslash), so adding
quotes will cause make to treat the backslashes literally (and break).
Fixes an issue with package-tests:
$ make package-tests
[...]
build-mac-classic-dont\ link failed
build-mac-unified-dont\ link failed
build-mac-unifiedXM45-dont\ link failed
build-mac-unified32-dont\ link failed
build-mac-unifiedXM4532-dont\ link failed
build-mac-unified-link\ all failed
build-mac-unified-link\ sdk failed
make[4]: *** [build-mac] Error 1
make[3]: *** [mac-test-package.zip] Error 2
make[2]: *** [package-tests] Error 2
* [xharness] Run monotouch-test both with and without the static registrar in the simulator.
This way we catch (some) problems with the static registrar without having to run on device.
* [xharness] Add comments to explain extra test configurations.
* [xharness] Fix how projects are cloned.
Fix how projects are cloned so that xharness doesn't end up confused when
multiple test tasks share the same build task.
Previously xharness would iterate over all test tasks and modifying their
build tasks, now it will create the build tasks correctly in the first place.
* [tests] Add 'link all' test for XM.
* [tests] Add 'link sdk' test for XM.
* [tests] Move dontlink-mac tests to linker-mac directory to have the same directory layout as linker-ios.
These were accidentally not disabled when we started running tests on Wrench
like we do on Jenkins.
So disable them, to avoid duplicate work on Wrench.
and ensure the temporary `NSString` instance is disposed asap.
Found will debugging something else. Unit tests added to confirm there
is no behavior change when the API are used.
* [mtouch][mmp] Report invalid debug symbols files. Fixes#3200
Try to read the assembly with symbols and, if that fails, warn and
fallback to loading them without symbols.
This fixes cases were it's not easy to update or delete (e.g. nuget)
bad symbols files - so this cannot be an error without causing a lot
of pain.
However it needs to be reported, otherwise it wont be fixed (by the
publisher) and it can limit the debugability of the application and
the usefulness of the stacktraces.
Finally merge most of the resolver's code between mtouch and mmp so
we don't have to fix such issue twice anymore.
note: this needs to be slightly updated once we get a version of cecil
that can give us a more precise error message.
Also bring Rolf's tests from
https://github.com/xamarin/xamarin-macios/pull/3079
reference:
https://github.com/xamarin/xamarin-macios/issues/3200
This now formal `CAAnimationDelegate` protocol had to be reverted [1]
because we did not support `FormalSince` at the time - and this broke the
static registrar when used with older SDK. Support was added in [2] but
did not include `CAAnimationDelegate` (but `CALayerDelegate` was fixed).
Because this was not a protocol the `Delegate` property expose it as a
`CAAnimationDelegate`, the concrete/model type, and not an interface.
The workaround so `ICAAnimationDelegate` can be used, thru the
`WeakDelegate`, requires to manually re-bind some API because the
generator won't allow this anymore (it's bad to expose a [Model]
when a [Protocol] exists).
xtro data updated
[1] https://github.com/xamarin/xamarin-macios/pull/698
[2] https://github.com/xamarin/xamarin-macios/pull/2130
In particular the mmp tests build a lot of project files, which means they can
find issues whenever something in the MSBuild logic changes, so run them.
They would have caught https://github.com/xamarin/maccore/issues/612 for instance.
Fixesxamarin/xamarin-macios#3166
Apple broke `addAnimation:forKey:` API by changing `CAAnimation` parameter into a
`ISCNAnimationProtocol` that was introduced in Xcode 9 (iOS 11 and company).
We can't break the existing API but we can add an extension method that
reuses the `CAAnimation` overload but takes a `SCNAnimation` and we
turn the `SCNAnimation` into a `CAAnimation` behind the scenes.
For XAMCORE_4_0 we corrected the protocol signature to take `ISCNAnimationProtocol` so there won't be a need for the extension method anymore.
Largely related to somewhat recent frameworks/API additions to XM
ExternalAccessory was added to macOS 10.13 (Xcode9) and can't be run before that (including on the jenkins sierra bots). Also enable that test on tvOS (which added support in Xcode8)
Sadly this creates a breaking change since the `ScaleTransform`
property was re-introduced with an incorrect signature in the new
base class `MPSImageScale`
Unless someone has an idea how to avoid it (I don't see an option)
then we'll have to document it in the 15.7 release notes.
Also add missing _SetScaleTransform call and related unit tests
Don't *always* codesign, especially for Xcode 8 which seems to break.
iOS Simulator builds should only be codesigned if they require
Entitlements (signified by RequireProvisionProfile).
Don't *always* codesign, especially for iOS8 which seems to break.
iOS Simulator builds should only be codesigned if they require
Entitlements (signified by RequireProvisionProfile).
Previous PMCS removal changes froze XamMac.BindingAttributes.dll but not bgen.exe which causes interesting issues when we make changes there and run classic XM tests.
This can be seen here: #3147
This PR freezes bgen-classic in macios-binaries (which will need to be added to master and bumped before this goes in) and update various scripts/tests.
Before XAMCORE_4_0 the setter will throw an `NotImplementedException`
which is better, and more accurate, than a native exception.
Found by xtro. Data file updated.
We normally frown on large scale _cosmetic_ changes, mostly because it breaks git's history (very useful) and makes merging branches harder and more error prone (very annoying).
However we require, right now, such changes to remove our old, mcs-based, pre-processor (pmcs) so it's a _good_ time to address the old, unneeded availability attributes - since most of them are re-written for our next milestone.
This won't change the final application size in most cases, as the linker removes them, but it will make the (unlinked) platform assemblies smaller. This means they will load faster (e.g. by mtouch, mmp, IDE, workbooks...) and will reduce the time/memory needed to reflect them.
* SLComposeServiceViewController has [Mac] specific stuff but was
excluded under a (too large) `#if !MONOMAC`
* SLComposeSheetConfigurationItem::init is a designated initializer
* SLRequest::addMultipartData:withName:type: is macOS-only and missing
xtro results:
!missing-designated-initializer! SLComposeSheetConfigurationItem::init is missing an [DesignatedInitializer] attribute
!missing-selector! SLComposeServiceViewController::charactersRemaining not bound
!missing-selector! SLComposeServiceViewController::contentText not bound
!missing-selector! SLComposeServiceViewController::placeholder not bound
!missing-selector! SLComposeServiceViewController::setCharactersRemaining: not bound
!missing-selector! SLComposeServiceViewController::setPlaceholder: not bound
!missing-selector! SLComposeServiceViewController::textView not bound
!missing-selector! SLRequest::addMultipartData:withName:type: not bound
!missing-type! SLComposeServiceViewController not bound
* PHLivePhotoView only available on 64 bits
xtro results:
!missing-enum! PHLivePhotoViewContentMode not bound
!missing-enum! PHLivePhotoViewPlaybackStyle not bound
!missing-protocol! PHLivePhotoViewDelegate not bound
!missing-selector! PHLivePhotoView::audioVolume not bound
!missing-selector! PHLivePhotoView::contentMode not bound
!missing-selector! PHLivePhotoView::delegate not bound
!missing-selector! PHLivePhotoView::isMuted not bound
!missing-selector! PHLivePhotoView::livePhoto not bound
!missing-selector! PHLivePhotoView::livePhotoBadgeView not bound
!missing-selector! PHLivePhotoView::setAudioVolume: not bound
!missing-selector! PHLivePhotoView::setContentMode: not bound
!missing-selector! PHLivePhotoView::setDelegate: not bound
!missing-selector! PHLivePhotoView::setLivePhoto: not bound
!missing-selector! PHLivePhotoView::setMuted: not bound
!missing-selector! PHLivePhotoView::startPlaybackWithStyle: not bound
!missing-selector! PHLivePhotoView::stopPlaybackAnimated: not bound
!missing-type! PHLivePhotoView not bound
* [xtro] Sort earlier in EnumCheck so we don't have to duplicate checks (or get random failures)
That fix a NRE while running xtro
12:55:31.4682580 System.NullReferenceException: Object reference not set to an instance of an object
12:55:31.4682960 at Extrospection.Helpers.GetFramework (Mono.Cecil.TypeReference type) [0x00012] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xtro-sharpie/Helpers.cs:284
12:55:31.4683110 at Extrospection.EnumCheck.VisitManagedType (Mono.Cecil.TypeDefinition type) [0x0006c] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xtro-sharpie/EnumCheck.cs:28
12:55:31.4683210 at Extrospection.AssemblyReader.ProcessType (Extrospection.BaseVisitor v, Mono.Cecil.TypeDefinition type) [0x00001] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xtro-sharpie/Runner.cs:78
12:55:31.4683320 at Extrospection.AssemblyReader.Load (System.String filename) [0x00079] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xtro-sharpie/Runner.cs:71
12:55:31.4684210 at Extrospection.Runner.Execute (System.String pchFile, System.Collections.Generic.IEnumerable`1[T] assemblyNames) [0x000f2] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xtro-sharpie/Runner.cs:41
12:55:31.4684400 at Extrospection.MainClass.Main (System.String[] args) [0x00046] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xtro-sharpie/Program.cs:20
https://jenkins.mono-project.com/job/xamarin-macios-pr-builder/5845/Test_Report/
Short story: PR #3096 adds **non public** attributes without a namespace
so they take precedence over existing ones.
xtro enum check also needed to discard them.
- XamarinPreprocessorVisitor handled processing/generating availability
attributes but needs to be removed as it depends on PMCS
- Because processing was handled at a preprocessor/token level before and
now inside generator.cs a number of changes were needed avoid checking
in a million line diff (literally)
- This commit creates a "shadow" set of availability attributes, with
the desired names [Mac] [Watch] [NoTV], etc when not in existence before
- Instead of adding hundreds of using statements to force resolution of these
shadow types, I abuse C# type resolution by storing them in the root
(not namespaced) so they are resolved first.
- generator-attributes-manager was taught how to process the multitude of
old-style attributes and how to generate the new-style attributes
- Generator's bug57070 is no longer valid, since we _can_ and do convert [iOS]
We can't trust Apple's native linker to pick the right (non private)
framework when an older TargetVersion is used. It just prefer what's
available - even if specified with a WeakFramework :(
That was already dealt with for applications. However the native linking
of the Xamarin.Sdk.framework (code sharing with extensions) is done with
the `LinkTask` instead of the `NativeLinkTask` so it did not have the
"auto correct" code.
Unit test added.
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=61039
We can't trust Apple's native linker to pick the right (non private)
framework when an older TargetVersion is used. It just prefer what's
available - even if specified with a WeakFramework :(
That was already dealt with for applications. However the native linking
of the Xamarin.Sdk.framework (code sharing with extensions) is done with
the `LinkTask` instead of the `NativeLinkTask` so it did not have the
"auto correct" code.
Unit test added.
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=61039
According to documentation this was added in watchOS 4.0
xtro reported:
!missing-pinvoke! vImageBoxConvolve_ARGB8888 is not bound
!missing-pinvoke! vImageBoxConvolve_Planar8 is not bound
!missing-pinvoke! vImageConvolve_ARGB8888 is not bound
!missing-pinvoke! vImageConvolve_ARGBFFFF is not bound
!missing-pinvoke! vImageConvolve_Planar8 is not bound
!missing-pinvoke! vImageConvolve_PlanarF is not bound
!missing-pinvoke! vImageConvolveMultiKernel_ARGB8888 is not bound
!missing-pinvoke! vImageConvolveMultiKernel_ARGBFFFF is not bound
!missing-pinvoke! vImageConvolveWithBias_ARGB8888 is not bound
!missing-pinvoke! vImageConvolveWithBias_ARGBFFFF is not bound
!missing-pinvoke! vImageConvolveWithBias_Planar8 is not bound
!missing-pinvoke! vImageConvolveWithBias_PlanarF is not bound
!missing-pinvoke! vImageMatrixMultiply_ARGB8888 is not bound
!missing-pinvoke! vImageRichardsonLucyDeConvolve_ARGB8888 is not bound
!missing-pinvoke! vImageRichardsonLucyDeConvolve_ARGBFFFF is not bound
!missing-pinvoke! vImageRichardsonLucyDeConvolve_Planar8 is not bound
!missing-pinvoke! vImageRichardsonLucyDeConvolve_PlanarF is not bound
!missing-pinvoke! vImageTentConvolve_ARGB8888 is not bound
!missing-pinvoke! vImageTentConvolve_Planar8 is not bound
Beside eliminating a bit of code duplication this solve the random
(metadata order) xtro report
> ?unknown-entry? !unknown-pinvoke! close bound in 'macOS-ObjCRuntime.ignore'
because it was reported against two namespaces and we don't check
for duplicate p/invokes (largely because there's tons of them in
OpenTK)
Fixes https://github.com/xamarin/maccore/issues/602
The original test was to cover both X509Certificate and X509Certiicate2
when using with SecTrust. However the code diverged over time. That and
the different certificates used caused the `*2` tests to hit a time
loop (designed to reduce incorrect errors randomly reported).
We want to keep the "delay" logic for it's intended purpose - but it
should not be needed normally.
The tests have been refactored to reuse the same logic (between both
types of certificates) which solve this (when used with the same
certificates)
Replace https://github.com/xamarin/xamarin-macios/pull/3068
When a method signature contains any ref/out parameters
it is a hint that this method is not a candidate to be
used with [Async] we now error BI1062 in the generator.
The reason of an error instead of a warning is that we
currently generate not compilable code when ref/out is
used on the method signature or in the signature of the
delegate (completion handler), it is very unlikely we are
breaking someone now that we emit an error instead of broken
code.
* Fix Anchor and Clarify the addition of BI1117 Warning into docs/website/generator-errors.md
BI1117 Warning documentation was missing from docs/website/generator-errors.md
so I added it.
* Not every old annotations have been migrated (work in progress, to be completed in another PR);
* Sanitation of the data files (e.g. removal of dupes and fixed, by Apple, entries) is done, but not automated (also a work in progress)
Even then this is immediately useful, i.e. better merged before 15.6 gets branched.
* [Debugger] Allow to step into Xamarin code.
The tool now detects the different sources and mangles the path to
ensure that the correct paths are installed in the following location:
/Library/Frameworks/Xamarin.iOS/Versions/Current/src
/Library/Frameworks/Xamarin.Mac/Versions/Current/src
The tool will detect if the path map command was used in the mdb and pub files, will point to the correct source code and will copy it to the installation dir.
Tests have been added that will be ran both by wrench and jenkins ensuring that changes in the manglers do not change it behaviour.
Facts:
* xtro-sharpie references Mono.Cecil 0.9.6 from a nuget.
* If a local Mono.Cecil.dll can't be found (according to the HintPath in the
csproj, which points to the nuget), then msbuild will look in the system
Mono.
* Mono 5.8 ships Mono.Cecil 0.10.
* Mono.Cecil 0.10 is not source compatible with 0.9.6 (there's a small issue
with interfaces).
* xtro-sharpie's source code works with v0.10.
This all means that xtro-sharpie will build fine as long as the 0.9.6 nuget
has *not* been restored. This can manifest itself confusingly ("msbuild xtro-
sharpie.sln" works fine from the command line, open the solution in VSfM and
it doesn't build anymore, not even from the command line, because VSfM
automatically restored nugets in the background).
Update the source code to work with Mono.Cecil 0.9.6 because there's no 0.10
nuget yet (yet keeping the code for v0.10 clearly marked as such for future
updates to v0.10).
Also bump from 0.9.6.1 to 0.9.6.4 since that's the latest available.
Rolf Bjarne Kvinge
Manuel de la Pena
Sebastien Pouliot
Alex Soto
Vincent Dondain
Chris Hamons
Alex Soto
Jeffrey Stedfast
Timothy Risi