The computation that determined whether an access to a `let` instance
property within a constructor should be an initialization conflated the
cases of "we don't have a base expression" and "the base expression is
not something that could be `self`", and incorrectly identified rvalue
bases as being "initializable". Make the interface properly separate
out these cases, so we don't turn an lvalue into an rvalue access.
Fixes rdar://128661833.
Add a new mandatory BooleanLiteralFolding pass which constant folds conditional branches with boolean literals as operands.
```
%1 = integer_literal -1
%2 = apply %bool_init(%1) // Bool.init(_builtinBooleanLiteral:)
%3 = struct_extract %2, #Bool._value
cond_br %3, bb1, bb2
```
->
```
...
br bb1
```
This pass is intended to run before DefiniteInitialization, where mandatory inlining and constant folding didn't run, yet (which would perform this kind of optimization).
This optimization is required to let DefiniteInitialization handle boolean literals correctly.
For example in infinite loops:
```
init() {
while true { // DI need to know that there is no loop exit from this while-statement
if some_condition {
member_field = init_value
break
}
}
}
```
* Delegated-to `Optional` ctors were always handled as if they were failable, resulting in false-positive delegation errors.
* Delegations via `try?` were not diagnosed if the called ctor had IUO failability on top of being `throws`. SILGen would then handle the `try?` as if it was a `try!`.
* Delegations via `try?` were diagnosed with the wrong message if the `try?` was nested inside a `try!`, e.g. `try! try self.init(nonFailable:)`
* If there are issues with both `try?` and failability of the called initializer, diagnose both.
Provide more detailed diagnostic message when implicitly synthesized @objc initializer in subclass was overridden inside the subclass' extension
Resolves: rdar://problem/79179597
Before lookup was requestified, the entire lookup stack would
install semantic members. As this caused cycles in the lookup path, it
was refactored to instead only occur at the TypeChecker::lookup*
entrypoints. Unfortunately, these entrypoints were not kept in sync with
the stack building code in qualified lookup, so a case was missed:
class-bound archetypes. We need to synthesize semantic members for them
as well or we'll non-deterministically fail to find synthesizable
members in incremental mode.
rdar://74174749
Convenience inits are only allowed on classes and in extensions thereof. And in CFTypes we are not allowed to put convenince inits since swift does not support this feature yet.
This PR solve the bad fix suggestion when a user declare a init method in an extension of CF Type.
Another bug (similar to this one) that i found and became visible when i was doing the test cases for SR-116779 was the fact that if you declare a convenience init that delegates the init function in self, a fix suggestion will appear. The same suggestion that is causing troubles in SR-11679. The fix for this was removing the fix suggestion when the class kind type was CFType since if we leave it as is, it will be the same problem as SR-11679.
SR-11679: PR Feedback
Formatting the new code with clang-format and using `isa` and `cast` instead of `dyn_cast`
SR-11679: PR Feedback
Inlining `cast
SR-11679: PR Feedback
Remove semi-colon
SR-11679: PR Feedback
Remove empty line & add mark to avoid fixit.
SR-11679: PR Feedback
Remove empty line.
SR-11679: PR Feedback
Move Diagnostics Info & Remove empty lines
Use it to provide an idealized API for the VarDecl case in validateDecl.
In reality, a lot of work is needed to rationalize the dependency
structure of this request. To start, the callers of
typeCheckPatternBinding must be eliminated piecemeal. Once that is
done, the AST should introduce pattern binding decls along all the
places where getParentStmt() used to apply.
This is an amalgam of simplifications to the way VarDecls are checked
and assigned interface types.
First, remove TypeCheckPattern's ability to assign the interface and
contextual types for a given var decl. Instead, replace it with the
notion of a "naming pattern". This is the pattern that semantically
binds a given VarDecl into scope, and whose type will be used to compute
the interface type. Note that not all VarDecls have a naming pattern
because they may not be canonical.
Second, remove VarDecl's separate contextual type member, and force the
contextual type to be computed the way it always was: by mapping the
interface type into the parent decl context.
Third, introduce a catch-all diagnostic to properly handle the change in
the way that circularity checking occurs. This is also motivated by
TypeCheckPattern not being principled about which parts of the AST it
chooses to invalidate, especially the parent pattern and naming patterns
for a given VarDecl. Once VarDecls are invalidated along with their
parent patterns, a large amount of this diagnostic churn can disappear.
Unfortunately, if this isn't here, we will fail to catch a number of
obviously circular cases and fail to emit a diagnostic.
Since getStoredProperties() is a request that lowers lazy properties
and property wrappers to their underlying storage, and SIL can validate
stored property and enum element types, there's no longer any need for
Sema to explicitly finalize members of structs and enums. SILGen can
trigger any necessary type checkin work just by lowering a struct or
enum type.
Now the only remaining reason we need finalizeDecl() is adding implicit
methods to classes, and synthesizing accessors for storage in classes
and protocols.
Detect and fix situations when (force) unwrap is used on
a non-optional type, this helps to diagnose invalid unwraps
precisely and provide fix-its.
Resolves: [SR-8977](https://bugs.swift.org/browse/SR-8977)
Resolves: rdar://problem/45218255
When we determine that an optional value needs to be unwrapped to make
an expression type check, use notes to provide several different
Fix-It options (with descriptions) rather than always pushing users
toward '!'. Specifically, the errors + Fix-Its now looks like this:
error: value of optional type 'X?' must be unwrapped to a value of
type 'X'
f(x)
^
note: coalesce using '??' to provide a default when the optional
value contains 'nil'
f(x)
^
?? <#default value#>
note: force-unwrap using '!' to abort execution if the optional
value contains 'nil'
f(x)
^
!
Fixes rdar://problem/42081852.
That is, if there's a problem with a witness, and the witness comes
from a different extension from the conformance (or the original type,
when the conformance is on an extension), put the main diagnostic on
the conformance, with a note on the witness. This involves some
shuffling and rephrasing of existing diagnostics too.
There's a few reasons for this change:
- More context. It may not be obvious why a declaration in file
A.swift needs to be marked 'public' if you can't see the conformance
in B.swift.
- Better locations for imported declarations. If you're checking a
conformance in a source file but the witness came from an imported
module, it's better to put the diagnostic on the part you have
control over. (This is especially true in Xcode, which can't display
diagnostics on imported declarations in the source editor.)
- Plays better with batch mode. Without this change, you can have
diagnostics being reported in file A.swift that are tied to a
conformance declared in file B.swift. Of course the contents of
A.swift also affect the diagnostic, but compiling A.swift on its
own wouldn't produce the diagnostic, and so putting it there is
problematic.
The change does in some cases make for a worse user experience,
though; if you just want to apply the changes and move on, the main
diagnostic isn't in the "right place". It's the note that has the info
and possible fix-it. It's also a slightly more complicated
implementation.
And provide better semantic background by surrounding 'nil' in ticks when it is referred to as a value
Added missing tests for certain cases involving nil capitalization
Introduce a new Type node, BoundNameAliasType, which describes a
reference to a typealias that requires substitutions to produce the
underlying type. This new type node is used both for references to
generic typealiases and for references to (non-generic) typealiases
that occur within generic contexts, e.g., Array<Int>.Element.
At present, the new type node is mainly useful in preserving type
sugar for diagnostics purposes, as well as being reflected in other
tools (indexing, code completion, etc.). The intent is to completely
replace NameAliasType in the future.
This restriction came from wanting to make resilient and non-resilient
code follow the same rules whenever possible, but after thinking about
it a bit more we realized there was no reason why you /wouldn't/ just
mark your structs @_fixed_layout in non-resilient libraries anyway.
Since that (currently?) doesn't affect what you can do with the struct
across module boundaries, and since the layout of the struct is
available anyway in a non-resilient library, there's no real downside,
which means it's a meaningless restriction.
The same logic doesn't /quite/ apply to classes, since classes are
normally much more flexible than structs. (For example, you could add
a stored property to a class without recompiling clients, as long as
no initializers are inlined.) But it's close enough that we don't want
to put in the restriction at this time.
All of this is about attributes that haven't been finalized yet anyway
(hence the leading underscore), but it's still useful information.
rdar://problem/37408668
This is technically a source break, but the @_fixed_layout attribute
is not official yet. If anyone really cares, we can make this
conditional on -swift-version 5 later, but I'd rather not.
This change is necessary so that we can give property initializers
non-public linkage. Currently they are public, because they can be
referenced from inlinable initializers.
Now that property initializers inside a @_fixed_layout type can
only reference public symbols, they no longer have to be public,
but making that change requires a bit more work.
Now that struct initializers "just" fall into the delegating case when
they're made inlinable, the only interesting case is class
initializers, which can be checked in a more direct way than what we
were doing before.
(and when the struct in question is non-fixed-layout, which was
already implemented)
This ensures that these initializers are never fieldwise in Swift 5
mode, which makes it safe for library authors to add new fields.
Initializers for non-fixed-layout structs that are inlinable or
are defined in a different module are treated as delegating
initializers.
Previously, only initializers containing a 'self.init' call were
delegating; initializers that assigned to 'self' were not, which
resulted in DI treating them as a root initializer where the
stored 'self' value was exploded into a series of stores to each
stored property member.
They were not resilient as a result.
Fixes <https://bugs.swift.org/browse/SR-5649>,
<rdar://problem/33767516>.
