in favor of a single-element non-canonical TupleType) broke the type
system, in that supposed sugar (the TupleType) supported a different
set of operations from the canonical type. For example, a
single-element unlabelled tuple type supports elementwise projection
(foo.$0), but the underlying element does not (or supports it
differently).
The IR-gen failure was due to a very related problem: IR-gen
was not updated to reflect that a single unlabelled tuple element
is the same type as its element type, and therefore it was giving
different representations to these types ({ %foo } and %foo,
respectively), which broke widespread assumptions.
The removal of ParenType was done in pursuit of an AST invariant
that's not actually particularly interesting in the first place
and which, furthermore, is problematic to attain.
Swift SVN r1182
it is now a single element TupleType(x). In order to preserve sane behavior,
we force grouping parens to be non-canonical and have them desugar down to
their underlying element type.
This does cause an IRGen testcase failure that looks like it was just working
accidentally before (though I don't really understand what is going on). I
filed rdar://10967479 to track it.
Swift SVN r1146
- introduce the concept of qualifiers on l-value types
- teach overload resolution and coercion how to drop explicitness
- require explicitness on normal [byref] arguments
- make 'this' [byref(implicit)]
- special-case '&' as a unary operator in the parser to make it
produce an expression which type-checks as turning implicit l-values
into explicit ones.
Obvious missing pieces:
- updating LangRef
- we should really complain about ever trying to rvalue-convert an
explicit l-value
- maybe qualification should play a part in overload resolution
- we should diagnose attempts to declare unary '&' operators
- there's a test case in expressions.swift which suggests my logic is
slightly off
But I am out of time, and these will have to wait.
Swift SVN r1119
anonymous member is actually one of these.
A func decl is curried over all of its parameter clauses,
as long as they're written without parentheses. So the body
of a func is the body of the "most curried" function:
func foo(x:int) -> (y:int) -> int {
// This is the body of the function that takes 'y'.
// It returns an int.
}
func bar(x:int) -> ((y:int) -> int) {
// This is the body of the function that takes 'x'.
// It returns a functon of type (y:int) -> int.
}
Swift SVN r993
that LLVM supports. The standard library still only exports float and double,
but the swift core should be more general. Yay for PPC128 :)
Swift SVN r973
their ASTContext without bloating everything. Basically, now instead of having
a canonical type point to itself when canonical, it points to the ASTContext
when canonical. This means that Canonical types always have direct access to
their context and non-canonical ones just indirect through the canonical type
pointer to get to it (so it's two jumps away) by using a PointerUnion.
This should make type manipulation more straight-forward.
While we're at it, we actually memoize type canonicalization. Before we
forgot to remember the result in the canonical type pointer in Type.
Swift SVN r755
Also use the new getAdvancedLoc() method instead of hacking
on SMLoc directly.
Also fix the warning/note/error methods to forward through ASTContext
instead of being replicated everywhere.
Swift SVN r750
diagnostics over to it.
There are a few differences between this diagnostic engine and Clang's
engine:
- Diagnostics are specified by a .def file (Diagnostics.def), rather
than via tblgen, which drastically simplifies the build and makes
code completion work when you add a new diagnostic.
- Calls to the "diagnose()" method are safely typed based on the
argument types specified in the .def file, so it's harder to write a
diagnostic whose expected arguments (in the string) and whose actual
arguments (in the code) don't match.
- It uses variadic templates, so it hangs with the cool kids.
Swift SVN r734
