"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
Rename AccessibilityAttr to AccessControlAttr and
SetterAccessibilityAttr to SetterAccessAttr, then track down the last
few uses of "accessibility" that don't have to do with
NSAccessibility. (I left the SourceKit XPC API alone because that's
supposed to be more stable.)
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
This commit changes the 'Accessibility' enum to be named 'AccessLevel'.
Pushes __consuming through the frontend and extends existing
attribute-based diagnsotics to cover it. Unlike `nonmutating`,
__consuming is allowed in class methods, though it makes little
sense to put it there.
Rather than pretend that the requirement signature of a protocol is a
full, well-formed generic signature that one can meaningfully query,
treat it as a flat set of requirements. Nearly all clients already did
this, but make it official. NFC
When printing an associated type that is not provided (e.g. during
code-completion of overrides), we want to print the type even if there
are errors.
rdar://problem/30451236
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
As such, we no longer insert two placeholders for initializers that
need two vtable slots; instead we record that in the
MissingMemberDecl. I can see MissingMemberDecl growing to be something
we'd actually show to users, that can be used for other kinds of
declarations that don't have vtable entries, but for now I'm not going
to worry about any of that.
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.
Implement exhaustiveness checking in Sema with rich error messages. The
algorithm used is a variant of the one described in Fengyun Liu's paper
"A Generic Algorithm for Checking Exhaustivity of Pattern Matching"
published in the EPFL conference, and Luc Maranget's seminal paper
"Warnings for Pattern Matching"
The Space Engine views pattern matching as a problem of projecting the
scrutinee of a pattern-match into a "Space", then iteratively
constructing a Space from the cases. Taking the difference of this
master space and the covered spaces yields the "holes" left over or
reveals a completely covered space.
The algorithm also extends trivially to redundancy checks in patterns,
but that check is already implemented in SILGen and this algorithm does
not improve upon it.
That is, if you have this declaration:
struct Outer {
struct Inner {
// ...
}
}
and you're just printing 'Inner', print it like this:
struct Outer.Inner {
// ...
}
This comes up with the ClangImporter's import-as-member feature, and
is also about to affect how error code enums are imported as well.
This is currently only enabled in certain contexts: always when
printing interfaces, and for types (but not other members) when
printing declarations for Quick Help.
rdar://problem/28208090
We would consider types that structurally contain generic parameters as being depthless, leading to same-type requirements being printed at the wrong depth, defeating the SIL parser. Superclass constraints can also involve a generic base class referring to generic parameters at depth.
Add a 'hasExplicitAnyObject()' bit to ProtocolCompositionType
to represent canonical composition types containing '& AnyObject'.
Serialize this bit and take it into account when building
ExistentialLayouts.
Rename ProtocolCompositionType::getProtocols() to getMembers()
since it can contain classes now, and update a few usages that
need further attention with FIXMEs or asserts.
For now, nothing actually constructs these types, and they will
trigger arounds asserts. Upcoming patches will introduce support
for this.
* Use the presence of an argument type to check for associated values
hasOnlyCasesWithoutAssociatedValues returns true for any serialized
enum declaration whether or not it has cases. This never really came
up because it's mostly relevant to Sema's proto-deriving mechanism. Fix
this by using the presence of the case's argument type instead.
* Separate checks for presence of cases and enum simplicity
Necessary because the old behavior was an artifact of the
implementation.
We already have an option to skip /all/ unavailable decls. Singling
out the ones that are specifically unavailable-in-Swift just makes
testing harder.
This will not affect interface generation in Xcode, which sets that
option to skip all unavailable decls.
In the general case, this is done by reverse engineering the "best"
places for requirements to go from the requirement signature.
Conformance/superclass requirements like Self: Foo and Self.T: Bar defer
to the inheritance clause if they appear there, or are attached to the
protocol where clause or T (respectively) if not. A conformance
requirement like Self.T.U: Baz will go on T (if T is declared in the
protocol being printed).
Same-type requirements always go in where clauses, and specifically a
where clause of an associated type that is mentioned in them, so
something simple like Self.T.U == Int goes on the T associated type
definition, and similarly Self.T.U == Self.V will go on V (it's kinda
nonsense, but also more directly connected to V). There's a left-bias
for cases without an "obvious" choice, meaning something more
complicated like Self.T.U == Foo<Self.V> will end up on T.
Requirements that don't fit elsewhere will go on the
protocol (e.g. Self.AssocTypeFromSuperProtocol == Int).
1. Make sure the actions taken by fixits are reflected in diagnostics messages.
2. Issue missing cases diagnostics at the start of the switch statement instead of its end.
3. Use <#code#> instead of <#Code#> in the stub.
