wide
Currently integer literals are 64-bit. In order to allow checking for overflow
while converting an integer literal to swift.UInt/Int* types we need at least
65 bits. But floating point numbers (Float32, Float64, Float80) are
BuiltinIntegerLiteralConvertible. In order to allow spelling large floating
point constants, we allow 136-bit literals.
Rationale: 128 bits are enough to represent the absolute value of min/max IEEE
Binary32, and we need 1 bit to represent the sign. 136 is 129 rounded to the
next 8 bits.
The plan is to have builtins that do the overflow check and convert 136-bit
numbers to the required width. We need these builtins for both integers and
floating point numbers to ensure that 136-bit numbers are folded into sane
constants in SIL and don’t escape to LLVM IR.
Swift SVN r9253
Now that we have a solid Optional-based story for dynamic casts, it's no longer needed, and can be expressed as '(x as T)!'. Future refinement of the 'as' syntax will deal with the unfortunate extra parens.
Swift SVN r9181
Right now this is just an extra layer of indirection for the decls,
operators, and imports in a TU, but it's the first step towards compiling
multiple source files at once without pretending they're all in a single
file. This is important for the "implicit visibility" feature, where
declarations from other source files in the same module are accessible
from the file currently being compiled.
Swift SVN r9072
As with the monadic '?', we treat any left-bound '!' as a postfix
operator. Currently, it extracts the value of its optional
subexpression, failing at run-time if the optional is empty.
Swift SVN r8948
When building the (dependent) interface type of generic functions,
don't resolve any generic parameter types to archetypes, even those at
outer levels. Instead, keep everything dependent.
As a special case, the type of 'self' gets baked into the parameter
patterns with archetypes, so reconstruct the 'self' type ourselves.
The actual output of this is still frustratingly untestable, but we
get decent coverage because all of the type checking of generic
functions goes through here first.
Swift SVN r8936
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
Parse '_' as a DiscardAssignmentExpr. Type-check it as an lvalue, and check that it only appears in the LHS of AssignExprs. During matching pattern resolution, convert it into an AnyPattern. In SILGen, when we see '_' in the LHS of an assignment, ignore the corresponding RHS rvalue.
Swift SVN r8848
Though we plan to revamp the casting syntax, our general plan is for this form of cast, which does a conditional cast and returns an Optional<T> result, to be the one that survives. Parse the status-quo syntax 'x as? T' and type-check it. While we're here, refresh some fixits for redundant casts that referred to the now defunct 'as T' coercion syntax to completely remove whatever cast was in the source code.
Swift SVN r8805
Require that either T be default constructible or that the user provide a closure that maps indices to initial values. We don't actually call the closure yet to initialize the array; that's blocked on function abstraction difference <rdar://problem/13251236>.
Swift SVN r8801
Instead of relying on the subpattern being a well-formed TuplePattern, let's track our own subelements so we can associate them to properties and validate them ourselves.
Swift SVN r8771
These are the terms sent out in the proposal last week and described in
StoredAndComputedVariables.rst.
variable
anything declared with 'var'
member variable
a variable inside a nominal type (may be an instance variable or not)
property
another term for "member variable"
computed variable
a variable with a custom getter or setter
stored variable
a variable with backing storage; any non-computed variable
These terms pre-exist in SIL and IRGen, so I only attempted to solidify
their definitions. Other than the use of "field" for "tuple element",
none of these should be exposed to users.
field
a tuple element, or
the underlying storage for a stored variable in a struct or class
physical
describes an entity whose value can be accessed directly
logical
describes an entity whose value must be accessed through some accessor
Swift SVN r8698
for all AbstractFunctionDecl's. Refactor ASTDump of AbstractFunctionDecl's
to all go through the same funnel point and print it in the right place.
Swift SVN r8242
AnyFunctionRef is a universal function reference that can wrap all AST nodes
that represent functions and exposes a common interface to them. Use it in two
places in SIL where CapturingExpr was used previously.
AnyFunctionRef allows further simplifications in other places, but these will
be done separately.
Swift SVN r8239
and remove DeclContext base class from FuncDecl, ConstructorDecl and
DestructorDecl
This decreases the number of DeclContexts to 7 and allows us to apply
alignas(8) to DeclContext.
Swift SVN r8186
If an OpaqueValueExpr is only used in one place, mark it as such. SIL
generation will then elide the retain/release pair associated with
each reference to the opaque value, instead consuming the value at the
point of use.
Swift SVN r8072
These helper expressions will eventually be used by SILGen to help
package up the optional values. I expect that we'll eventually have
library builtins for this, so consider this a stop-gap until those
appear.
As part of this, make OpaqueValueExpr a bit more usable: it can now
persist in the AST as a placeholder, but its uses must be within AST
subtrees of some specific introduction point (similarly to how Clang's
OpaqueValueExpr works).
Swift SVN r8051
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
