When an optional requirement of an @objc protocol has a selector that
collides with an entity that has a different *Swift* name but produces
an Objective-C method with the same selector, we have an existing
diagnostic complaining about the conflict. In such cases, make a few
suggestions (with Fix-Its) to improve the experience:
* Change Swift name to match the requirement, adding or modifying the
@objc as appropriate.
* Add "@nonobjc" to silence the diagnostic, explicitly opting out of
matching an @objc requirement.
This is intended to help with migration of Swift 2 code into Swift
3. The Swift 2 code will produce selectors that match Objective-C
methods in the protocol from Swift names that don't match; this helps
fix up those Swift names so that we now match.
Fixes the rest of rdar://problem/25159872. In some sense, it's a
stop-gap for more detailed checking of near-misses for optional
requirements, but it's not clear how wide-reaching such changes would
be.
When an optional requirement of an @objc protocol has a selector that
collides with an entity that has a different *Swift* name but produces
an Objective-C method with the same selector, we have an existing
diagnostic complaining about the conflict. In such cases, make a few
suggestions (with Fix-Its) to improve the experience:
* Change Swift name to match the requirement, adding or modifying the
@objc as appropriate.
* Add "@nonobjc" to silence the diagnostic, explicitly opting out of
matching an @objc requirement.
This is intended to help with migration of Swift 2 code into Swift
3. The Swift 2 code will produce selectors that match Objective-C
methods in the protocol from Swift names that don't match; this helps
fix up those Swift names so that we now match.
Fixes the rest of rdar://problem/25159872. In some sense, it's a
stop-gap for more detailed checking of near-misses for optional
requirements, but it's not clear how wide-reaching such changes would
be.
In order for the method to be const, it should cast its Pointer member to a const void* and return it as such, not as a void*. This wasn't caught before due to using a C-style cast which stripped away the member's constness implicitly.
Calling ::strlen on nullptr is not allowed, but getLength() does not such check. We should either check for nullptr and return 0, or just assert assuming that calling getLength() on an empty Identifier is not intended and indicates a bug. Here the second approach was selected.
This class formalizes the common case of the "trailing allocation" idiom we use
frequently. I didn't spot any true bugs while making this change, but I did see
places where we were using the wrong pointer type or casting through void* for
no good reason. This will keep us honest.
I'll get to the other libraries soon.
Basic implementatation of SE-0021, naming functions with argument
labels. Handle parsing of compound function names in various
unqualified-identifier productions, updating the AST representation of
various expressions from Identifiers to DeclNames. The result doesn't
capture all of the source locations we want; more on that later.
As part of this, remove the parsing code for the "selector-style"
method names, since we now have a replacement. The feature was never
publicized and doesn't make sense in Swift, so zap it outright.
Introduce a new attribute, swift3_migration, that lets us describe the
transformation required to map a Swift 2.x API into its Swift 3
equivalent. The only transformation understood now is "renamed" (to
some other declaration name), but there's a message field where we can
record information about other changes. The attribute can grow
somewhat (e.g., to represent parameter reordering) as we need it.
Right now, we do nothing but store and validate this attribute.
Parameters (to methods, initializers, accessors, subscripts, etc) have always been represented
as Pattern's (of a particular sort), stemming from an early design direction that was abandoned.
Being built on top of patterns leads to patterns being overly complicated (e.g. tuple patterns
have to have varargs and default parameters) and make working on parameter lists complicated
and error prone. This might have been ok in 2015, but there is no way we can live like this in
2016.
Instead of using Patterns, carve out a new ParameterList and Parameter type to represent all the
parameter specific stuff. This simplifies many things and allows a lot of simplifications.
Unfortunately, I wasn't able to do this very incrementally, so this is a huge patch. The good
news is that it erases a ton of code, and the technical debt that went with it. Ignoring test
suite changes, we have:
77 files changed, 2359 insertions(+), 3221 deletions(-)
This patch also makes a bunch of wierd things dead, but I'll sweep those out in follow-on
patches.
Fixes <rdar://problem/22846558> No code completions in Foo( when Foo has error type
Fixes <rdar://problem/24026538> Slight regression in generated header, which I filed to go with 3a23d75.
Fixes an overloading bug involving default arguments and curried functions (see the diff to
Constraints/diagnostics.swift, which we now correctly accept).
Fixes cases where problems with parameters would get emitted multiple times, e.g. in the
test/Parse/subscripting.swift testcase.
The source range for ParamDecl now includes its type, which permutes some of the IDE / SourceModel tests
(for the better, I think).
Eliminates the bogus "type annotation missing in pattern" error message when a type isn't
specified for a parameter (see test/decl/func/functions.swift).
This now consistently parenthesizes argument lists in function types, which leads to many diffs in the
SILGen tests among others.
This does break the "sibling indentation" test in SourceKit/CodeFormat/indent-sibling.swift, and
I haven't been able to figure it out. Given that this is experimental functionality anyway,
I'm just XFAILing the test for now. i'll look at it separately from this mongo diff.
This is a case that the operator splitting code didn't handle because of
the bizarre lexer code for handling operators with periods in them. We had
accreted some weird special case logic for what is valid in an operator
(but which even had a special case hack for ..<). The policy is now very
simple: if an operator name starts with a dot, it is allowed to include other
dots in its name. If it doesn't, it doesn't. This allows us to get lexer
level operator splitting in cases like x=.Foo, allowing our existing operator
set that have dots in them without hacks, and provides a superior QoI
experience due to operator splitting.
This is technically a language change, but the TSPL operator grammar was
incorrect for it anyway. I will file an internal radar to get TSPL updated
with the actual behavior (now that it is defensible).
The translation from the Objective-C NSError** convention into Swift
throwing methods alters the names of methods. Move that computation
into importFullName. This should be NFC refactoring for everything
except the Swift name lookup tables, which will now correctly reflect
this name translation.
Rename 'assignment' attribute of infix operators to 'mutating'. Add
'has_assignment' attribute, which results in an implicit declaration of
the assignment version of the same operator. Parse "func =foo"
declaration and "foo.=bar" expression. Validate some basic properties of
in-place methods.
Not yet implemented: automatic generation of wrapper for =foo() if foo()
is implemented, or vice versa; likewise for operators.
Swift SVN r26508
Include a mapping from Objective-C selectors to the @objc methods that
produce Objective-c methods with those selectors. Use this to lazily
populate the Objective-C method lookup tables in each class. This makes
@objc override checking work across Swift modules, which is part of
rdar://problem/18391046.
Note that we use a single, unified selector table, both because it is
simpler and because it makes global queries ("is there any method with
the given selector?") easier.
Swift SVN r23214
@objc methods, initializers, deinitializers, properties, and
subscripts all produce Objective-C methods. Diagnose cases where two
such entities (which may be of different kinds) produce the same
Objective-C method in the same class.
As a special exception, one can have an Objective-C method in an
extension that conflicts with an Objective-C method in the original
class definition, so long as the original class definition is from a
different model. This reflects the reality in Objective-C that the
category definition wins over the original definition, and is used in
at least one overlay (SpriteKit).
This is the first part of rdar://problem/18391046; the second part
involves checking that overrides are sane.
Swift SVN r23147
reserve ? itself as a special token that cannot be defined (protecting ternary, postfix ?,
etc) but add some defensive code to prevent people from defining those operators.
<rdar://problem/17923322> allow ? as a general operator character
Swift SVN r21051
Perform redeclaration checking of global and type-member declarations
at the time of declaration, using a notion of the signature of a
declaration to determine when one declaration is a redeclaration of
another. See ValueDecl::getOverloadSignature() and
conflicting(OverloadSignature, OverloadSignature) for the specific
rules we implement. In a nutshell:
- For functions, the signature includes:
+ The full name (which includes argument names)
+ The interface type
+ Whether the function is a class/static or instance method
+ For an operator, whether it is prefix or postfix
- For a subscript, the signature is the interface type
- For everything else, the signature is just the name
This tightens the rules in a number of ways, which is reflected in the
test case churn:
- We now properly perform redeclaration checking for generics
- We now propertly handle API argument names for functions
- We now ban overloading between two variables of the same name but
different type
- We now ban overloading between a variable/property and a function
- We now ban overloading for initializers
The two test cases of actual interest are:
test/decl/overload.swift: A bunch of new test cases for our checking
test/Constraints/members.swift: I commented out a useful test for
now, because it relies on overloading between a property and a
function. We can reconsistute this test with a couple of modules.
This commit fixes at least a half dozen radars under the umbrella
<rdar://problem/11212777>. I still need to check them individually to
close them out.
Swift SVN r16691
We have to work with selectors quite often, so provide an efficient
representation for them. Switch ObjCAttr over to this representation,
which has the nice property that it efficiently represents implicit
@objc attributes with names and allows us to overwrite the Objective-C
name without losing all source information. Addresses
<rdar://problem/16478678>, and sets us up for dealing with selectors
better.
Swift SVN r16327
Swift will use the basename + argument names formulation for
names. Update the DeclName interfaces, printing, and __FUNCTION__ to
use the method syntax.
We'll still need to rework the "x.foo:bar:wibble:" syntax; that will
come (significantly) later.
Swift SVN r15763
Resolve selector references using compound name lookup, pushing DeclNames a bit deeper through the type-checker and diagnostics as necessary.
Swift SVN r14791
Make the name lookup interfaces all take DeclNames instead of identifiers, and update the lookup caches of the various file units to index their members by both compound name and simple name. Serialized modules are keyed by identifiers, so as a transitional hack, do simple name lookup then filter the results by compound name.
Swift SVN r14768
the result of the string_literal instruction.
This fixes:
<rdar://problem/15883849> Diagnostic CCP should be able to fold operations on string_literal lengths
I will follow up with cleanups this enables.
Swift SVN r13361
