[xcode27.0] Baseline update for Xcode 27.0 Beta 1#25665
Conversation
…deployment target to 15.0
Update .NET for iOS, tvOS, macOS and Mac Catalyst to build against the
Xcode 27.0 beta SDK, and address every issue required to make `make world`
succeed cleanly with the new SDK.
Version bumps (26.5 -> 27.0):
* Make.config: XCODE_VERSION, XCODE_URL and XCODE_DEVELOPER_ROOT now point at
the Xcode 27.0 beta, and NUGET_HARDCODED_PRERELEASE_IDENTIFIER/_BRANCH are
set to xcode27.0.
* Make.versions: {IOS,TVOS,MACOS,MACCATALYST}_NUGET_OS_VERSION -> 27.0.
* tools/common/SdkVersions.cs: regenerated from SdkVersions.in.cs with the new
Xcode/SDK and executable/deployment-target versions.
* builds/Versions-{iOS,tvOS,macOS,MacCatalyst}.plist.in: add 27.0 to
KnownVersions and SupportedTargetPlatformVersions; add the 27.0 -> 27.0
entry to MacCatalystVersionMap (so the macOS<->Mac Catalyst version mapping
resolves, avoiding MX0184 when building Mac Catalyst apps).
* tools/devops/automation/templates/variables/common.yml: set xcodeChannel to
Beta for the beta build.
Raise the iOS and tvOS minimum deployment target from 12.2 to 15.0:
* The Xcode 27 iOS/tvOS SDKs declare 15.0 as their minimum supported
deployment target (SDKSettings.plist MinimumDeploymentTarget, and
ValidDeploymentTargets starts at 15.0). In addition, libc++ now emits
"The selected platform is no longer supported by libc++" for deployment
targets below 15.0; because the native runtime is compiled with -Werror,
this turned into a hard build error for the previous 12.2 minimum.
* Make.config: MIN_IOS_SDK_VERSION, MIN_TVOS_SDK_VERSION,
DOTNET_MIN_IOS_SDK_VERSION and DOTNET_MIN_TVOS_SDK_VERSION -> 15.0 (these
flow into the regenerated constants in SdkVersions.cs).
* builds/Versions-{iOS,tvOS}.plist.in: trim the now-unsupported sub-15.0
entries from KnownVersions (consistency is enforced by
scripts/versions-check). The SupportedTargetPlatformVersions arrays are
intentionally left untouched: they drive the IOSX_Y_OR_GREATER
conditional-compilation symbols and must retain the historical versions.
* dotnet/Templates: bump the default SupportedOSPlatformVersion in the iOS
(13.0 -> 15.0) and tvOS (12.2 -> 15.0) project templates to match the new
minimum.
* macOS (12.0) and Mac Catalyst (15.0) minimums are unchanged (they already
sit at or above the Xcode 27 SDK floor).
runtime/trampolines.m: replace the deprecated method_getDescription with
method_getTypeEncoding. method_getDescription was marked deprecated in the
Xcode 27 SDK ("first deprecated in macOS 11.0 - Use method_getName and
method_getTypeEncoding"), and -Werror/-Wdeprecated-declarations turned the
call into a build error. We only ever consumed the method description's
`types` field, which method_getTypeEncoding returns directly, so the behaviour
is unchanged.
scripts/generate-vs-workload/generate-vs-workload.cs: fix the .NET 10 MSI
version computation, which crashed on Xcode 27. The minor-version bump was
computed as `new Version (26 - xcodeMajor, xcodeMinor)`, which is negative for
Xcode >= 27 and throws in the System.Version constructor (Abort trap 6),
breaking vs-workload.props generation. Compute it directly as
`(xcodeMajor - 26) * 10 + xcodeMinor`: this is identical to the old result for
the 26.x series, increases monotonically as Xcode advances, and stays within
the Windows Installer minor-version ceiling (255) across .NET 10's supported
Xcode range (26-28). The version scheme is now documented in detail.
src/Makefile: skip AppleDocReader documentation injection when the Xcode
offline documentation cache is unavailable. Xcode 27 no longer ships the
SQLite documentation cache (cache.db) that AppleDocReader reads; that
directory now contains only a "deleted" tombstone, and documentation is
instead downloaded on demand into a CoreSpotlight index that is non-hermetic
(absent on clean/CI machines) and has no public read API. A new
capability-based ENABLE_APPLE_DOC_READER gate detects the absence of the
legacy cache and falls back to copying the generated XML documentation through
unchanged (the same behaviour as the existing NO_XCODE path), emitting a clear
warning. This only affects whether <appledoc> links are injected; the XML
documentation is otherwise complete. Re-implementing enrichment against a
hermetic source (e.g. Apple's online DocC render JSON, which still carries the
Clang USR we key on) should be tracked separately.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…minimum
After raising the iOS and tvOS minimum deployment target to 15.0, every
[SupportedOSPlatform ("ios<ver>")] / ("tvos<ver>") attribute whose version is
<= 15.0 became redundant in the manual (strongly-typed) binding source files.
Unlike the attributes bgen generates from [iOS (X, Y)] / [TV (X, Y)] - which it
strips automatically when the version is <= the platform's minimum deployment
target (see GenerateSupported in src/bgen/Attributes.cs) - these hand-written
literal attributes are emitted verbatim. That made the cecil-tests
ApiAvailabilityTest.AttributeConsistency test fail for the iOS and tvOS
reference assemblies (it treats any SupportedOSPlatform version <= the minimum
as an error).
Strip the redundant version while keeping the platform marker, e.g.
[SupportedOSPlatform ("ios13.0")] -> [SupportedOSPlatform ("ios")], leaving
versions > 15.0 and the macOS/Mac Catalyst attributes untouched.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Azure Pipelines successfully started running 3 pipeline(s). |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
MLaunchTool builds an mlaunch '--device:' argument from a hardcoded simulator
device type (iPhone-SE for iOS, Apple-TV-1080p for tvOS) combined with
Configuration.sdk_version. Both of those device types were removed in the
Xcode 27 simulator runtimes:
iPhone-SE + iOS-27-0 => error 403 "Incompatible device"
Apple-TV-1080p + tvOS-27-0 => error 403 "Incompatible device"
Make the device type version-aware, gated on the same Configuration.sdk_version
that's used to build the runtime string: for iOS/tvOS 27+ use iPhone-14 and
Apple-TV-4K-3rd-generation-4K respectively, and keep the previous device types
for older SDKs so behavior is unchanged there.
Verified on macOS 26.5 with Xcode 27: the previous device types fail to create
on the 27 runtimes while iPhone-14 / Apple-TV-4K-3rd-generation-4K create
successfully; the legacy types still create on the older (tvOS 16/26.5)
runtimes.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This comment has been minimized.
This comment has been minimized.
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
…d accessors When a smart-enum member carries a [SupportedSimulator] or [UnsupportedSimulator] attribute, bgen emitted the platform availability attributes on the generated *Extensions field accessor but dropped the simulator availability attributes. The attribute therefore never reached the generated API, so the introspection simulator-availability test could not see it. This surfaced with CoreMedia's kCMSampleAttachmentKey_HDR10PlusPerFrameData, which is declared available at iOS/tvOS 16.0 but is only present in the simulator runtimes of a later release: the [SupportedSimulator] annotation on the smart-enum member was silently discarded. Emit PrintSimulatorAvailabilityAttributes (f) alongside the existing PrintPlatformAttributes (f) call in the smart-enum field-accessor loop so the simulator attributes are propagated like the platform ones. Add a regression test: a smart enum with a [SupportedSimulator]-annotated [Field] member asserts the attribute lands on the generated *Extensions accessor for the active profile (iOS -> ios17.0, tvOS -> tvos17.0), that a plain member gets none, and that Mac profiles emit none. The test fails (Expected 1 / But was 0) without the one-line generator change. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…S minimum
Raising the iOS/tvOS minimum deployment target to 15.0 raised the minimum
simulator the introspection tests run on to 16.0. Several APIs that are declared
available at an early version are not actually present in those older simulator
runtimes (they ship on device and/or in newer simulators only), so the
introspection simulator-availability test started failing on the 16.0
configurations while the 27.0 configurations passed.
Annotate the affected APIs with the appropriate simulator availability
attributes (verified against the actual simulator runtime binaries with nm):
* SafetyKit SACrashDetectionEvent / SACrashDetectionManager /
SAEmergencyResponseManager: device-only Crash Detection; the framework was
only added to the iOS simulator later -> [SupportedSimulator ("ios18.0")].
* CoreMedia HDR10+ (kCMSampleAttachmentKey_HDR10PlusPerFrameData), both the
interface property and the smart-enum member: absent in the iOS 16 / tvOS 16
simulators, present in iOS 18.5 / tvOS 26.4 ->
[SupportedSimulator ("ios18.0")] + [SupportedSimulator ("tvos26.0")].
* tvOS Metal acceleration-structure / mesh / rasterization types: absent in the
tvOS 16 simulator, present in tvOS 26.4 -> [SupportedSimulator ("tvos26.0")].
* Metal MTLIOCompressionContext* P/Invokes: present in the iOS 16 / tvOS 16
simulators but removed in 18.0+; the previous version-less
[UnsupportedSimulator] was wrong for the 16.0 simulators (where the symbols
exist) -> versioned [UnsupportedSimulator ("ios18.0")] +
[UnsupportedSimulator ("tvos18.0")].
To make the versioned [UnsupportedSimulator] meaningful:
* tests/common/PlatformInfo.IsAvailableInSimulator now interprets a versioned
[UnsupportedSimulator] ("ios18.0") as "unavailable starting with that
simulator version" (Host.Version >= version), mirroring the existing versioned
[SupportedSimulator] handling. A bare platform name ("ios") keeps its previous
meaning of "unavailable on every simulator version".
* The linker's DerivedLinkContext.HasAvailabilityAttributesShowingUnavailableIn-
Simulator now prefix-matches [UnsupportedSimulator] platform names (like the
existing [SupportedSimulator] pass). A versioned [UnsupportedSimulator] cannot
be evaluated against a single build-time deployment target, so it is treated
conservatively as "unavailable" and the simulator inlining optimization is
skipped, falling back to the runtime symbol lookup (already weak +
dlsym-guarded). Bare platform names behave exactly as before.
The CoreMedia HDR10+ smart-enum member relies on the preceding bgen fix to carry
its [SupportedSimulator] attribute to the generated accessor.
Validated by running the introspection tests on iOS 16.0/27.0 and
tvOS 16.0/27.0 simulators: all four configurations pass with no failures.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…a hang SecProtocolMetadataTest.TlsDefaults starts an NWConnection on a DispatchQueue created with a 'using' block and registers a state-change handler that disposes the connection when it reaches the Cancelled/Failed state. The handler runs on that queue, but the test disposed the queue (leaving the 'using' scope) without waiting for the asynchronous cancellation to complete, and skipped the trailing Cancel () entirely whenever Assert.Fail / IgnoreInCI threw. The cancellation callback could therefore still be pending - and run on a disposed queue - long after the test finished, contributing to a process-wide hang on the macOS test run (observed as a ~20 minute timeout / "Test run crashed"). Wrap the body in try/finally and signal a ManualResetEvent from the Cancelled/Failed branch of the handler. The finally cancels the connection and waits (bounded to 10s) for that event before the queue is disposed, on every path (success, the Assert.Fail, an assertion failure inside the inner 'using', and the IgnoreInCI case). Cancel () is guarded against ObjectDisposedException so that, if the connection already failed on its own and the handler disposed it, the original test failure is preserved instead of being masked. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
✅ [PR Build #3921131] Build passed (Detect API changes) ✅Pipeline on Agent |
This comment has been minimized.
This comment has been minimized.
|
🔥 Failed to compare API and create generator diff 🔥 Error: The system requirements for the hash to compare against (4c9e983) are different than for the current hash. Comparison is currently not supported in this scenario. Pipeline on Agent |
✅ [PR Build #3921131] Build passed (Build packages) ✅Pipeline on Agent |
✅ [PR Build #3921131] Build passed (Build macOS tests) ✅Pipeline on Agent |
This comment has been minimized.
This comment has been minimized.
🔥 [CI Build #3921131] Test results 🔥Test results❌ Tests failed on VSTS: test results 1 tests crashed, 0 tests failed, 188 tests passed. Failures❌ windows tests🔥 Failed catastrophically on VSTS: test results - windows (no summary found). Html Report (VSDrops) Download Successes✅ cecil: All 1 tests passed. Html Report (VSDrops) Download macOS tests✅ Tests on macOS Monterey (12): All 5 tests passed. Html Report (VSDrops) Download Linux Build VerificationPipeline on Agent |
No description provided.