the printed interface.
Previously we printed the typechecked and uniqued requirements and the result was non-sensical.
Long-term the requirements will be preserved in a better form but for now print the requirements
and serialize them.
rdar://19963093
Swift SVN r27680
Allow an unversioned 'deprecated' attribute to specify unconditional
deprecation of an API, e.g.,
@availability(*, deprecated, message="sorry")
func foo() { }
Also support platform-specific deprecation, e.g.,
@availability(iOS, deprecated, message="don't use this on iOS")
func bar() { }
Addresses rdar://problem/20562871.
Swift SVN r27355
Move the map that keeps track of conforming decl -> requirement from ASTContext
to a nominal type's ConformanceLookupTable, and populate it lazily.
This allows getSatisfiedProtocolRequirements() to work with declarations from module files.
Test on the SourceKit side.
Part of rdar://20526240.
Swift SVN r27353
Allow an unversioned 'deprecated' attribute to specify unconditional
deprecation of an API, e.g.,
@availability(*, deprecated, message="sorry")
func foo() { }
Also support platform-specific deprecation, e.g.,
@availability(iOS, deprecated, message="don't use this on iOS")
func bar() { }
Addresses rdar://problem/20562871.
Swift SVN r27339
This is an internal-only affordance for the numerics team to be able to work on SIMD-compatible types. For now, it can only increase alignment of fixed-layout structs and enums; dynamic layout, classes, and other obvious extensions are left to another day when we can design a proper layout control design.
Swift SVN r27323
Currently untestable (due to SILGen's inability to handle throwing
@objc methods), but testing will become trivial once that's in place.
Swift SVN r27294
Introduce basic validation for throwing @objc initializers, e.g., a
failable @objc initializer cannot also be throwing. However,
Objective-C selector computation is broken.
Swift SVN r27292
Currently untestable (due to SILGen's inability to handle throwing
@objc methods), but testing will become trivial once that's in place.
Swift SVN r27290
These aren't really orthogonal concerns--you'll never have a @thick @cc(objc_method), or an @objc_block @cc(witness_method)--and we have gross decision trees all over the codebase that try to hopscotch between the subset of combinations that make sense. Stop the madness by eliminating AbstractCC and folding its states into SILFunctionTypeRepresentation. This cleans up a ton of code across the compiler.
I couldn't quite eliminate AbstractCC's information from AST function types, since SIL type lowering transiently created AnyFunctionTypes with AbstractCCs set, even though these never occur at the source level. To accommodate type lowering, allow AnyFunctionType::ExtInfo to carry a SILFunctionTypeRepresentation, and arrange for the overlapping representations to share raw values.
In order to avoid disturbing test output, AST and SILFunctionTypes are still printed and parsed using the existing @thin/@thick/@objc_block and @cc() attributes, which is kind of gross, but lets me stage in the real source-breaking change separately.
Swift SVN r27095
"Autoclosure" is uninteresting to SIL. "noescape" isn't currently used by SIL and we shouldn't have it until it has a meaningful effect on SIL. "throws" should be adequately represented by a SIL function type having an error result.
Swift SVN r27023
The set of attributes that make sense at the AST level is increasingly divergent from those at the SIL level, so it doesn't really make sense for these to be the same. It'll also help prevent us from accidental unwanted propagation of attributes from the AST to SIL, which has caused bugs in the past. For staging purposes, start off with SILFunctionType's versions exactly the same as the FunctionType versions, which necessitates some ugly glue code but minimizes the potential disruption.
Swift SVN r27022
Another step toward using the conformance lookup table for
everything. This uncovered a tricky little bug in the conformance
lookup table's filtering logic (when asking for only those
conformances explicitly specified within a particular context) that
would end up dropping non-explicit conformances from the table (rather
than just the result).
Ween a few tests off of -enable-source-import, because they'll break
otherwise.
Swift SVN r27021
to represent them, and just dropped them on the ground. Now we parse them,
persist them in the AST, and "resolve" them from the expr grammar, but still
drop them on the ground. This is progress towards fixing: rdar://20135489
Swift SVN r26828
Have TypeChecker's constructor register itself as the lazy resolver,
and its destructor unregister itself. This introduces the
completely-sensible restriction that there can only be one type
checker active for an ASTContext at a time, which is the case already.
Use ASTContext's lazy resolver in a single place that's been causing
trouble (rdar://problem/20363958, rdar://problem/19773096), where
deserializing a protocol conformance can cause us to pass a null lazy
resolver into the protocol conformance table, which doesn't handle it
well. This commit fixes those issues, which I'm unable to reduce down
to a sane-enough test case to commit.
This commit implies a ton of cleanup work to eliminate LazyResolver
parameters from *everywhere*, deriving them from the ASTContext in the
few places they're needed as well. It's a good direction, but that
cleanup can be evolutionary.
Swift SVN r26824
- Enhance PBD with a whereExpr/elseStmt field to hold this.
- Start parsing the pattern of let/var decls as a potentially refutable pattern. It becomes
a semantic error to use a refutable pattern without an 'else' (diagnostics not in place yet).
- Change validatePatternBindingDecl to use 'defer' instead of a goto to ensure cleanups on exit.
- Have it resolve the pattern in a PBD, rewriting it from expressions into pattern nodes when valid.
- Teach resolvePattern to handle TypedPatterns now that they can appear (wrapping) refutable patterns.
- Teach resolvePattern to handle refutable patterns in PBD's without initializers by emitting a diagnostic
instead of by barfing, fixing regressions on validation tests my previous patch caused, and fixing
two existing validation test crashers.
Sema, silgen, and more tests coming later.
Swift SVN r26706
Start parsing a "trailing" where clause for extension declarations, which follows the extended type name and (optional) inheritance clause. Such a where clause is only currently permitted for protocol extensions right now.
When used on a protocol extension, it allows one to create a more-constrained protocol extension, e.g.,
extension CollectionType where Self.Generator.Element : Equatable { ... }
which appears to be working, at least in the obvious cases I've tried.
More cleanup, tests, and penance for the previous commit's "--crash" introductions still to come.
Swift SVN r26689
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
Start allowing extensions to redeclare type parameters, which will get
different archetypes from the original nominal type. When an extension
does not redeclare type parameters, silently clone the nominal type's
generic type parameters so we still get distinct type parameters.
When deserializing an extension, wire up its generic parameter list so
we get the right archetypes for its members. This doesn't change the
module format (that happened earlier).
When determining the substitutions for an associated type that comes
from a different declaration context from the conformance that will
own the witness, be sure to map into the conformance's
DeclContext. Otherwise, we'll end up with tangled archetypes.
Fixes rdar://problem/16519588.
Swift SVN r26483
Primarily, unique normal protocol conformances and reference them via
a conformance ID. This eliminates the use of trailing records for
normal protocol conformances and (more importantly) the cases were we
would write incomplete conformances. The latter could cause problems
if we ever ended up deserializing an incomplete conformance without
also deserializing a complete record for that same conformance.
Secondarily, simplify the way we write conformances. They are now
always trailing records, and we separate out the derived conformance
kinds (specialized/inherited) from either a reference to a normal
conformance in the current module file (via a normal conformance ID)
or via a cross-reference to a conformance in another module file
(currently always a normal conformance, but this need not always be
the case). As part of this, make each conformance record
self-sustaining, so we don't have to push information down to the
reading routines (e.g., the conforming type) to actually produce a
proper conformance. This simplifies deserialization logic further.
Swift SVN r26482
Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
The lit and testsuite changes are hacks to work around the problems with the -enable-source-import model. Some day, we’ll get a “real” mock SDK with compiled overlays so these hacks can go away.
Swift SVN r26327
Previously, a multi-pattern var/let decl like:
var x = 4, y = 17
would produce two pattern binding decls (one for x=4 one for y=17). This is convenient
in some ways, but is bad for source reproducibility from the ASTs (see, e.g. the improvements
in test/IDE/structure.swift and test/decl/inherit/initializer.swift).
The hardest part of this change was to get parseDeclVar to set up the AST in a way
compatible with our existing assumptions. I ended up with an approach that forms PBDs in
more erroneous cases than before. One downside of this is that we now produce a spurious
"type annotation missing in pattern"
diagnostic in some cases. I'll take care of that in a follow-on patch.
Swift SVN r26224
The deallocating parameter convention is a new convention put on a
non-trivial parameter if the caller function guarantees to the callee
that the parameter has the deallocating bit set in its object header.
This means that retains and releases do not need to be emitted on these
parameters even though they are non-trivial. This helps to solve a bug
in +0 self and makes it trivial for the optimizer to perform
optimizations based on this property.
It is not emitted yet by SILGen and will only be put on the self
argument of Deallocator functions.
Swift SVN r26179
This changes 'if let' conditions to take general refutable patterns, instead of
taking a irrefutable pattern and implicitly matching against an optional.
Where before you might have written:
if let x = foo() {
you now need to write:
if let x? = foo() {
The upshot of this is that you can write anything in an 'if let' that you can
write in a 'case let' in a switch statement, which is pretty general.
To aid with migration, this special cases certain really common patterns like
the above (and any other irrefutable cases, like "if let (a,b) = foo()", and
tells you where to insert the ?. It also special cases type annotations like
"if let x : AnyObject = " since they are no longer allowed.
For transitional purposes, I have intentionally downgraded the most common
diagnostic into a warning instead of an error. This means that you'll get:
t.swift:26:10: warning: condition requires a refutable pattern match; did you mean to match an optional?
if let a = f() {
^
?
I think this is important to stage in, because this is a pretty significant
source breaking change and not everyone internally may want to deal with it
at the same time. I filed 20166013 to remember to upgrade this to an error.
In addition to being a nice user feature, this is a nice cleanup of the guts
of the compiler, since it eliminates the "isConditional()" bit from
PatternBindingDecl, along with the special case logic in the compiler to handle
it (which variously added and removed Optional around these things).
Swift SVN r26150
The contract for LazyResolver::loadAllMembers() was that the caller
would handle actually adding the members, since it was an iterable
declaration context and could centralize that (simple) logic. However,
this fails in the Clang importer in rare but amusing ways when some of
the deferred actions (e.g., finishing a protocol conformance) depend
on having the members already set. The deferred action occurs after
the member list is complete in ClangImporter's loadAllMembers(), but
before its caller actual set the member list, leaving incomplete
conformances. Fixes rdar://problem/18884272.
Swift SVN r25630
...rather than trying to serialize them again, which could lead to attempting
to cross-reference an ExtensionDecl, which can't be done.
rdar://problem/19794141
Swift SVN r25292
Local type declarations are saved in the source file during parsing,
now serialized as decls. Some of these may be defined in DeclContexts
which aren't Decls and previously weren't serialized. Create four new
record kinds:
* PatternBindingInitializer
* DefaultArgumentInitializer
* AbstractClosureExpr
* TopLevelCodeDecl
These new records are used to only preserve enough information for
remangling in the debugger, and parental context relationships.
Finally, provide a lookup API in the module to search by mangled name.
With the new remangling API, the debugging lifecycle for local types
should be complete.
The extra LOCAL_CONTEXT record will compressed back down in a
subsequent patch.
Swift SVN r24739
with more explicit/semantic conversions in and out.
Using a PointerUnion with overlapping pointer types
is both error-prone and pretty close to illegible.
Swift SVN r24707
Changing the design of this to maintain more local context
information and changing the lookup API.
This reverts commit 4f2ff1819064dc61c20e31c7c308ae6b3e6615d0.
Swift SVN r24432
