Rename pointer bounds

[hnrklssn]

Renames the @PointerBounds macro to @_SwiftifyImport and makes it generally available in the standard library. The API is expected to change drastically without accompanying release notes or backwards compatibility, as the macro is intended to be applied by ClangImporter only, which will be updated in tandem with the macro.

[hnrklssn]

@swift-ci please smoke test

[hnrklssn]

@swift-ci please smoke test

[DougGregor]

LGTM, thanks!

[hnrklssn]

@swift-ci please smoke test

[hnrklssn]

I took the liberty of not adding @available to _PointerParam, since it's not really intended to be "available" at runtime, only for passing info to the macro. Please let me know if that has any consequences I'm not aware of. @DougGregor @Xazax-hun

[hnrklssn]

@swift-ci please smoke test

[tshortli]

I took the liberty of not adding @available to _PointerParam, since it's not really intended to be "available" at runtime, only for passing info to the macro. Please let me know if that has any consequences I'm not aware of.

Availability is needed on every declaration that might be linked by a separate executable (so that the compiler can generate correct linkage relative to the deployment target of the executable for the symbols). Even if the only separate executables that reference it are macro plugins, I think it may still be appropriate to have accurate availability.

[hnrklssn]

I took the liberty of not adding @available to _PointerParam, since it's not really intended to be "available" at runtime, only for passing info to the macro. Please let me know if that has any consequences I'm not aware of.

Availability is needed on every declaration that might be linked by a separate executable (so that the compiler can generate correct linkage relative to the deployment target of the executable for the symbols). Even if the only separate executables that reference it are macro plugins, I think it may still be appropriate to have accurate availability.

How does this work for the stdlib? If I simply try adding @available(SwiftStdlib 6.1, *) to _PointerParam, then I get an error saying error: '_PointerParam' is only available in macOS 9999 or newer when building the stdlib for the host OS. I thought custom built swiftc was supposed to build with availability for all releases?

[hnrklssn]

@swift-ci please test linux

[hnrklssn]

Could this test failure actually be related to my changes?

FAIL: test_command_stats_force (TestStatisticsAPI.TestStatsAPI)
   Test reporting all pssible debug info stats by force loading all debug
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/build-user/llvm-project/lldb/test/API/functionalities/stats_api/TestStatisticsAPI.py", line 151, in test_command_stats_force
    self.assertEqual(debug_stats["totalDebugInfoByteSize"], 193)
AssertionError: 386 != 193

It doesn't seem like something that should be affected, but maybe I'm missing something. It seems like other PRs are passing fine.

[Xazax-hun]

Could this test failure actually be related to my changes?

I remember seeing this on other PRs. I think you should just rerun the tests, hopefully should be fixed by now.

[tshortli]

How does this work for the stdlib? If I simply try adding @available(SwiftStdlib 6.1, *) to _PointerParam, then I get an error saying error: '_PointerParam' is only available in macOS 9999 or newer when building the stdlib for the host OS. I thought custom built swiftc was supposed to build with availability for all releases?

SwiftStdlib 6.1 maps to OS version 9999 as a temporary placeholder on all platforms since Swift 6.1 has not yet been released with any Apple OS release. It will eventually be updated to map to a real version. Every context that refers to _PointerParam needs to be constrained to SwiftStdlib 6.1 too. It would be helpful to see the specific instances of error: '_PointerParam' is only available in macOS 9999 or newer you are seeing in order to decided what needs to be done about each.

[hnrklssn]

How does this work for the stdlib? If I simply try adding @available(SwiftStdlib 6.1, *) to _PointerParam, then I get an error saying error: '_PointerParam' is only available in macOS 9999 or newer when building the stdlib for the host OS. I thought custom built swiftc was supposed to build with availability for all releases?

SwiftStdlib 6.1 maps to OS version 9999 as a temporary placeholder on all platforms since Swift 6.1 has not yet been released with any Apple OS release. It will eventually be updated to map to a real version. Every context that refers to _PointerParam needs to be constrained to SwiftStdlib 6.1 too. It would be helpful to see the specific instances of error: '_PointerParam' is only available in macOS 9999 or newer you are seeing in order to decided what needs to be done about each.

Edit: d'oh, found it as soon as I posted my reply: I forgot to mark the macro definition with @available

[DougGregor]

Availability is needed on every declaration that might be linked by a separate executable (so that the compiler can generate correct linkage relative to the deployment target of the executable for the symbols). Even if the only separate executables that reference it are macro plugins, I think it may still be appropriate to have accurate availability.

These declarations are weird, because they are used in the arguments to the new macro but aren't part of the expansion and shouldn't ever be used outside of those macro arguments. We'd like them not to have availability at all, because the macros themselves should be usable on early deployment targets (some of the things they expand to might require newer deployment targets, but that's fine).

[tshortli]

Doesn't the macro plugin itself need to link the symbols associated with _PointerParam though?

[DougGregor]

Doesn't the macro plugin itself need to link the symbols associated with _PointerParam though?

The macro plugin is going to need to have its own version of any of these types, so that it itself is not deployment-target-gated.

[tshortli]

Ok, if _PointerParam is not expected to be linked dynamically by any back-deployable binaries then leaving availability off for convenience seems fine, but I do think the type deserves at least a comment explaining all of this in case anyone has to investigate a scenario where these fragile assumptions have been violated.

[hnrklssn]

some of the things they expand to might require newer deployment targets

This raises the question: do we want macro expansions with Span annotated with @available? My thinking is yes, so we can apply the macro in all contexts without causing compilation errors when Span isn't available.

[hnrklssn]

@swift-ci please smoke test

[hnrklssn]

@swift-ci please smoke test

[DougGregor]

some of the things they expand to might require newer deployment targets

This raises the question: do we want macro expansions with Span annotated with @available? My thinking is yes, so we can apply the macro in all contexts without causing compilation errors when Span isn't available.

Yes, the functions we generate that use Span will have to have appropriate availability. (That can, of course, but a follow-up)