Availability checking for types was only suppressed when the immediate context
for the use of the type was explicitly marked unavailable. Availability is
lexical so the checking should be suppressed in the entire scope instead.
A recent PR (#77204) started to import C++ source locations into Swift.
This PR flips a switch so these locations are actually used more widely.
Now some of the diagnostic locations are changed, but they generally
improved the quality of the diagnostics, pointing out conformances
imported from Obj-C code right when they are declared.
https://github.com/swiftlang/swift/pull/76621 caused a regression by skipping
the AST nodes nested under `defer` blocks. The node associated with a `defer`
block is implicit because it is a kind of closure context synthesized by the
compiler. However, the nodes it contains are not implicit and so they must be
visited by the `TypeRefinementContextBuilder`.
Resolves rdar://139012152
Delaying such bindings is too restrictive and leads to subpar selections.
For `$T1` to be array or C-style pointer it would have to be
connected either to a type variable that could be bound to
array/pointer or directly to array/pointer type which would
result in the solver either selecting the other type variable
first (because it appears in adjacent variables of `$T1`) or
provide an additional binding(s) for `$T1` (including literals).
Consider the following constraint system:
```
$T2 arg conv $T1
$T2 conforms ExpressibleByIntegerLiteral
inout $T1 arg conv UnsafeMutablePointer<UInt8>?
```
If `$T1` and `$T2` are the only viable type variables delaying
`$T1` would mean that `$T2` is picked to attempt its default
type `Int` which is incorrect (it doesn't get `UInt8` because
there is no transitive inference through conversions).
Today ParenType is used:
1. As the type of ParenExpr
2. As the payload type of an unlabeled single
associated value enum case (and the type of
ParenPattern).
3. As the type for an `(X)` TypeRepr
For 1, this leads to some odd behavior, e.g the
type of `(5.0 * 5).squareRoot()` is `(Double)`. For
2, we should be checking the arity of the enum case
constructor parameters and the presence of
ParenPattern respectively. Eventually we ought to
consider replacing Paren/TuplePattern with a
PatternList node, similar to ArgumentList.
3 is one case where it could be argued that there's
some utility in preserving the sugar of the type
that the user wrote. However it's really not clear
to me that this is particularly desirable since a
bunch of diagnostic logic is already stripping
ParenTypes. In cases where we care about how the
type was written in source, we really ought to be
consulting the TypeRepr.
Occasionally, when the Swift compiler emits a diagnostic for a construct
that was imported from C++ we get a diagnostic with unknown location.
This is a bad user experience. It is particularly bad with the
borrow-checker related diagnostics. This patch extends the source
location importing to declarations in ClangImporter. There are some
invariants enforced by the Swift compile, e.g., a source range is
comprised of two valid source locations or two invalid ones. As a
result, this patch adds approximate source locations to some separators
like braces or parens that are not maintained by Clang. Having slightly
incorrect ranges in this case is better than emitting unknown source
locations.
If the feature is enabled, base the requirement for the underscored
accessors on the availability of the non-underscored accessors. If the
(non-underscored) accessor's was available earlier than the feature,
interpret that to mean that the underscored version was available in
that earlier version, and require the underscored version. The goal is
to ensure that the ABI is preserved, so long as the simplest migration
is done (namely, deleting the underscores from the old accessors).
For modify2, cache the required-ness in the same way that it is cached
for modify.
Ensure the implicit `do` statement has a source
range that covers the `for` loop by changing the
source location for the initial binding. This ensures
we correctly detect the code completion child and
avoid skipping it.
In #58965, lookup for custom derivatives in non-primary source files was
introduced. It required triggering delayed members parsing of nominal types in
a file if the file was compiled with differential programming enabled.
This patch introduces `CustomDerivativesRequest` to address the issue.
We only parse delayed members if tokens `@` and `derivative` appear
together inside skipped nominal type body (similar to how member operators
are handled).
Resolves#60102
Consider:
1. File struct.swift defining `struct Struct` with `static func max` member
2. File derivatives.swift defining `extension Struct` with custom derivative of the `max` function
3. File error.swift defining a differentiable function which uses `Struct.max`.
Previously, when passing error.swift as primary file and derivatives.swift as a secondary file to swift-frontend (and forgetting to pass struct.swift as a secondary file as well), an assertion failure was triggered.
This patch fixes the issue by adding a check against `ErrorType` in `findAutoDiffOriginalFunctionDecl` before calling `lookupMember`.
Co-authored-by: Anton Korobeynikov <anton@korobeynikov.info>
https://github.com/swiftlang/swift/pull/77236 caused a source compatibility
regression because `extractEnumElement()` does not suppress its diagnostics in
the context of pattern matching. Potentially unavailable enum elements should
not be diagnosed when pattern matching since the generated code will not
retrieve the potentially unavailable element value on versions where it is
unavailable.
Fixes rdar://138771328.
Add the necessary compiler-side logic to allow
the regex parsing library to hand back a set of
features for a regex literal, which can then be
diagnosed by ExprAvailabilityWalker if the
availability context isn't sufficient. No tests
as this only adds the necessary infrastructure,
we don't yet hand back the features from the regex
parsing library.
Based on feedback in PR https://github.com/swiftlang/swift/pull/69460, enabling indexing for synthesized decls because they are usable by users and make sense to appear in the indexstore.
Sets `synthesized` on some additional decls:
- derived `hashInto(...)`
- Objc properties and methods derived from Objc protocols
https://github.com/apple/swift/issues/67446
Currently, we do not support exporting zero-sized value types from Swift
to C++. It needs some work on our end as these types are not part of the
lowered signature. In the meantime, this PR makes sure that common (but
not all) zero sized types are properly marked as unavailable. This is
important as the proper diagnostic will give users a hint how to work
around this problem. Moreover, it is really easy to hit this when
someone is experimenting with interop, so it is important to not have a
cryptic failure mode.
rdar://138122545
It is invalid to reference an internal setter from a fragile function
regardless of whether the storage is unavailable. The swiftinterface generated
for this code would not typecheck since the setter is not known to exist
outside the module.
Avoid relying on the modeling of single unlabeled
associated values as ParenType, instead check the
case constructor parameters. Also refactor to
early return in more cases.
