Removes the underscored prefixes from the @_section and @_used attributes, making them public as @section and @used respectively. The SymbolLinkageMarkers experimental feature has been removed as these attributes are now part of the standard language. Implemented expression syntactic checking rules per SE-0492.
Major parts:
- Renamed @_section to @section and @_used to @used
- Removed the SymbolLinkageMarkers experimental feature
- Added parsing support for the old underscored names with deprecation warnings
- Updated all tests and examples to use the new attribute names
- Added syntactic validation for @section to align with SE-0492 (reusing the legality checker by @artemcm)
- Changed @DebugDescription macro to explicitly use a tuple type instead of type inferring it, to comply with the expression syntax rules
- Added a testcase for the various allowed and disallowed syntactic forms, `test/ConstValues/SectionSyntactic.swift`.
Several changes:
- shorten the warning at the call-site of unannotated functions that
return FRTS
- place the call to action ("annotate 'X' with 'Y'") at the diagnostic
note attached to the unannotated callee, where the annotation should
be made
- re-word the foreign-reference-type.md documentation to (1) reflect the
diagnostic wording change, (2) give a little bit more background about
why the annotations are needed, and (3) not be specific to C++ (since
we can import FRTs from C as well)
Replace the `here` part of the generic exportability diagnostic for
variables with: `in a property declaration marked public or in a
'@frozen' or '@usableFromInline' context`.
The full diagnostic now looks like:
```
error: cannot use struct 'ImportedType' in a property declaration marked
public or in a '@frozen' or '@usableFromInline' context;
'HiddenDependency' has been imported as implementation-only
```
This should be improved further to support implicitly exported memory
layouts in non-library-evolution and embedded.
- Delete baseline language feature WarnUnannotatedReturnOfCxxFrt,
which won't really be useful to users
- Remove some references to "cxx", since FRTs are not exclusively
imported from C++
- Clean up lit test RUN lines to use %{fs-sep}
This change makes the warning for unannotated C++ functions returning foreign
reference types (FRT) enabled by default, improving memory safety for Swift/C++
interop users. Also added CxxForeignReferenceType diagnostic group for better control
`discard self` requires knowledge of the internal layout of the type in order to clean
up its fields while bypassing its public `deinit`. Inlinable code can get copied into
and run from outside of the defining module, so this is impossible to implement.
Fixes rdar://160815058.
Consider functions in embedded mode to be fragile unless marked with
`@_neverEmitIntoClient`. Basically treating them as if they were
`@_alwaysEmitIntoClient` by default. A fragile function cannot reference
restricted imports such as `@_implementationOnly`, `internal import`,
etc.
We consider them as fragile only for type-checking, at the SIL level
they remain treated as normal functions like before. This allows the
later optimization to work as expected. We may want to likely align both
ends of the compiler once this is properly supported in sema.
This is enabled only in embedded. Fragile functions in library-evolution
are marked with attributes and are already checked. We do not need this
is non-embedded non-library-evolution as CMO handles inlining and
already takes into consideration `@_implementationOnly` imports.
Note: We'll need a similar check for memory layouts exposed to clients.
We can still see compiler crashes and miscompiles in this scenario. This
will apply to both embedded and non-library-evolution modes. That will
likely need to extend the `@_neverEmitIntoClient` attribute and may
require a staged deployment.
rdar://161365361
When expanding a Swift macro in a clang module where the original clang
module imported a submodule in a C++ standard library module other than
`std`, e.g. a submodule to `std_core`, this would result in an error.
This is because `std_core.math.abs` would be imported as
`CxxStdlib.math.abs`, which would later be translated back as
`std.math.abs` which doesn’t exist.
This changes the mapping to only map `std` to `CxxStdlib`. To prevent
errors when importing modules starting with `std_`, this error is moved
from the late-stage module import to the earlier processing of
`ImportDecl`s. This results in these module names still being forbidden
in explicit imports (i.e. naming them in source code), while still being
allowed in implicit imports inherited from clang modules.
This also fixes a fix-it bug where only the first 3 characters would be
selected for replacing with `CxxStdlib` when importing `std_core`.
This also fixes a diagnostic bug where aliased modules would refer to
the module name in the source code rather than the real module name, and
adds a note clarifying the situation.
rdar://161795429
rdar://161795673
rdar://161795793
fix non-fatal import error
The flow was such that we recorded subtype constraints regardless of the
subject type's nature. Extract value generics handling out of the
devious `else if` chain, and never record any subtype constraints if the
subject type is a non-type parameter.
While we're here, generalize the diagnostic message for user-written
subtype constraints on value generic parameters and emit it
consistently, not just if the right-hand side contains a protocol type.
This commit introduces a performance hint check that warns on the use of
existential any in variable declarations, function and closure parameters and
returns, and typealiases.
@c @implementation relies on matching the original C declaration. The
lookup for the original C declaration was doing the wrong kind of
lookup, meaning that it could only find the C declaration if it came
through a bridging header, and not through a normal module import.
Using unqualified lookup here finds the name appropriately.
Clarify the diagnostics here as well to not talk about umbrella and
bridging headers.
Fixes rdar://161909754.
This check will run on each type-checked primary input of the current compilation and emit a warning diagnostic for all discovered occurences of this code pattern when the performance hint diagnostic is enabled
The intent for `@inline(always)` is to act as an optimization control.
The user can rely on inlining to happen or the compiler will emit an error
message.
Because function values can be dynamic (closures, protocol/class lookup)
this guarantee can only be upheld for direct function references.
In cases where the optimizer can resolve dynamic function values the
attribute shall be respected.
rdar://148608854
A "permanently enabled" availability domain is one that has been declared
always available and is also simultaneously has either an attribute that
makes it deprecated or universally unavailable.
Emit fix-its that remove (or update) `@available` attributes that restrict
availability in a permanently enabled domain. Also, emit warnings about
`if #available` queries that always return true because they check a
permanently enabled domain.
Resolves rdar://157601761.
When using an internal import for a bridging header, semantically treat
the contents of the bridging header, and anything that it imports, as
if they were imported internally. This is the actual semantic behavior
we wanted from internally-imported bridging headers.
This is the main semantic checking bit for rdar://74011750.
Not all clients can properly handle the presence of placeholders in
interface types and it doesn't seem worth the complexity for the
type replacement diagnostic.
Embedded Swift doesn't have protocol conformance metadata, so it cannot
handle dynamic casts to existentials (nor should it).
Another part of rdar://119383905.
The existing SIL-level diagnostic for this check only triggers when
the type is actually used, while the type-checker version is more
eager. Stage in the stricter check as a warning and we'll clamp down
on things later.
Generic methods declared in protocols (and extensions thereof) cannot
be used on existential values, because there is no way to specialize
them for all potential types. Diagnose such cases in Embedded Swift
mode and via `-Wwarning EmbeddedRestrictions`.
This adds a bunch more warnings to the standard library that we'll
need to clean up, probably by `#if`'ing more code out.
Part of rdar://119383905.
Move the diagnostic about non-final generic methods in classes up to
the type checker, so that it is available to `-Wwarning
EmbeddedRestrictions` and earlier in the pipeline. The SIL version of
this is still available as a backstop.
Yet another part of rdar://133874555.
This attribute forces programmers to acknowledge every
copy that is required to happen in the body of the
function. Only those copies that make sense according
to Swift's ownership rules should be "required".
The way this is implemented as of now is to flag each
non-explicit copy in a function, coming from SILGen, as
an error through PerformanceDiagnostics.
