ClangImporter: enhance the importer to alias declarations #81840

compnerd · 2025-05-29T17:56:24Z

Import simple CPP macro aliases as aliases in Swift. Extend the macro importer to import the following construct:

#define alias aliasee

as the following Swift construct:

@_transparent @inline(__always)
var alias: type(of: aliasee) {
  aliasee
}

This improves the QoI for Windows where there is a universal define (UNICODE) which normally is used for translating APIs between ANSI and Unicode variants, e.g.:

#if defined(UNICODE)
#define MessageBox MessageBoxW
#else
#define MessageBox MessageBoxA
#endif

compnerd · 2025-05-29T17:56:40Z

@swift-ci please smoke test

egorzhdan

This is exciting, thanks!

test/ClangImporter/Inputs/custom-modules/Aliases.h

compnerd · 2025-05-29T21:13:50Z

@swift-ci please smoke test

al45tair

Nice; this will be a huge quality of life improvement for Windows development.

lib/ClangImporter/ImportMacro.cpp

egorzhdan

LGTM modulo Alastair's question

compnerd · 2025-05-30T16:05:52Z

@swift-ci please smoke test Linux platform

compnerd · 2025-05-30T19:28:30Z

@swift-ci please test Windows platform

compnerd · 2025-06-01T02:39:52Z

@swift-ci please test Windows platform

compnerd · 2025-06-02T05:36:11Z

@swift-ci please smoke test

compnerd · 2025-06-02T15:33:20Z

@swift-ci please smoke test

compnerd · 2025-06-06T02:16:35Z

@swift-ci please smoke test

compnerd · 2025-06-06T04:27:47Z

