This commit adds tracking of the reason a declaration reference is potentially
unavailable to the UnavailableToOptionalExpr AST node and to OverloadChoice. We
will use this reason during SILGen to emit the appropriate run-time check and
during typechecking to provide more helpful diagnostics.
To keep OverloadChoice as small as possible, we encode the reason as an index
into a vector of reasons stored in a given instance of ConstraintSystem (this is
the same approach that Fix takes).
This commit adds Sema/OverloadChoice.cpp (for the parts of OverloadChoice that
now rely on ConstraintSystem) and AST/Availability.h (to bring in
availability-related structures without TypeRefinementContext).
Swift SVN r22377
attribute checking on a per attribute basis. It makes a lot more sense for a
given attribute to think about all of the decl kinds it may or may not apply to
rather than all decl kinds thinking about the cross products of attributes they
may apply to.
Start by adding a new check to reject @final in structs and enums.
Swift SVN r15925
"Playground Transform." This is an
instrumentation pass that adds calls to a
function called playground_log at locations of
interest. Roughly speaking, these locations are
- Initialization of variables
- Modification of variables
- Expressions returning values
- Application of mutating methods on objects
The playground transform currently only finds
modifications of variables, but the intent is to
make all of these cases work.
It is enabled by a frontend option, and can
also be invoked by calling
swift::performPlaygroundTransform(SF)
which is the way LLDB, its main client, will
use it.
The frontend option is intended for testing,
and indeed I will add tests for this
transformation in the coming week as I bring
more functionality online.
Swift SVN r14801
If an enum has no cases with payloads, make it implicitly Equatable and Hashable, and derive default implementations of '==' and 'hashValue'. Insert the derived '==' into module context wrapped in a new DerivedFileUnit kind, and arrange for it to be codegenned with the deriving EnumDecl by adding a 'DerivedOperatorDecls' array to NominalTypeDecls that gets visited at SILGen time.
Swift SVN r14471
Have ArchetypeBuilder key the archetypes it produces by the abstract {depth,index} position of generic parameters rather than by the identity of particular GenericTypeParamDecls. Tighten the signature of AbstractTypeParamDecl-taking methods to only take GenericTypeParamDecls; that's the only case that comes up anymore. Introduce 'addGenericParameter' and 'getArchetype' overloads that work with GenericTypeParamTypes and DependentMemberTypes in addition to those that work with GenericTypeParamDecls.
Move ArchetypeBuilder.cpp from 'Sema' to 'AST' to correspond to its header's location.
In this version of the patch, we handle the problem of invalid nested protocol decls by simply ignoring the parent generic context of ProtocolDecls in validateGenericTypeSignature, which allows for better recovery and avoids the crash problems with the ErrorType approach I tried in the previous patch.
Swift SVN r10983
Have ArchetypeBuilder key the archetypes it produces by the abstract {depth,index} position of generic parameters rather than by the identity of particular GenericTypeParamDecls. Tighten the signature of AbstractTypeParamDecl-taking methods to only take GenericTypeParamDecls; that's the only case that comes up anymore. Introduce 'addGenericParameter' and 'getArchetype' overloads that work with GenericTypeParamTypes and DependentMemberTypes in addition to those that work with GenericTypeParamDecls.
Move ArchetypeBuilder.cpp from 'Sema' to 'AST' to correspond to its header's location.
When we parse something like 'protocol P { protocol Q {} }', eagerly give the erroneous nested protocol Q an ErrorType to suppress type-checking of the declaration. Otherwise, the nested implicit 'Self' parameters, which are fixed depth 0 index 0 in the generic parameter space, will collide in the ArchetypeBuilder.
Swift SVN r10966
rdar://14151649 suggests that it should be a warning, but I don’t see a reason
why it should not be an error. We have no legacy code that relies on this.
Swift SVN r9976
If an enum has a valid raw type, synthesize a RawType associated type along with fromRaw and toRaw methods.
An implicit conformance to RawRepresentable is not yet set up. This synthesis may need to be done earlier in order for the names to be available during type-checking of definitions in the enum too.
Swift SVN r8890
gen pass has had it disabled for some time, so snip the last few uses
in the REPL and zap it.
Goodbye old friend, you were a very useful stopgap.
Swift SVN r6885
This eliminates all of the coercion and overloading code, which is the
main part of the old type checker. There are some residual expression
nodes (such as overloaded subscript/member expressions) as well as
residual goop in the type system ("unresolved" types at various
levels) that will still need to be removed.
Swift SVN r5409
This paves the way for having a Swift module importer. The eventual goal
here is to eliminate all explicit uses of the Clang module loader, but
I'm not going to push too hard on that for now.
Swift SVN r5092
Tie the laziness into name lookup, so any attempt to look for the
constructors in a struct will ensure that the implicit default
constructor gets generated and added to the lookup set.
Laziness here is not about performance. Rather, it is a step toward
defining the implicit default constructor only when all instance
variables have implicit default constructors. Because Swift allows
struct definitions to come in any order, we need to wait until we've
done the first round of type-checking on declarations, then resolve
implicit default constructors as-needed, finalizing them all before
moving on to check function bodies.
Swift SVN r4888
The five parts are:
- Support code and high-level entry points
- Constraint generation
- Constraint solving
- Constraint application
- Diagnostics
No functionality change.
Swift SVN r4447
generation from an expression that has not been type-checked. One can
see the constraints introduced by an expression by using
:dump_constraints <expression>
within the REPL. We're still missing several major pieces of
constraint generation:
- We don't yet "open up" references to polymorphic types
- We don't print out the child constraint systems in the dump, so
it's not at all obvious what happens within overloading (and I'm not
convinced I like my representation anyway)
- There are no tests whatsoever
- Member constraints are still very, very weird
Swift SVN r2624
placed on generic parameters and associated types within the generic
parameter clause, expands those requirements out to form the complete
set of requirements, then assigns archetypes for each of the generic
parameters and their nested types (recursively).
Swift SVN r2379
types. Use this simple overload resolution scheme in both type
checking and type coercion, simplifying both code paths a bit.
There is one significant semantic change here: we allow overload
resolution to operate on (structured) dependent arguments, which
allows for more overload filtering before we come in with the type
coercion hammer. For example, we can now properly type-check
var x : int32;
x + 0;
Swift SVN r1310
A function argument clause is now one or more patterns (which
must be parenthesized and explicitly type all positions) not
separated by arrows; the first arrow then separates off the
return type.
Revisions to language reference forthcoming.
Swift SVN r1099
just move the Sema code into the Parser library. There is no way to use one without
the other. The library formerly known as Sema will get renamed.
Swift SVN r542
This CMake-based build system is based on the one in Clang, simplified
and tweaked slightly to better support building a smaller Xcode
project that links against an existing LLVM (rather than importing all
of LLVM into this project).
Swift SVN r403
