To answer "did the user specify this, or is it implicit", stick a couple
of is-implicit bits in InfixOperatorDecl, and thread them through
serializaton/deserialization.
Swift SVN r20067
enforce its own little constraints. The type checker isn't using it for
anything, and it is just clutter.
This resolves <rdar://problem/16656024> Remove @assignment from operator implementations
Swift SVN r19960
modifiers and with the func implementations of the operators. This resolves the rest of:
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
Swift SVN r19931
This only tackles the protocol case (<rdar://problem/17510790>); it
does not yet generalize to an arbitrary "class" requirement on either
existentials or generics.
Swift SVN r19896
accessors due to syntax errors.
This allows AST clients to consult the source range of the braces for
computed properties even when there are errors.
Addresses the first part of <rdar://problem/16747499>.
Swift SVN r19843
SIL SROA needs to know when a struct's visible fields actually completely make up the struct value, which becomes an issue if we start importing structs with yet-unrepresentable unions and bitfields. Track this in the ClangImporter, and add an 'aggregateHasUnreferenceableStorage' predicate to SILType to make it easy for passes to query. Part of <rdar://problem/17555966>.
Swift SVN r19720
This always wrapped a single GenericTypeParamDecl *, and provided no benefit
over just using the decl directly.
No (intended) functionality change.
Swift SVN r19628
...because you can't match them properly in switches.
In the future, we could consider allowing private enum cases in a
resilient public enum, which essentially forces the user to consider the
default case.
Swift SVN r19620
- Change the parser to accept "objc" without an @ sign as a contextual
keyword, including the dance to handle the general parenthesized case.
- Update all comments to refer to "objc" instead of "@objc".
- Update all diagnostics accordingly.
- Update all tests that fail due to the diagnostics change.
- Switch the stdlib to use the new syntax.
This does not switch all tests to use the new syntax, nor does it warn about
the old syntax yet. That will be forthcoming. Also, this needs a bit of
refactoring, which will be coming up.
Swift SVN r19555
(when -enable-access-control is used)
Note that this is currently circumvented when looking up requirements in a
protocol. We're not currently set up to pass along the DeclContext where a
protocol's requirements are requested /from/, so we're just relying on the
fact that the requirements have the same visibility as the protocol in 1.0.
Swift SVN r19355
No validation is done yet on whether the user-specified access control makes
sense in context, but all ValueDecls should at least /have/ accessibility now.
/Still/ no tests yet. They will be much easier to write once we're actually
enforcing access control and/or printing access control.
Swift SVN r19143
Add the ability to store optionality of the ObjC method parameters and return
type in a sidecar. This hardcoded info is then used to import Objective C
object pointer types as either optional or none, instead of implicitly
unwrapped optionals.
The feature is enabled with -import-with-tighter-objc-types=true.
Swift SVN r19048
-Hide vars that have a private type.
-Hide functions that have a parameter with private type or a parameter name with leading underscore.
-Minor change in StringUTF16.swift to avoid printing "func generate() -> IndexingGenerator<_StringCore>".
rdar://17027294
Swift SVN r18623
Post-WWDC, we need to update the type checking process to make these kinds of infinite loops impossible without checking special flags.
Swift SVN r18598
Attribute validation is not naturally idempotent, and we shouldn’t need to make it so. Rather, we should only do the validation once. This fixes an immediate issue with @NSManaged in multi-file situations (<rdar://problem/16879162>) and avoids some redundant work.
Longer term, we have a ton of redundant visitation that needs to be addressed <rdar://problem/16905199>.
Swift SVN r18039
Eliminate the duplicate half-broken bridging logic in emitClassConstructorAllocator by referencing foreign initializers through their foreign-to-native thunks, which SILGen knows how to emit already. Do the same thing for factory initializers by suppressing their normal allocating initializer codegen and just referencing the usual foreign-to-native thunk for them. This fixes <rdar://problem/16853205> because we get the ownership thunking right now.
Swift SVN r17840
This preserves more of source info (e.g. API name location) and simplifies things since
we don't have to construct ParamDecls for the unnamed parameters later on.
Swift SVN r17828
We were accidentally forcing all members of a class to be instantiated in two places:
- by trying to look up an existing destructor decl in the class, and
- by adding the implicit destructor to the class, because addMember needlessly called loadAllMembers.
Fix the former problem by adding a 'has destructor' bit to ClassDecl so we can track whether the implicit destructor needs to be added without querying its members. Fix the latter by making IterableDeclContext::addMember not call loadAllMembers, and making loadAllMembers not barf when it sees existing members in the context.
Together with Jordan and JoeP's changes, this makes many interpreter tests now compile 3-20x faster.
Swift SVN r17562
This basically just means "it's a CF class" for now,
but you could imagine applying this to all sorts of
class-like types from peer runtimes that we can't
support all possible language features for.
There are quite a few language features that require
fairly deep object-model integration to implement,
like subclassing and adding polymorphic methods.
Some of those features, like final classes, are useful
to generally support as attributes, but most of
them aren't. At least in the short term, it makes
sense to have a big hammer we can hit things with.
Swift SVN r17428
Subscript declarations were still encoding the names of index
variables in the subscript type, which unintentionally made them
keyword arguments. Bring subscript declarations into the modern day,
using compound names to encode the subscript argument names, which
provides consistency for the keyword-argument world
<rdar://problem/14462349>. Note that arguments in subscripts default
to not being keyword arguments, which seems like the right default.
We now get keyword arguments for subscripts, so one can overload
subscripts on the names of the indices, and distinguish at the call
site. Under -strict-keyword-arguments, we require strictness here as well.
The IRGen/IDE/SILGen test updates are because the mangling of common
subscripts changed from accidentally having keyword arguments to not
having keyword arguments.
Swift SVN r17393
Introduce a model where an argument name is a keyword argument if:
- It is an argument to an initializer, or
- It is an argument to a method after the first argument, or
- It is preceded by a back-tick (`), or
- Both a keyword argument name and an internal parameter name are
specified.
Provide diagnostics Fix-Its to clean up cases where the user is
probably confused, i.e.,
- "_ x: Int" -> "x: Int" where "x" would not have been a keyword
argument anyway
- "x x: Int" -> "`x: Int"
This covers the compiler side of <rdar://problem/16741975> and
<rdar://problem/16742001>.
Update the AST printer to print in this form, never printing just
a type for a parameter name because we're also going to adopt
<rdar://problem/16737312> and it was easier to move the tests once
rather than twice.
Standard library and test updates coming separately.
Swift SVN r17056
Fixes
<rdar://problem/16438738> Ensure that RawOptionSet conformance is printed for
imported NS_OPTIONS
and probably other latent bugs.
Swift SVN r16971
This restructures IfConfigDecl/Stmt to be a list of clauses controlled
by a condition. This makes it straight-forward to drop in #elseif support.
While I'm in here, this patch moves checking for extraneous stuff at the
end of the #if line from the lexer to the parser. This means that you can
now put a comment on the same line as a #if/#else/#elseif/#endif.
Swift SVN r16912
(and a similar issue for subscripts)
In Cocoa, a property can be declared readonly in the public interface of a
class and readwrite in a class extension. Similarly, a protocol can require
a readable property, but a category then declares the property as readwrite.
Swift doesn't like having two of the same declaration, and which one ended
up being used was order-dependent.
This change doesn't really fix the problem, but it does paper over it.
Now, when the importer sees a redeclaration of a readonly property as
readwrite, it forcibly updates the existing property with the new setter.
This isn't entirely correct; the redeclaration doesn't show up in its category,
and this doesn't respect visibility (i.e. the change to readwrite occurs in
a separate module that isn't visible in all source files). (But extensions
don't respect visibility in any other way, either, even in pure Swift code.)
At its heart, this is just a mismatch between Objective-C allowing
redeclarations that add capabilities and Swift not having redeclarations
at all. At some point, it may make more sense to model this as an overload,
or to mark the original declaration invalid, but for now this seems to be
the most contained change we can get that fixes the problem.
<rdar://problem/16692921>
Swift SVN r16832
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
