Fixes two bugs in Clang importer and deserialization code that were found by
the verifier:
(1) FuncExprs were created with a null FuncDecl
(2) BoundGenericType that was created by Clang importer for UnsafePtr<> and
other magic types did not have substitutions.
Swift SVN r8073
ConstructorDecl::getBody() and DestructorDecl::getBody() return 'BraceStmt *'.
After changing the AST representation for functions, FuncDecl::getBody() will
return 'BraceStmt *' and FuncDecl::getFuncExpr() will be gone.
Swift SVN r8050
That is, 1234 is a CInt, 1234U is a CUnsignedInt, and 1234LL is a CLongLong.
Oh, and 3.14F is a CFloat.
One caveat here is that it is not actually possible in C to write a literal
INT_MIN:
-0x80000000 is two tokens and the literal part is unsigned
(-INT_MAX - 1) is several tokens
I've simply dropped this test for now, but it might be confusing in the rare
case where an INT_MIN-like value is used as a sentinel.
<rdar://problem/13839025>
Swift SVN r7639
This was not likely an error-free change. Where you see problems
please correct them. This went through a fairly tedious audit
before committing, but comments might have been changed incorrectly,
not changed at all, etc.
Swift SVN r7631
Each nested archetype X.Y corresponds to an associated type named 'Y'
within one of the protocols to which X conforms. Record the associated
type within the archetype itself. When performing type substitutions,
use that associated type to extract the corresponding type witness
rather than looking for the type itself. This is technically more
correct (since we used the type witness for type checking), and a step
toward pulling type substitutions into the AST.
Swift SVN r7624
Previously, we were creating the type corresponding to
class/struct/union declarations as part of creating the declaration
node, which happens at parse time. The main problem with this (at the
moment) occurs with nested nominal types, where we'd end up with the
wrong "parent" type when the type was nested inside an extension
(because the extension hadn't been resolved at the time we accessed
the parent's type). Amusingly, only code completion observed this,
because the canonical type system hid the problem. The churn in the
code-completion tests come from the fact that we now have the proper
declared type for class/struct/union declarations within extensions.
Take a step toward order-independent type checking by setting the type
of a class/struct/union declaration in type checking when we either
find the declaration (e.g., due to name lookup) or walk to the
declaration (in our walk of the whole translation unit to type-check
it), extending the existing TypeChecker::validateTypeDecl() entry
point and adding a few more callers.
The removeShadowedDecls() hack is awful; this needs to move out to the
callers, which should be abstracted better in the type checker anyway.
Incremental, non-obvious step toward fixing the representation of
polymorphic function types. This yak has a *lot* of hair.
Swift SVN r7444
At present, this is a distinction without a difference. However, it's
a step toward detangling archetypes from the interface of a
polymorphic function.
Swift SVN r7405
Previously, TypeAliasDecl was used for typealiases, generic
parameters, and assocaited types, which is hideous and the source of
much confusion. Factor the latter two out into their own decl nodes,
with a common abstract base for "type parameters", and push these
nodes throughout the frontend.
No real functionality change, but this is a step toward uniquing
polymorphic types, among other things.
Swift SVN r7345
Break cycles agressively when we find circular class inheritance. The
stronger AST invariants prevent us from having to check for loops
everywhere in the front end.
Swift SVN r7325
Before this change, DeclContext of all imported decls was set to the first
imported module.
No tests now, will be tested by future code completion commits.
Swift SVN r6949
We haven't fully updated references to union cases, and enums still are not
their own thing yet, but "oneof" is gone. Long live "union"!
Swift SVN r6783
This makes it very clear who is depending on special behavior at the
module level. Doing isa<ClangModule> now requires a header import; anything
more requires actually linking against the ClangImporter library.
If the current source file really can't import ClangModule.h, it can
still fall back to checking against the DeclContext's getContextKind()
(and indeed AST currently does in a few places).
Swift SVN r6695
Standardize on the more-common "superclass" and "subclass" terminology
throughout the compiler, rather than the odd mix of base/derived and
super/sub.
Also, have ClassDecl only store the Type of the superclass. Location
information will be part of the inheritance clause for parsed classes.
Swift SVN r6687
Previously the result of a failed import was always cached, even if it
failed because a forward declaration was missing.
There is an actual problem here: NSString methods in the ObjectiveC
module (specifically, -description and +description, and later
-debugDescription) are not being imported if ObjectiveC is imported
before Foundation. However, previously this resulted in a crash.
Swift SVN r6524
standard library modules because the user did not import the module.
For example, using 'SEL' without importing ObjectiveC (and while importing
other Clang module) used to assert.
Swift SVN r6337
-Refactor Parser to stop creating types
-Refactor TypeChecker to create types by resolving TypeReprs.
-Remove "validation" bit from the type system.
We don't need to "validate" every type that gets created but there's still a validation bit in TypeLoc,
necessary because of generic substitutions.
Swift SVN r6326
Give oneof bodies syntax consistent with other NominalTypes. Give oneof elements first-class declaration syntax using the 'case' introducer, as suggested by Jordan. Oneofs can contain 'case' decls, functions, properties, and constructors, but not physical ivars. Non-oneof scopes cannot contain 'case' decls. Add some QoI to the oneof 'case' parser to also parse and complain about things that resemble switch 'case' labels inside decl contexts.
Swift SVN r6211
This the first part for improving source location fidelity for types,
changes to follow:
-The Parser will not create any types, it will just create TypeReprs.
-The type checker will create the types by going through TypeReprs.
-IdentifierType will be removed.
Swift SVN r6112
When checking a type's conformance against a protocol, we can deduce
the values of associated types. Make these associated types visible to
qualified name lookup so that (for example) VectorEnumeratorType does
not need to define the Element type. It is deduced from the signautre
of next(), and made available as, e.g.,
VectorEnumeratorType<Int>.Element through the Enumerator protocol
conformance. Fixes <rdar://problem/11510701>, but with some lingering
dependencies on lazy type resolution (<rdar://problem/12202655>).
Note that the infrastructure here is meant to be generalized to
support default implementations in protocols, but there are several
pieces still not in place.
Swift SVN r6073
Previously, this set of protocols was computed lazily, which fails
catastrophically if getProtocols() was invoked before validation of
the types in a type/extension's "inherited" list.
Swift SVN r5924
Improve our representations of casts in the AST and SIL so that 'as!' and 'is' (and eventually 'as?') can share almost all of the same type-checking, SILGen, and IRGen code.
In the AST, we now represent 'as!' and 'is' as UnconditionalCheckedCastExpr and IsaExpr, respectively, with the semantic variations of cast (downcast, super-to-archetype, archetype-to-concrete, etc.) discriminated by an enum field. This keeps the user-visible syntactic and type behavior differences of the two forms cleanly separated for AST consumers.
At the SIL level, we transpose the representation so that the different cast semantics get their own instructions and the conditional/unconditional cast behavior is indicated by an enum, making it easy for IRGen to discriminate the different code paths for the different semantics. We also add an 'IsNonnull' instruction to cover the conditional-cast-result-to-boolean conversion common to all the forms of 'is'.
The upshot of all this is that 'x is T' now works for all the new archetype and existential cast forms supported by 'as!'.
Swift SVN r5737
binary compatible.
This enables us to import MacTypes.h types as stdlib swift types to avoid name
conflicts. We also import stdint.h types as stdlib swift types.
We can not map 'long double'-based ctypes.Float80 to swift.Float80 because size
of long double is 128 according to SysV ABI, and I compare that against what
the type name says (I did not find a way to find the size of the type).
Darwin.Float80 is a struct, so I don’t think we can import it as swift.Float80.
So with import Darwin, Float80 is still ambiguous.
I had to rename test/ClangModules/ctypes.swift ->
test/ClangModules/ctypes_test.swift because other tests do 'import ctypes',
which picks up 'ctypes.swift'.
Swift SVN r5727
Just refer to "class archetypes" and "class protocols". Change 'isClassBounded' methods to 'requiresClass', which is a character shorter.
Swift SVN r5674
Import ObjC protocol decls into Swift with the [class_protocol] and [objc] attributes. Add an -import-objc-protocol-types flag to reenable import of ObjC qualified object types as Swift protocol types.
Swift SVN r5604
Change AssignStmt into AssignExpr; this will make assignment behave more consistently with assignment-like operators, and is a first step toward integrating '=' parsing with SequenceExpr resolution so that '=' can obey precedence rules. This also nicely simplifies the AST representation of c-style ForStmts; the initializer and increment need only be Expr* instead of awkward Expr*/AssignStmt* unions.
This doesn't actually change any user-visible behavior yet; AssignExpr is still only parsed at statement scope, and typeCheckAssignment is still segregrated from the constraint checker at large. (In particular, a PipeClosureExpr containing a single assign expr in its body still doesn't use the assign expr to resolve its own type.) The parsing issue will be addressed by handling '=' during SequenceExpr resolution. typeCheckAssignment can hopefully be reworked to work within the constraint checker too.
Swift SVN r5500
Unprototyped C functions can't sensibly be reflected in the Swift type
system, and are awful besides, so don't import them. Then, always go
through importFunctionType to import function types, fixing the
missing pattern in <rdar://problem/13992215>.
Swift SVN r5494
Explicit detect (and reject) conversions that aren't class
downcasts. We'll want to lift some of these restrictions later (see
<rdar://problem/14013456>), but for now we just reject them with a
decent diagnostic (rather than crashing).
When an explicit downcast is actually just a coercion, complain,
provide a Fix-It, and update the AST appropriately.
This also splits the checking of unchecked downcasts into two different
constraint systems: one for the context of expression, and one for the
subexpression, then compares the results. This eliminates the need to
model "can be downcast to" in the constraint solver, and makes it
easier to provide good diagnostics.
Swift SVN r5377
We had an inconsistency where the synthesized Swift getter/setters were bridged but the VarDecl wasn't, causing assertion failures in SILGen.
Swift SVN r5366
