Saying "implicitly non-escaping because it was declared @autoclosure"
does not make sense. Since Swift 3, parameters of function type are
non-escaping by default, whether or not they are @autoclosure.
We would also inhibit the fixit for inserting @escaping if the
@autoclosure attribute was present. Again, a holdover from the
Swift 2 days, when @autoclosure implied @noescape and the special
@autoclosure(escaping) attribute was used to define an escaping
autoclosure.
- SILSerializeAll flag is now stored in the SILOptions and passed around as part of it
- Explicit SILSerializeAll/wholeModuleSerialized/makeModuleFragile API parameters are removed in many places
When we infer a requirement from the result type of a function, don't
warn if that requirement was also stated explicitly. This has been a
point of confusion since we introduced the redundancy warnings,
because users don't consider to result type to be an "input" to the
function in the way the compiler does. So, while technically it is
"correct" to warn, it's unintuitive---so stop.
Fixes SR-5072 / rdar://problem/31357967.
Swift 3 had a type soundness hole in protocol conformance checking
where the requirement contained an "== Self" constraint and the
witness was a member of a non-final class. We previously closed the
type soundness hole in PR #9830, but left it as a warning in Swift 3
compatibility mode.
Escalate that warning to an error. The optimizers break due to this
type soundness hole, and of course it can lead to other runtime
breakage because it violates the type system.
Fixes rdar://problem/28601761.
This was done back in Swift 3.0.1 or 3.0.2. Let's finally make them
errors in Swift 4!
I also fixed up a number of '%error' entries in diagnostics that can
actually happen in invalid code. These are the ones that were already
present in the warnings.
Push the getName method from ValueDecl down to only those types that are
guaranteed to have a name that is backed by an identifier and that will
not be special.
Between syntactic restrictions and later checks for spurious '&'
expressions, we don't need to check for '&' expressions when coercing
to an rvalue. Plus, 'inout' doesn't imply 'not lvalue', so we'd never
get here.
In anticipation of removing this bit, move it from the
recursive type property into TupleType - its only real
user. This necessitates uglifying a bit of logic in the
short term that used to speak broadly of materializability
to instead speak about LValues and Tuples of InOut values
independently.
Remove the descriptive decl kind (since with subpaths it is not correct and
cannot represent a tuple element) and change "simultaneous" to "overlapping"
in order to lower the register slightly and avoid connoting threading.
For example, for the following:
takesTwoInouts(&x.f, &x.f)
the diagnostic will change from
"simultaneous accesses to var 'x.f', but modification requires exclusive access;
consider copying to a local variable"
to
"overlapping accesses to 'x.f', but modification requires exclusive access;
consider copying to a local variable"
Relax the static enforcement of exclusive access so that we no longer diagnose
on accesses to separate stored structs of the same property:
takesInout(&s.f1, &s.f2) // no-warning
And perform the analogous relaxation for tuple elements.
To do this, track for each begin_access the projection path from that
access and record the read and write-like modifications on a per-subpath
basis.
We still warn if the there are conflicting accesses on subpaths where one is
the prefix of another.
This commit leaves the diagnostic text in a not-so-good shape since we refer
to the DescriptiveDeclKind of the access even describing a subpath.
I'll fix that up in a later commit that changes only diagnostic text.
https://bugs.swift.org/browse/SR-5119
rdar://problem/31909639
Generates a warning for any expression that takes longer than <limit>
milliseconds to type check. This compliments the existing
-warn-long-function-body=<limit> option.
substitutions for calling a specialized declaration.
For full generality, this really ought to be a Witness, but the current
use cases where we're constructing calls to specialized witnesses never
need to call a generic requirement, and I'm not sure how to apply
substitutions to a Witness with a synthetic environment.
The -enable-testing flag makes ValueDecl::getEffectiveAccess()
say that internal declarations are public.
This would lead us to emit spurious diagnostics if a default
argument of an internal function referenced a private symbol,
for example, which is something we actually want to allow.
This is a second revision of the patch -- instead of changing
getEffectiveAccess() to take an extra parameter, this changes
getFormalAccessScope() instead.
Fixes <rdar://problem/32592973>.
The -enable-testing flag makes ValueDecl::getEffectiveAccess()
say that internal declarations are public.
This would lead us to emit spurious diagnostics if a default
argument of an internal function referenced a private symbol,
for example, which is something we actually want to allow.
Hack around this by adding a new 'forLinkage' parameter to
getEffectiveAccess(). When this is false, we ignore the
-enable-testing flag, and only look for the @_versioned
attribute.
I'm not very happy with the fix, because it only compliates
the subtle behaviors of getFormalAccess(), getEffectiveAccess()
and getFormalAccessScope() further. But refactoring this is
a bigger change than I'm willing to put into swift-4.0-branch.
Fixes <rdar://problem/32592973>.
This time, the warnings only fire when the class in question directly
conforms to NSCoding. This avoids warning on cases where the user has
subclassed something like, oh, UIViewController, and has no intention
of writing it to a persistent file.
This also removes the warning for generic classes that conform to
NSCoding, for simplicity's sake. That means
'@NSKeyedArchiverEncodeNonGenericSubclassesOnly' is also being
removed.
Actually archiving a class with an unstable mangled name is still
considered problematic, but the compiler shouldn't emit diagnostics
unless it can be sure they are relevant.
rdar://problem/32314195
This is accomplished by recognizing this specific situation and
replacing the 'objc' attribute with a hidden '_objcRuntimeName'
attribute. This /only/ applies to classes that are themselves
non-generic (including any enclosing generic context) but that have
generic ancestry, and thus cannot be exposed directly to Objective-C.
This commit also eliminates '@NSKeyedArchiverClassName'. It was
decided that the distinction between '@NSKeyedArchiverClassName' and
'@objc' was too subtle to be worth explaining to developers, and that
any case where you'd use '@NSKeyedArchiverClassName' was already a
place where the ObjC name wasn't visible at compile time.
This commit does not update diagnostics to reflect this change; we're
going to change them anyway.
rdar://problem/32414557
We silently miscompiled previously the following code:
protocol Gesture {}
struct Foo {}
struct Bar {}
enum FooOrBar {
case foo(Foo)
case bar(Bar)
}
func main(_ f : FooOrBar) {
switch f {
case .foo(let data as Gesture),
.bar(let data as Gesture):
...
}
...
}
This was because the multiple pattern per case code never implemented support
for address only types.
Now instead of miscompiling such programs, we do the following:
1. We emit an error.
2. When we construct the arguments for the named bindings, we just skip the
address only types. Everything else is normal.
3. In the case block, we use a SILUndef for the address only value.
This ensures that we preserve as many other diagnostics as possible.
rdar://32525952
P.S. As an additional benefit, this eliminates a source of address phi nodes
from SILGen.