20:49:21   154 |     var endTime = timespec(tv_sec: 0, tv_nsec: 0)
20:49:21   155 | 
20:49:21   156 |     clock_gettime(CLOCK_MONOTONIC, &startTime)
20:49:21       |                   `- error: ambiguous use of 'CLOCK_MONOTONIC'
20:49:21   157 |     body()
20:49:21   158 |     clock_gettime(CLOCK_MONOTONIC, &endTime)
20:49:21  
20:49:21  _time.CLOCK_MONOTONIC:2:12: note: found this candidate in module '_time'
20:49:21  1 | @available(macOS 10.12, *)
20:49:21  2 | public var CLOCK_MONOTONIC: clockid_t { get }
20:49:21    |            `- note: found this candidate in module '_time'
20:49:21  
20:49:21  _time.CLOCK_MONOTONIC:1:12: note: found this candidate in module '_time'
20:49:21  1 | public var CLOCK_MONOTONIC: clockid_t { get }
20:49:21    |            `- note: found this candidate in module '_time'
20:49:21

Looking at /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/_time.h, we see:

typedef enum {
_CLOCK_REALTIME __CLOCK_AVAILABILITY = 0,
#define CLOCK_REALTIME _CLOCK_REALTIME
_CLOCK_MONOTONIC __CLOCK_AVAILABILITY = 6,
#define CLOCK_MONOTONIC _CLOCK_MONOTONIC
#if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE)
_CLOCK_MONOTONIC_RAW __CLOCK_AVAILABILITY = 4,
#define CLOCK_MONOTONIC_RAW _CLOCK_MONOTONIC_RAW
_CLOCK_MONOTONIC_RAW_APPROX __CLOCK_AVAILABILITY = 5,
#define CLOCK_MONOTONIC_RAW_APPROX _CLOCK_MONOTONIC_RAW_APPROX
_CLOCK_UPTIME_RAW __CLOCK_AVAILABILITY = 8,
#define CLOCK_UPTIME_RAW _CLOCK_UPTIME_RAW
_CLOCK_UPTIME_RAW_APPROX __CLOCK_AVAILABILITY = 9,
#define CLOCK_UPTIME_RAW_APPROX _CLOCK_UPTIME_RAW_APPROX
#endif
_CLOCK_PROCESS_CPUTIME_ID __CLOCK_AVAILABILITY = 12,
#define CLOCK_PROCESS_CPUTIME_ID _CLOCK_PROCESS_CPUTIME_ID
_CLOCK_THREAD_CPUTIME_ID __CLOCK_AVAILABILITY = 16
#define CLOCK_THREAD_CPUTIME_ID _CLOCK_THREAD_CPUTIME_ID
} clockid_t;

Looking at /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/_time.apinotes, we see:

Name: _time
Enumerators:
- Name: _CLOCK_MONOTONIC
  SwiftName: CLOCK_MONOTONIC

With this change we would now synthesize the following:

var CLOCK_MONOTONIC: CInt {
  _CLOCK_MONOTONIC
}

But due to the APINotes, we would import _CLOCK_MONOTONIC as CLOCK_MONOTONIC, resulting in this clash.

al45tair · 2025-06-06T11:13:57Z

With this change we would now synthesize the following:
var CLOCK_MONOTONIC: CInt {
  _CLOCK_MONOTONIC
}
But due to the APINotes, we would import _CLOCK_MONOTONIC as CLOCK_MONOTONIC, resulting in this clash.

:-(

It would be much easier if we could fix the compiler to tolerate that somehow, rather than having to change the API notes file. Would @_disfavouredOverload work to fix this? Or is that going to cause other problems. Alternatively, I wonder if we can look up in the API notes and ignore things that are already listed there?

compnerd · 2025-06-06T16:15:37Z

@swift-ci please smoke test Linux platform

hnrklssn · 2025-06-06T18:07:49Z

The APINotes have already been applied by clang before we import the nodes, right? It seems to me like we should be able to inspect the aliased clang decl and check for swift_name attributes that clash with the macro name.

lib/ClangImporter/ImportMacro.cpp

compnerd · 2025-06-06T20:09:37Z

@swift-ci please smoke test

compnerd · 2025-06-06T21:26:45Z

@swift-ci please smoke test

compnerd · 2025-06-07T01:24:20Z

@swift-ci please test windows platform

compnerd · 2025-06-07T01:24:45Z

@swift-ci please smoke test macOS platform

compnerd · 2025-06-07T06:03:17Z

@swift-ci please smoke test macOS platform

compnerd · 2025-06-07T15:09:06Z

@swift-ci please smoke test macOS platform

compnerd · 2025-06-07T17:47:38Z

@swift-ci please smoke test macOS platform

When building on non-Darwin targets, we are not guaranteed that there is no ICU library on the system (Windows ships an ICU since Windows 1703 (RedStone 2), SDK 10.0.15063. This now is implicitly pulled in OneCore.lib which vends the memory API contract; Linux normally ships a copy of ICU; android ships a copy of ICU since Android 6.0 (API Level 23) but is not part of the supported APIs). The availability of ICU on the system and in Swift causes a conflict. As there is no stable ABI for ICU, this is a problem and can cause spurious failures. Such a failure has been observed on Windows when statically linking Foundation. Unfortunately, the symbol renaming support in ICU relies on the `U_ICU_ENTRY_POINT_RENAME` macro which is defined thusly: ``` #define U_DEF_ICU_ENTRY_POINT_RENAME(x, y, z) x ## y ## z #define U_DEF2_ICU_ENTRY_POINT_RENAME(x, y, z) U_DEF_ICU_ENTRY_POINT_RENAME(x, y, z) #define U_ICU_ENTRY_POINT_RENAME(name) U_DEF2_ICU_ENTRY_POINT_RENAME(name, ICU_VERSION_SUFFIX, U_LIB_SUFFIX_C_NAME) ``` This macro is too complex for the clang importer to import into Swift, making this not possible to use directly. Instead, we manually perform the expansion of the CPP macros, using the `swift_` prefix instead to isolate and namespace our implementation. Unfortunately, even the aliasing macro is too complex for the clang importer to import directly. Because changing all the call sites would not be tractable (nor maintainable), this will require an additional change (swiftlang/swift#81840) to support aliasing macros to be imported into Swift. Although this change currently only enables the symbol renaming on static builds, once everything is merged and tested, it should be safe to control this behaviour on all non-Darwin targets. The change to the static linking targets solves the immediate problem on Windows where the early swift-driver implicitly will pick up the system ICU and fault at runtime. Although in theory only the dynamically linked version should be susceptible to the interpositioning issue, if any of the system libraries causes ICU to be included (e.g. a linker script on Unix or an import library pulling in another version), we can also hit this issue in the statically linked scenario. When dynamically linking, on Windows at least, it would not be a problem if the symbol is bound properly at link time as the symbolic resolution involves two-level namespacing, which is not available on ELF hosts. On Darwin, we cannot perform the renaming as the library is vended by the system and this would constitute an ABI break.

