...and collapse StaticVar/ClassVar and StaticLet/ClassLet into
StaticProperty/ClassProperty.
"var" and "let" aren't great nouns to use in diagnostics to begin with,
especially alongside semantic terms like "instance method". Focus on
the type vs. non-type aspect instead with "property", which better
matches how people talk about member vars (and lets) anyway.
Whenever we visit a declaration via the DeclChecker, add it to the
list of declarations to finalize. This makes sure that we can centralize
the notion of “finalize for SILGen” and that it will be called for
everything in the source file being processed.
- moving WARNING definition from DiagnosticsCommon.def to DiagnosticsSema.def
- improving WARNING message to better align with guidelines described in docs/Diagnostics.md as suggested by @xwu.
- adapting expected warning message in tests.
This gets adjustAccessLevelForProtocolExtension, a hack of sorts to
begin with, out of ValueDecl's general API, and down to a helper for
isAccessibleFrom and isSetterAccessibleFrom. (The only reason these
two don't go through access scopes is as an optimization.)
For now, the accessors have been underscored as `_read` and `_modify`.
I'll prepare an evolution proposal for this feature which should allow
us to remove the underscores or, y'know, rename them to `purple` and
`lettuce`.
`_read` accessors do not make any effort yet to avoid copying the
value being yielded. I'll work on it in follow-up patches.
Opaque accesses to properties and subscripts defined with `_modify`
accessors will use an inefficient `materializeForSet` pattern that
materializes the value to a temporary instead of accessing it in-place.
That will be fixed by migrating to `modify` over `materializeForSet`,
which is next up after the `read` optimizations.
SIL ownership verification doesn't pass yet for the test cases here
because of a general fault in SILGen where borrows can outlive their
borrowed value due to being cleaned up on the general cleanup stack
when the borrowed value is cleaned up on the formal-access stack.
Michael, Andy, and I discussed various ways to fix this, but it seems
clear to me that it's not in any way specific to coroutine accesses.
rdar://35399664
When a `fileprivate` method is declared in a `private`
extension, a warning is raised since access level
`fileprivate` is literally higher than `private`.
This is not appropriate because extensions are top level
declarations, for which `private` and `fileprivate` are
equivalent. This patch stops such warnings.
Resolves: SR-8306.
A bunch of tests that technically require Objective-C interop were
not labeled as such, and worked in the absence of Objective-C interop
due to bugs in the type checker.
The code for performing the third pass using the GenericToArchetypeResolver
is still there, but it only runs for non-generic declarations.
The next step is to consolidate this path with the generic path.
We still had unavailable versions of these for floating-point types
only. We shouldn't need to keep these around, and can instead just
emit a helpful diagnostic for anyone that attempts to use them.
Unfortunately I don't see any way for the diagnostic to produce an
actual fix-it, so it just suggests '+= 1' or '-= 1' without actually
producing a fix.
When diagnosing ApplyExpr, the existing implementation
tries to resolve the function subexpression independently
in the first place, without considering the argument
information. As a result, such resolved function type
may not produce the best diagnostic message.
This patch adds condideration of the number of arguments
to decide the better function subexpression for diagnostic
purpose.
Resolves: SR-7918, SR-7786, SR-7440, SR-7295, SR-5154.
When there are multiple possible overloads for a call, the partially-
type-checked argument expression might end up with a LoadExpr outside
of the call ParenExpr instead of inside it. Account for this in a one-
off way for the 'rawValue' / 'init(rawValue:)' fix-its.
Yet more https://bugs.swift.org/browse/SR-8150
Pass through the location of the equal '=' token for pattern binding decl entries, and use this location for the immediate deallocation diagnostic. Previously, we were just diagnosing on the start of the initialiser expression.
Additionally, this commit moves the call to `diagnoseUnownedImmediateDeallocation` from `typeCheckBinding` to `typeCheckPatternBinding`. This not only gives us easier access to the PBD entry, but also avoids calling the diagnostic logic for statement conditions such as `if let x = <expr>`. We currently never diagnose on these anyway, as the 'weak' and 'unowned' keywords cannot be applied to such bindings.
Resolves [SR-7340](https://bugs.swift.org/browse/SR-7340).
If a conformance to a protocol is implied by several other
conformances (i.e. protocol P: Equatable {} and protocol Q: Equatable {} and a
type declares conformance to both P and Q), we should choose a source that's in
the same file as the type, if we can, because automatic synthesis of
conformances (for Equatable, Hashable, etc.) only works in that case.
Fixes rdar://problem/41852654.
That is, if a type has a raw value of Int, and the function being
called has overloads for both Int and UInt, we always want to offer a
fix-it that leads to the 'Int' overload, not insert a conversion to
UInt that might be incorrect.
More https://bugs.swift.org/browse/SR-8150.
They were being put outside the call parentheses instead of inside.
We even had tests for this; I just got them wrong.
https://bugs.swift.org/browse/SR-8150
Without this, the compiler ended up complaining about missing cases
that can't actually occur, like `Optional<Never>.some(_)`. This was a
regression from Swift 4.1.
https://bugs.swift.org/browse/SR-8125
The storage kind has been replaced with three separate "impl kinds",
one for each of the basic access kinds (read, write, and read/write).
This makes it far easier to mix-and-match implementations of different
accessors, as well as subtleties like implementing both a setter
and an independent read/write operation.
AccessStrategy has become a bit more explicit about how exactly the
access should be implemented. For example, the accessor-based kinds
now carry the exact accessor intended to be used. Also, I've shifted
responsibilities slightly between AccessStrategy and AccessSemantics
so that AccessSemantics::Ordinary can be used except in the sorts of
semantic-bypasses that accessor synthesis wants. This requires
knowing the correct DC of the access when computing the access strategy;
the upshot is that SILGenFunction now needs a DC.
Accessor synthesis has been reworked so that only the declarations are
built immediately; body synthesis can be safely delayed out of the main
decl-checking path. This caused a large number of ramifications,
especially for lazy properties, and greatly inflated the size of this
patch. That is... really regrettable. The impetus for changing this
was necessity: I needed to rework accessor synthesis to end its reliance
on distinctions like Stored vs. StoredWithTrivialAccessors, and those
fixes were exposing serious re-entrancy problems, and fixing that... well.
Breaking the fixes apart at this point would be a serious endeavor.
Allow witnesses to protocols in a copyable context to elide explicit
ownership conventions. This allows clients like the standard library to
standardize on one ownership convention without an ABI or API breaking
change in 3rd party code.
In the future, moveonly contexts must disallow this default behavior
else the witness thunks could silently transfer ownership.
rdar://40774922
protocol P {
__consuming func implicit(x: __shared String)
__consuming func explicit(x: __owned String)
__consuming func mismatch(x: __shared String)
}
class C : P {
// C.implicit(x:) takes self and x '@guaranteed' thru the witness thunk
func implicit(x: String) {}
// C.explicit(x:) takes self and x @owned with no convention changes
__consuming func explicit(x: __owned String) {}
// Would inherit __consuming, but x has been spelled __owned so the requirement match fails.
func mismatch(x: __owned String) {}
}
We weren't checking this before, which would let you define a
public protocol that no public type could conform to.
This is a source-breaking change, so stage it in with a warning.
It becomes an error in -swift-version 5 mode.
The various 'isExplicit' checks were wrong -- they should apply
to protocol requirements only, not protocol extension members.
Also, we weren't performing this check for type aliases in
protocols, so you would get a misleading diagnostic telling you
the type alias must be declared private/internal, when in fact
type aliases in protocols cannot have their own access control.
Finally, the "should be declared <X>" diagnostics (the
!isExplicit case) need to state the most visible access level
that will work, and in a few cases we would say private instead
of fileprivate here.
