Enable the feature by default, and add an experimental feature
`DeprecateCompatMemberwiseInit` to control the deprecation behavior
which was deferred from the proposal.
Lifetime indices are never necessary in Swift, they unnecessarily expose
implementation details, and they make lifetime annotations more error-prone,
since they may need to be updated if a function's parameter list changes.
The Swift Syntax parser also cannot handle lifetime annotations where the target
is an index. The main reason the C++ parser supports them is because it is also
used for SIL.
Note that new code path doesn't actually seem to be taken, due to
NameImporter logic that renames non-member operators differently.
Adds some test case to at least document current behavior.
Extend support for proper errors on broken modularization to type
members, previously only top-level declarations were reported as error.
This change raises errors with relevant context if a type member is
referenced from a swiftmodule file but at reading the member is not
found or changed shape.
It doesn't report moves between modules like we do for top-level
declarations. This is less likely to happen at the member level as the
check is already applied at the top-level for the same reference. We may
still see such issues when using `SWIFT_NAME` to assign a top-level
declaration to a type from a different module.
We fall back to indices when labels are not available, but labels are
preferable, because they readable, stable, and preferred by the lifetime
dependencies proposal.
To a function type's lifetimes, a base version of the type is first created with
no lifetime dependence info. This is then passed to the dependence checker, and
the resulting dependencies are added to it.
It would be possible to do this analysis by passing just the parameter list and
result type (which are available before the type is created), but this approach
lets us avoid dealing with a header inclusion cycle between Types.h, ExtInfo.h,
and LifetimeDependence.h, since it does not require AnyFunctionType::Param to be
defined in LifetimeDependence.h.
The isFromAnnotation flag is set if and only if the lifetime originates from a
@lifetime or @_lifetime annotation in the source program.
isFromAnnotation==false means that the lifetime dependence checker would infer
the same lifetime if the Swift type or decl was printed without an annotation
for that dependency. More specifically, it means that the depenence was inferred
by the lifetime dependence checker.
Some dependencies on imported C/C++ decls are "inferred", but they either
correspond to explicit lifetime information in the source (smart pointers,
lifetimebound attribute) or are likely to differ from what the dependence
checker would infer. As such, we set the flag to true for all of them.
When generating a reverse interop header for a Swift module that declares `func ===` for a Swift type, we were printing `operator===`, which isn't valid in C++.
This teaches reverse interop to only print operators that are valid in C++.
rdar://169474185
This addresses feedback from #86560:
- Remove redundant collectParameterInfo call
- Consistent naming of ParamInfo variables
- Explicit type name instead of decltype
Also add nullptr checks on afd, as appropriate.
c2952b7 mistakenly treated the binary C++ operator*() ("multiply") as
the unary operator*() ("dereference"), preventing ClangImporter from
synthesizing the Swift func *(_:_) operator. This patch fixes the issue
and adds some tests to exercise the scenario.
rdar://169448888