When building on non-Darwin targets, we are not guaranteed that there is no ICU library on the system (Windows ships an ICU since Windows 1703 (RedStone 2), SDK 10.0.15063. This now is implicitly pulled in OneCore.lib which vends the memory API contract; Linux normally ships a copy of ICU; android ships a copy of ICU since Android 6.0 (API Level 23) but is not part of the supported APIs). The availability of ICU on the system and in Swift causes a conflict. As there is no stable ABI for ICU, this is a problem and can cause spurious failures. Such a failure has been observed on Windows when statically linking Foundation. Unfortunately, the symbol renaming support in ICU relies on the `U_ICU_ENTRY_POINT_RENAME` macro which is defined thusly: ``` #define U_DEF_ICU_ENTRY_POINT_RENAME(x, y, z) x ## y ## z #define U_DEF2_ICU_ENTRY_POINT_RENAME(x, y, z) U_DEF_ICU_ENTRY_POINT_RENAME(x, y, z) #define U_ICU_ENTRY_POINT_RENAME(name) U_DEF2_ICU_ENTRY_POINT_RENAME(name, ICU_VERSION_SUFFIX, U_LIB_SUFFIX_C_NAME) ``` This macro is too complex for the clang importer to import into Swift, making this not possible to use directly. Instead, we manually perform the expansion of the CPP macros, using the `swift_` prefix instead to isolate and namespace our implementation. Unfortunately, even the aliasing macro is too complex for the clang importer to import directly. Because changing all the call sites would not be tractable (nor maintainable), this will require an additional change (swiftlang/swift#81840) to support aliasing macros to be imported into Swift. Although in theory only the dynamically linked version should be susceptible to the interpositioning issue, if any of the system libraries causes ICU to be included (e.g. a linker script on Unix or an import library pulling in another version), we can also hit this issue in the statically linked scenario. When dynamically linking, on Windows at least, it would not be a problem if the symbol is bound properly at link time as the symbolic resolution involves two-level namespacing, which is not available on ELF hosts. On Darwin, we cannot perform the renaming as the library is vended by the system and this would constitute an ABI break.

compnerd · 2025-06-08T04:34:06Z

@swift-ci please smoke test

compnerd · 2025-06-08T17:15:44Z

@swift-ci please smoke test

@inline

Import simple CPP macro aliases as aliases in Swift. Extend the macro importer to import the following construct: ``` #define alias aliasee ``` as the following Swift construct: ``` @_transparent @inline(__always) var alias: type(of: aliasee) { aliasee } ``` This improves the QoI for Windows where there is a universal define (`UNICODE`) which normally is used for translating APIs between ANSI and Unicode variants, e.g.: ``` #if defined(UNICODE) #define MessageBox MessageBoxW #else #define MessageBox MessageBoxA #endif ``` Global variables which are non-const also have a setter synthesized: ``` @_transparent @inline(__always) var alias: type(of: aliasee) { get { return aliasee } set { aliasee = newValue } } ```

compnerd · 2025-06-08T19:45:53Z

@swift-ci please smoke test

kateinoigakukun · 2025-06-12T09:32:26Z

@compnerd I noticed that the latest nightly toolchain seems to have introduced an issue with import var Darwin.stderr on macOS SDK, and I guess this change might be related. Could you please take a look when you have a chance? Thanks in advance!

$ printf "import var Darwin.stderr\n" | /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2025-06-09-a.xctoolchain/usr/bin/swiftc -typecheck - -sdk $(xcrun --show-sdk-path)
<stdin>:1:12: error: ambiguous name 'stderr' in module 'Darwin'
1 | import var Darwin.stderr
  |            `- error: ambiguous name 'stderr' in module 'Darwin'
2 |

_stdio.stderr:2:12: note: found this candidate
1 | @available(macOS 10.9, iOS 7.0, watchOS 2.0, tvOS 9.0, visionOS 1.0, *)
2 | public var stderr: UnsafeMutablePointer<FILE> { get set }
  |            `- note: found this candidate

_stdio.stderr:1:12: note: found this candidate
1 | public var stderr: UnsafeMutablePointer<FILE> { get set }
  |            `- note: found this candidate

@available

This reverts commit 33a324e, reversing changes made to 0afeafa due to a regression: ``` $ printf "import var Darwin.stderr\n" | /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2025-06-09-a.xctoolchain/usr/bin/swiftc -typecheck - -sdk $(xcrun --show-sdk-path) <stdin>:1:12: error: ambiguous name 'stderr' in module 'Darwin' 1 | import var Darwin.stderr | `- error: ambiguous name 'stderr' in module 'Darwin' 2 | _stdio.stderr:2:12: note: found this candidate 1 | @available(macOS 10.9, iOS 7.0, watchOS 2.0, tvOS 9.0, visionOS 1.0, *) 2 | public var stderr: UnsafeMutablePointer<FILE> { get set } | `- note: found this candidate _stdio.stderr:1:12: note: found this candidate 1 | public var stderr: UnsafeMutablePointer<FILE> { get set } | `- note: found this candidate ``` # Conflicts: # test/ClangImporter/Inputs/custom-modules/module.modulemap

compnerd requested review from zoecarver, egorzhdan, beccadax, ian-twilightcoder, Xazax-hun, j-hui, fahadnayyar and susmonteiro as code owners May 29, 2025 17:56

egorzhdan reviewed May 29, 2025

View reviewed changes

test/ClangImporter/Inputs/custom-modules/Aliases.h Show resolved Hide resolved

egorzhdan added the c++ interop Feature: Interoperability with C++ label May 29, 2025

compnerd force-pushed the aliases branch from ce6ef71 to 6bba78d Compare May 29, 2025 21:13

compnerd requested a review from egorzhdan May 29, 2025 21:13

compnerd added clang importer Area → compiler: The clang importer c/c++ macros labels May 29, 2025

al45tair reviewed May 30, 2025

View reviewed changes

lib/ClangImporter/ImportMacro.cpp Show resolved Hide resolved

egorzhdan approved these changes May 30, 2025

View reviewed changes

compnerd force-pushed the aliases branch from 6bba78d to 10fa705 Compare May 30, 2025 16:05

compnerd force-pushed the aliases branch from 10fa705 to dba9103 Compare May 30, 2025 19:27

compnerd force-pushed the aliases branch from dba9103 to a7aed49 Compare June 1, 2025 02:39

compnerd force-pushed the aliases branch from a7aed49 to 5b01430 Compare June 2, 2025 05:35

al45tair approved these changes Jun 2, 2025

View reviewed changes

compnerd force-pushed the aliases branch from 5b01430 to d412ed7 Compare June 2, 2025 15:30

compnerd force-pushed the aliases branch from d412ed7 to 58fbff5 Compare June 2, 2025 16:31

hnrklssn reviewed Jun 6, 2025

View reviewed changes

lib/ClangImporter/ImportMacro.cpp Show resolved Hide resolved

hnrklssn reviewed Jun 6, 2025

View reviewed changes

lib/ClangImporter/ImportMacro.cpp Show resolved Hide resolved

compnerd force-pushed the aliases branch from 7ce0fe7 to 1da10c3 Compare June 6, 2025 20:09

compnerd force-pushed the aliases branch from 1da10c3 to 486e5b9 Compare June 6, 2025 21:26

compnerd mentioned this pull request Jun 8, 2025

_FoundationUnicode: apply symbol renaming for non-Darwin targets swiftlang/swift-foundation-icu#63

Open

compnerd force-pushed the aliases branch from 486e5b9 to e0a79ea Compare June 8, 2025 04:33

compnerd force-pushed the aliases branch from e0a79ea to 0a31daf Compare June 8, 2025 04:45

compnerd force-pushed the aliases branch from 0a31daf to c66d43e Compare June 8, 2025 19:45

compnerd merged commit 33a324e into swiftlang:main Jun 9, 2025
3 checks passed

compnerd deleted the aliases branch June 9, 2025 01:07

ClangImporter: enhance the importer to alias declarations #81840

ClangImporter: enhance the importer to alias declarations #81840

Uh oh!

Conversation

compnerd commented May 29, 2025

Uh oh!

compnerd commented May 29, 2025

Uh oh!

egorzhdan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

compnerd commented May 29, 2025

Uh oh!

al45tair left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

egorzhdan left a comment

Choose a reason for hiding this comment

Uh oh!

compnerd commented May 30, 2025

Uh oh!

compnerd commented May 30, 2025

Uh oh!

compnerd commented Jun 1, 2025

Uh oh!

compnerd commented Jun 2, 2025

Uh oh!

compnerd commented Jun 2, 2025

Uh oh!

compnerd commented Jun 6, 2025

Uh oh!

compnerd commented Jun 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

al45tair commented Jun 6, 2025

Uh oh!

compnerd commented Jun 6, 2025

Uh oh!

hnrklssn commented Jun 6, 2025

Uh oh!

Uh oh!

Uh oh!

compnerd commented Jun 6, 2025

Uh oh!

compnerd commented Jun 6, 2025

Uh oh!

compnerd commented Jun 7, 2025

Uh oh!

compnerd commented Jun 7, 2025

Uh oh!

compnerd commented Jun 7, 2025

Uh oh!

compnerd commented Jun 7, 2025

Uh oh!

compnerd commented Jun 7, 2025

Uh oh!

compnerd commented Jun 8, 2025

Uh oh!

compnerd commented Jun 8, 2025

Uh oh!

compnerd commented Jun 8, 2025

Uh oh!

Uh oh!

kateinoigakukun commented Jun 12, 2025

Uh oh!

Uh oh!

compnerd commented Jun 6, 2025 •

edited

Loading