This is horribly hack and slash (but enough to pass all tests) for a few reasons:
- I've #if 0'd out the tendrils of the old code
- This handles *just* what was handled before instead of being more general
- We don't have an llvm::MutableArrayRef type, so there is some really gross
const_cast'ing and other struggles to deal with its absence.
Swift SVN r1050
some redundancy in the code that always has to create an overload set
or a single declrefexpr depending on what various lookups produce.
Swift SVN r1044
a tuple with one element and no labels. This form is
treated specially in essentially every case, so it might
as well be its own expression kind.
Swift SVN r1021
After some pondering on this, I can just use DeclRefExpr(TypeAliasDecl) to
represent a named metatype, there is not need to have yet-another decl. I'm
glad about this, because it didn't seem right.
Swift SVN r999
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
test/expressions.swift:316:4: error: inferred type 'bool' is not compatible with integer literals
4 //expected-error {{inferred type 'bool' is not compatible with integer literals}}
^
test/expressions.swift:312:3: note: while processing argument of conversion function to inferred type 'int_test5'
plus func convert_from_integer_literal(val : bool) -> int_test5 {} // expected-note {{while processing argument of conversion function to inferred type 'int_test5'}}
^
test/expressions.swift:315:1: note: while converting 'var' initializer to declared type
var il_g : int_test5 = // expected-note {{while converting 'var' initializer}}
^
Swift SVN r961
through 1 level of indirection in literal conversions. This allows the
testcase to define its "convert_from_integer_literal" function in terms
of the library 'int' type instead of requiring them to always be defined
in terms of Builtin:: types. We get the expected chained conversion calls
in the AST.
Swift SVN r957
import swift
var c : int8 = 4
becomes:
(translation_unit
(brace_stmt
(import_decl 'swift')
(var_decl 'c' type='int8'
(call_expr type='int8'
(declref_expr type='(val : int8) -> int8' decl=convert_from_integer_literal)
(integer_literal_expr type='int8' value=4))))) <<- this is Builtin::int8
... which is finally great. The only problem is that it causes massive explosions
in IRGen, which isn't expecting this yet. I'll look at this this evening if John
doesn't beat me to it :)
Swift SVN r954
