* Update usage checking to account for __shared parameters as immutable
* Allow pattern type checking to resolve Shared parameters to the appropriate parameter specifiers
* Add the __shared protocol requirement restriction
just for pointer identity.
The current technique for deciding whether that's the case is *extremely*
hacky and need to be replaced with an attribute, but I'm reluctant to
take that on so late in the schedule. The hack is terrible but not too
hard to back out in the future. Anyone who names a method like this just
to get the magic behavior knows well that they are not on the side of
righteousness.
rdar://33265254
Also, begin to pass around base types instead of raw InOutType types. Ideally, only Sema needs to deal with them, but this means that a bunch of callers need to unwrap any inouts that might still be lying around before forming these types.
Multiple parts of the compiler were slicing, dicing, or just dropping these flags. Because I intend to use them for the new function type representation, I need them to be preserved all across the compiler. As a first pass, this stubs in what will eventually be structural rules as asserts and tracks down all callers of consequence to conform to the new invariants.
This is temporary.
When inside a declaration or extension of TypeName, humans usually don't write
the full typename like #selector(TypeName.foo), but instead prefer the neater
form #selector(self.foo). The compiler has enough information to do this too.
Fixes rdar://problem/25284692 .
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.
Previously we would erroneously flag a `var` as not being mutated if the only mutations were through WritableKeyPaths. Fixes SR-5214 | rdar://problem/32599483.
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.
Instead of doing that, suggest removing 'var' altogether because
'let' cannot be used directly in an implicitly immutable context.
Resolves: rdar://problem/32390726
Situations where there is a contextual RawRepresentable type is
used incorrectly would produce `<Type>(rawValue: )` fix-it only
in cases where neither or both sides of the expression are optional.
Let's fix that by adding a fix-it for optional to contextual raw
value type conversion.
Resolves: rdar://problem/32431736
Adjust the definition of some diagnostics that are already called with
DeclBaseNames so that the implicit conversion from DeclBaseName to
Identifier is no longer needed.
Adjust the call side of diagnostics which don't have to deal with
special names to pass an Identifier to the diagnostic.
With the introduction of special decl names, `Identifier getName()` on
`ValueDecl` will be removed and pushed down to nominal declarations
whose name is guaranteed not to be special. Prepare for this by calling
to `DeclBaseName getBaseName()` instead where appropriate.
This changes `getBaseName()` on `DeclName` to return a `DeclBaseName`
instead of an `Identifier`. All places that will continue to be
expecting an `Identifier` are changed to call `getBaseIdentifier` which
will later assert that the `DeclName` is actually backed by an
identifier and not a special name.
For transitional purposes, a conversion operator from `DeclBaseName` to
`Identifier` has been added that will be removed again once migration
to DeclBaseName has been completed in other parts of the compiler.
Unify approach to printing declaration names
Printing a declaration's name using `<<` and `getBaseName()` is be
independent of the return type of `getBaseName()` which will change in
the future from `Identifier` to `DeclBaseName`
Printing a declaration's name using `<<` and `getBaseName()` is be
independent of the return type of `getBaseName()` which will change in
the future from `Identifier` to `DeclBaseName`
In Swift 3, we required that '.self' be specified on TypeExprs
and DeclRefExprs that reference types.
However, types referenced as member lookups, such as 'Foo.Bar',
did not get this treatment, and '.self' was not required.
Fix this by emitting warnings in the cases that Swift 3 did not
diagnose, and producing errors in Swift 4 mode where we want
strict enforcement.
Resolves: https://bugs.swift.org/browse/SR-4426
* Make IfConfigDecl be able to hold ASTNodes
* Parse #if as IfConfigDecl
* Stop enclosing toplevel #if into TopLevelCodeDecl.
* Eliminate IfConfigStmt
Replace `NameOfType foo = dyn_cast<NameOfType>(bar)` with DRY version `auto foo = dyn_cast<NameOfType>(bar)`.
The DRY auto version is by far the dominant form already used in the repo, so this PR merely brings the exceptional cases (redundant repetition form) in line with the dominant form (auto form).
See the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es11-use-auto-to-avoid-redundant-repetition-of-type-names) for a general discussion on why to use `auto` to avoid redundant repetition of type names.
The variable_never_used fixit transforms into invalid code in the case of two-stage let initialization. I introduced a new diagnostic that does not fixit and suggests removing the value.
...avoiding a crash when trying to detect near misses of protocol
requirements. Unfortunately I can't come up with a test case for the
VarDecl changes; everything I try seems to already work. But using
interface types is more correct anyway.
https://bugs.swift.org/browse/SR-3812
- Most immediately, we now have `withoutActuallyEscaping` as a supported way to temporarily reference a nonescaping closure as if it were escapable, and we plan to break the ABI for escaping and nonescaping closures so that the old `unsafeBitCast` workaround no longer works.
- `unsafeBitCast` is also commonly used to kludge pointers into different types, but we have more semantically meaningful APIs for type punning now. Guide users towards those APIs.
- Suggest more specific and type-safe operations, like `bitPattern:` initializers or `unsafeDowncast`, for the situations where `unsafeBitCast` is being used to avoid dynamic type checks or reinterpret numerical bits.
Previously all of the following would strip off varying amounts of
MetatypeType, LValueType, InOutType, DynamicSelfType, etc:
- ConstraintSystem::performMemberLookup()
- ConstraintSystem::lookupMember()
- TypeChecker::lookupMember()
- DeclContext::lookupQualified()
- Type::getContextSubstitutions()
The problem is that the higher level methods that took a lookup type
would call the lower level methods, and post-process the result using
the given lookup type. Since different levels of sugar were stripped,
it made the code hard to reason about and opened up edge cases, eg
if a DynamicSelfType or InOutType appears where we didn't expect it.
Since filtering out static/instance and mutating/nonmutating members
is done at higher levels, there's no reason for these name lookup
operations to accept anything other than nominal types, existentials
and archetypes.
Make this so with assertions, and deal with the fallout.
