This change separates emission of the diagnostics like:
```
unnecessary check for 'Platform'; enclosing scope ensures guard will always be true
```
from the deployment target of the current compilation. Instead, these diagnostics will only be emitted if the enclosing scope guard is explicitly specified by the user with an `#availability` attribute.
This fixes cases like the following:
```
@available(macOS 11.0, *)
class Foo {
func foo() {
if #available(macOS 11.1, *) {}
}
}
```
Compiling this with `-target x86_64-apple-macos11.2` results in:
```
warning: unnecessary check for 'macOS'; enclosing scope ensures guard will always be true
if #available(macOS 11.1, *) {}
.../test.swift:2:7: note: enclosing scope here
class Foo {
```
Even though in source-code the enclosing scope (`Foo`) of this guard does not ensure it will always be true.
This happens because availability range is propagated by intersecting ranges top-down from the root `TypeRefinementContext`, which is defined by the deployment target, causing the availability range on class `Foo` to become `11.2`.
Users may be sharing the same piece of source-code across different projects with their own respective deployment targets which makes such target-dependent warnings confusing at some times, and not-useful at others.
We should rather have the warning simply reflect what is in the source.
Resolves rdar://77607488
Asking for Sendable conformances on this path is going to lead to
a traversal of the stored properties of the type. If there is an
interface type computation ongoing, as is very likely the case, this
traversal can wind up causing a cycle when it forces the interface type
of a member once again.
Request only the non-structural conformances to break the cycle.
rdar://77189542
Let's make use of a newly added "disable for performance" flag to
allow solver to consider overload choices where the only issue is
missing one or more labels - this makes it for a much better
diagnostic experience without any performance impact for valid code.
mismatch.
If there's an error in property wrapper application, the backing property
wrapper type request will return a null type, which would cause the compiler
to crash because most error recovery code expects ErrorType. If the wrapper
application has an error, use the interface type of the parameter instead.
When referencing a function that is on a global actor, e.g.,
@MainActor func doSomething() -> Int
the result of that reference is a global-actor-qualified function type, e.g.,
@MainActor () -> Int
Part of rdar://76030136.
This change includes a fix to allow the diagnostics
for constantness in function arguments to work properly
for constructors. This change also includes some minor
code cleanup in the constantness diagnostic pass.
Intro the concept of library access or distribution level to identify
layers of libraries and report public imports of private libraries from
public ones.
rdar://62934005
Currently the function parameter constantness check for functions
annotated with @_semantics("oslog.requires_constant_argument") does
not support ranges (e.g. 0...5, 0..<5). Ranges like this are
considered binary expressions by the compiler. This change adds
support for accepting binary expressions as constant arguments
as long as both arguments to the expression are constant.
rdar://71822563
Type inside of an editor placeholder is more of a hint than anything else,
so if it's incorrect let's diagnose that and use type variable instead to
allow solver to make forward progress.
Resolves: SR-14213
Resolves: rdar://74356736
If a tuple is passed as the only argument to a function that takes two unnamed arguments, we try to diagnose the missing argument label. However, in the old diagnose code we didn’t distinguish between non-existing arguments and arguments without labels; both behaved the same.
Thus, the missing second argument in the function call would line up with the empty second argument label, not producing a diagnostic, but hitting an assertion later on.
Distinguish between the two to fix the issue.
Fixes rdar://64319340
This cannot be supported for the same reasons struct and class stored
properties with potential unavailability cannot be supported.
It is possible that some users relied on this, because it worked in
some cases where the type metadata for the potentially unavailable
type was not actually needed for anything (eg, if the type was @frozen
and trivial, or a simple class reference). If this becomes an issue
we can downgrade this to a warning.
Note that just like the previous fix for stored properties, we do
still allow writing an '@available' attribute on the enum element if
the OS version is not any newer than the deployment target. This allows
annotating APIs with the OS version where they were introduced.
We were checking that the witness is at least as available as
the intersection of the protocol and the conforming type.
In the case where the conformance is defined in an extension,
this should actually be the intersection of the protocol and
the _availability of the extension_.
Fixes <rdar://problem/74114880>.
To help support incremental adoption of the concurrency model, a number
of concurrency-related diagnostics are enabled only in "new" code that
takes advantage of concurrency features---async, @concurrent functions,
actors, etc. This warning flag opts into additional warnings that better
approximate the eventual concurrency model, and which will become
errors a future Swift version, allowing one to both experiment with
the full concurrency model and also properly prepare for it.
