One minor revision: this lifts the proposed restriction against
overriding a non-open method with an open one. On reflection,
that was inconsistent with the existing rule permitting non-public
methods to be overridden with public ones. The restriction on
subclassing a non-open class with an open class remains, and is
in fact consistent with the existing access rule.
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
and provide a fix-it to move it to the new location as referenced
in SE-0081.
Fix up a few stray places in the standard library that is still using
the old syntax.
Update any ./test files that aren't expecting the new warning/fix-it
in -verify mode.
While investigating what I thought was a new crash due to this new
diagnostic, I discovered two sources of quite a few compiler crashers
related to unterminated generic parameter lists, where the right
angle bracket source location was getting unconditionally set to
the current token, even though it wasn't actually a '>'.
It looks like migration fixits are done, and this doesn't
expose any new bugs that were not possible before, because
you could already define typealiases inside protocol
extensions.
To prevent some compiler_crasher regressions, add a simple
circularity-breaking hack. I'll need to do a sweep to clean
these up some day soon.
'fileprivate' is considered a broader level of access than 'private',
but for now both of them are still available to the entire file. This
is intended as a migration aid.
One interesting fallout of the "access scope" model described in
758cf64 is that something declared 'private' at file scope is actually
treated as 'fileprivate' for diagnostic purposes. This is something
we can fix later, once the full model is in place. (It's not really
/wrong/ in that they have identical behavior, but diagnostics still
shouldn't refer to a type explicitly declared 'private' as
'fileprivate'.)
As a note, ValueDecl::getEffectiveAccess will always return 'FilePrivate'
rather than 'Private'; for purposes of optimization and code generation,
we should never try to distinguish these two cases.
This should have essentially no effect on code that's /not/ using
'fileprivate' other than altered diagnostics.
Progress on SE-0025 ('fileprivate' and 'private')
- Any is made into a keyword which is always resolved into a TypeExpr,
allowing the removal of the type system code to find TheAnyType before
an unconstrained lookup.
- Types called `Any` can be declared, they are looked up as any other
identifier is
- Renaming/redefining behaviour of source loc methods on
ProtocolCompositionTypeRepr. Added a createEmptyComposition static
method too.
- Code highlighting treats Any as a type
- simplifyTypeExpr also does not rely on source to get operator name.
- Any is now handled properly in canParseType() which was causing
generic param lists containing ‘Any’ to fail
- The import objc id as Any work has been relying on getting a decl for
the Any type. I fix up the clang importer to use Context.TheAnyType
(instead of getAnyDecl()->getDeclaredType()). When importing the id
typedef, we create a typealias to Any and declare it unavaliable.
Also adds:
- Any is caught before doing an unconstrained lookup, and the
protocol<> type is emitted
- composition expressions can be handled by
`PreCheckExpression::simplifyTypeExpr` to so you can do lookups like (P
& Q).self
- Fixits corrected & new tests added
- Typeref lowering cases should have been optional
- This fixes a failing test case.
This commit defines the ‘Any’ keyword, implements parsing for composing
types with an infix ‘&’, and provides a fixit to convert ‘protocol<>’
- Updated tests & stdlib for new composition syntax
- Provide errors when compositions used in inheritance.
Any is treated as a contextual keyword. The name ‘Any’
is used emit the empty composition type. We have to
stop user declaring top level types spelled ‘Any’ too.
Allow 'static' (or, in classes, final 'class') operators to be
declared within types and extensions thereof. Within protocols,
require operators to be marked 'static'. Use a warning with a Fix-It
to stage this in, so we don't break the world's code.
Protocol conformance checking already seems to work, so add some tests
for that. Update a pile of tests and the standard library to include
the required 'static' keywords.
There is an amusing name-mangling change here. Global operators were
getting marked as 'static' (for silly reasons), so their mangled names
had the 'Z' modifier for static methods, even though this doesn't make
sense. Now, operators within types and extensions need to be 'static'
as written.
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
Right now 'fileprivate' is parsed as an alias for 'private' (or
perhaps vice versa, since the semantics of 'private' haven't changed
yet). This allows us to migrate code to 'fileprivate' without waiting
for the full implementation.
We'd really like to say that private decls can't affect other files,
but we don't have enough information at parse-time:
- Private members of non-private classes still show up in vtables,
which affects subclasses and callers in other files.
- Private stored properties of non-private structs change the
layout of the struct.
- Private types may be used in private stored properties, affecting
the layout of the containing struct.
- Private decls of /any kind/ can be used as the initial value of a
stored property without an explicit type.
private class Evil {
class func defaultAlignment() -> Alignment { return .evil }
}
public struct Character {
// Inferred type here!
private var alignment = Evil.defaultAlignment()
}
To be safe and correct, go back to only ignoring method bodies.
https://bugs.swift.org/browse/SR-1030
Previously getInterfaceType() would punt to getType() if no
interface type was set. This patch changes getInterfaceType()
to assert if no interface type is set, and updates various
places to set the interface type explicitly.
This brings us a step closer to removing PolymorphicFunctionType.
known as #sourceLocation. #setline was an intermediate but never endorsed state.
Upgrade the migration diagnostics for SE-0066 and SE-0049 to be errors instead of warnings.
In C++ we can't have nice things. The macro name 'defer' collided with
use of 'defer' in the Tokens.def file and we were already doing horrible
workarounds in a couple of places to allow them to be included into the
same file. So use a less awesome but more robust name (thanks to Joe for
suggesting SWIFT_DEFER).
Incidentally, sort a bunch of #inlcudes.
Consider this code:
struct A<T> {
struct B {}
struct C<U> {}
}
Previously:
- getDeclaredType() of 'A.B' would give 'A<T>.B'
- getDeclaredTypeInContext() of 'A.B' would give 'A<T>.B'
- getDeclaredType() of 'A.C' would give 'A<T>.C'
- getDeclaredTypeInContext() of 'A.C' would give 'A<T>.C<U>'
This was causing problems for nested generics. Now, with this change,
- getDeclaredType() of 'A.B' gives 'A.B' (*)
- getDeclaredTypeInContext() of 'A.B' gives 'A<T>.B'
- getDeclaredType() of 'A.C' gives 'A.C' (*)
- getDeclaredTypeInContext() of 'A.C' gives 'A<T>.C<U>'
(Differences marked with (*)).
Also, this change makes these accessors fully lazy. Previously,
only getDeclaredTypeInContext() and getDeclaredIterfaceType()
were lazy, whereas getDeclaredType() was built from validateDecl().
Fix a few spots where the return value wasn't being checked
properly.
These functions return ErrorType if a circularity was detected via
the generic parameter list, or if the extension did not resolve.
They return Type() if the extension cannot be resolved *yet*.
This is pretty subtle, and I'll need to do another pass over
callers of these functions at some point. Many of them should be
moved over to use getSelfInContext(), getSelfOfContext() and
getSelfInterfaceType() instead.
Finally, this patch consolidates logic for diagnosting invalid
nesting of types.
The parser had some code for protocols in bad places and bad things
inside protocols, and Sema had several different bail-outs for
bad things in protocols, nested generic types, and stuff nested
inside protocol extensions.
Combine all of these into a single set of checks in Sema. Note
that we no longer give up early if we find invalid nesting.
Leaving decls unvalidated and un-type-checked only leads to
further problems. Now that all the preliminary crap has been
fixed, we can go ahead and start validating these funny nested
decls, actually fixing some crashers in the process.
Goes back to Swift 2.2 behavior of treating the 'typealias' keyword inside a protocol as a deprecated form of an associatedtype. To get the newer (but still partly buggy) behavior of treating it as an actual typealias, add "-Xfrontend -enable-protocol-typealiases" to the compile invocation. 'decl/typealias/typealias.swift' now uses this flag to continue testing the enabled behavior.
This patch includes testsuite changes to show each of the decls supported.
Next step is to migrate the stdlib + testsuite + corelibs: I'd would *greatly* appreciate help with this.
After that is done, deprecation + migration of the old form can happen.
Since there still are some holes in this feature, and I haven't had time to
fill them lately: Go back to the 2.2 behavior of treating 'typealias' keyword
in protocols as an associated type, and emit a deprecation warning.
Commented out tests specifically for typealiases in protocols for now, and
random validation tests that crash or not based on whether keyword is interpreted as associatedtype or typealias updated.
Before, a keyword in an inheritance clause would lead to a long list of errors
not really showing what was wrong.
A special case is added to handle protocol composition; in inheritance clauses
the protocols don't have to be composed with 'protocol<>'.
The fix for methods to lower the dynamic method type from the substituted AST type of the expression also needed to be applied to the optional chaining, subscript, and property paths.
This also exposed a problem in the Clang importer, where imported subscript accessors would get the unbound generic context type as their Self parameter type instead of the type with the correct generic parameters. Fix this by renaming the all-too-convenient ParamDecl::createSelf factory to `createUnboundSelf`, and introduce a new `createSelf` that uses the bound generic type.
Fixes rdar://problem/26447758.
The verifier now asserts that Throws, ThrowsLoc and isBodyThrowing()
match up.
Also, add /*Label=*/ comments where necessary to make the long argument
lists easier to read, and cleaned up some inconsistent naming conventions.
I caught a case where ClangImporter where we were passing in a loc as
StaticLoc instead of FuncLoc, but probably this didn't affect anything.
A function declaration like:
func dog cow() {}
... yields a bunch of noisy diagnostics about expecting certain tokens, like
"expected '(' in argument list of function declaration", or the dreaded
"consecutive statements on a line must be separated by ';'". Instead,
look for a repeated identifier in this position and affirm that the
repeated identifier wasn't expected, suggesting that maybe this was a
single identifier with a break in it.
rdar://problem/25761940
- Remove stray newline
- Adjust wording when recommending backticks for a keyword identifier
- Provide fix-it when encountering a keyword as an identifier
rdar://problem/25761380
When declaring a function like func repeat(){}, the diagnostic is
"expected an identifier" but 'repeat' looks like a reasonable
identifier at first glance, so actually say why it isn't.
rdar://problem/25761380
Example:
@available(*, unavailable, renamed: "setter:CGRect.diagonal(self:_:)")
func scale(_ rect: inout CGRect, toDiagonalLength length: CGFloat)
(My examples are getting more and more contrived, but there you go.)
This is pretty much the same as the getter handling, except that we also
want to strip off the '&' at the call site.
Example:
@available(*, unavailable, renamed: "getter:UIColor.CIColor(self:)")
func convertToCIColor(_ color: UIColor) -> CIColor
This syntax looks weird, but it's the same as what's used by
NS_SWIFT_NAME. I intend to improve the diagnostic text once I have
all the fix-its working.
Next up: setters!
