[Sema] Implement @_nonEphemeral #27705
Conversation
|
@swift-ci please test |
|
Build failed |
|
@swift-ci please test Linux platform |
|
Build failed |
This non-user-facing attribute is used to denote pointer parameters which do not accept pointers produced from temporary pointer conversions such as array-to-pointer, string-to-pointer, and in some cases inout-to-pointer.
Diagnose ephemeral conversions that are passed to @_nonEphemeral parameters. Currently, this defaults to a warning with a frontend flag to upgrade to an error. Hopefully this will become an error by default in a future language version.
hamishknight
force-pushed
the
just-the-health
branch
from
6fe0857 to
1f78009
Compare
There was a problem hiding this comment.
From the type-checker/diagnostics perspective this looks good to me! I'm not really sure whether adding a new underscored attribute is the best way to go about it though.
It's already possible to determine that solver converts some type to a pointer implicitly and that it happened as part of the argument-to-parameter conversion. Maybe I just don't understand what is the intended use of this attribute...
|
@xedin Thanks for looking through this! The goal of the attribute is to allow us to selectively mark parameters which shouldn't accept temporary pointer arguments (you can take a look at the last two commits of #27695 to see which decls I'm planning on marking). We still want all other pointer parameters to continue accepting these temporary pointer conversions, as we don't know whether or not such conversions will be unsound (though the implementation of a SIL pass will help catch a bunch of cases there). |
|
Merged as a part of #27695. |
This PR contains a subset of the changes in #27695, specifically just the implementation for the
@_nonEphemeralattribute and the diagnosis of invalid temporary pointers conversions passed to it.This includes all array-to-pointer and string-to-pointer conversions, and most inout-to-pointer conversions with the exception of:
If landed, this will leave #27695 with just the changes required to start producing warnings in user code (by annotating the standard library + inferring the attribute in various places).