double-quoted string literals that contain a single extended grapheme cluster
SEGCL by default infer type String, but you can ask to infer Character
for them.
Single quoted literals continue to infer Character.
Actual extended grapheme cluster segmentation is not implemented yet,
<rdar://problem/16755123> Implement extended grapheme cluster
segmentation in libSwiftBasic
This is part of
<rdar://problem/16363872> Remove single quoted characters
Swift SVN r17034
Introduce some infrastructure that allows us to speculatively apply
localized fixes to expressions during constraint solving to fix minor
typos and omissions. At present, we're able to introduce the fixes
during constraint simplification, prefer systems with fewer fixes when
there are multiple fixes, and diagnose the fixes with Fix-Its.
Actually rewriting the AST to reflect what the Fix-Its are doing is
still not handled.
As a start, introduce a fix that adds '()' if it appears to have been
forgotton, producing a diagnostic like this if it works out:
t.swift:8:3: error: function produces expected type 'B'; did you mean
to call it with '()'?
f(g)
^
()
Note that we did regress in one test case
(test/NameBinding/multi-file.swift), because that diagnostic was
getting lucky with the previous formulation.
Swift SVN r16937
Language features like erasing concrete metatype
values are also left for the future. Still, baby steps.
The singleton ordinary metatype for existential types
is still potentially useful; we allow it to be written
as P.Protocol.
I've been somewhat cavalier in making code accept
AnyMetatypeType instead of a more specific type, and
it's likely that a number of these places can and
should be more restrictive.
When T is an existential type, parse T.Type as an
ExistentialMetatypeType instead of a MetatypeType.
An existential metatype is the formal type
\exists t:P . (t.Type)
whereas the ordinary metatype is the formal type
(\exists t:P . t).Type
which is singleton. Our inability to express that
difference was leading to an ever-increasing cascade
of hacks where information is shadily passed behind
the scenes in order to make various operations with
static members of protocols work correctly.
This patch takes the first step towards fixing that
by splitting out existential metatypes and giving
them a pointer representation. Eventually, we will
need them to be able to carry protocol witness tables
Swift SVN r15716
While diagnosing the cause of a constraint system failure, being able to ignore some failures but not others allows us to produce slightly better error messages in some cases. This is in support of JoeG's current work.
Swift SVN r15560
Originally, I didn't want this because I felt it made
unchecked-optional too non-local --- it wasn't always
obvious that an assignment might crash because it was
implicitly dropping optionality. And that's still a
concern! But I think that overall, if we're prepared
to accept that that danger is inherent in @unchecked T?,
this is a more consistent model: @unchecked T? means
that we don't know enough about the value to say for
certain that nil is a real possibility, so we'll let
you coerce it to the underlying type, and that coercion
just might not be dynamically safe. No more special
cases for calls and member access (to the user; of
course, to the implementation these are still special cases
because of lookup and overload resolution).
Swift SVN r14796
to a conversion restriction.
I'm pretty certain that this is *supposed* to be NFC, in that
any subtle differences between the two blocks are actually
inadvertent bugs.
Unify the two places that switch out on a conversion
restriction; I'm pretty sure they're supposed to be doing
the exact same thing, and that any differences between
flags/subFlags and whether to log the restriction kind
are inadvertent.
Swift SVN r14794
Resolve selector references using compound name lookup, pushing DeclNames a bit deeper through the type-checker and diagnostics as necessary.
Swift SVN r14791
This was blocked by some type-checker issues:
First, we weren't registering a constraint restriction when
tail-recursing in matchTypes (as opposed to when creating
a disjunction because multiple conversions applied). Do so,
and move the set of constraint restrictions to the constraint
system in order to make this simpler. A large amount of similar
solver state is already there, and of course solving the system
already prospectively modifies the constraint graph.
Second, only set up a potential existential conversion when
working with concrete types. Without this, we would fail to
typecheck conversions to optional protocol types, but not
optional class/struct/whatever types. It's not clear whether
whether we should ever really be considering conversions when
either of the types is non-concrete.
I believe it was the second fix which removed a need for a !
in the NewArray test case.
Swift SVN r14637
- purge @inout from comments in the compiler except for places talking about
the SIL argument convention.
- change diagnostics to not refer to @inout
- Change the astprinter to print InoutType without the @, so it doesn't show
up in diagnostics or in closure argument types in code completion.
- Implement type parsing support for the new inout syntax (before we just
handled patterns).
- Switch the last couple of uses in the stdlib (in types) to inout.
- Various testcase updates (more to come).
Swift SVN r13564
This eliminates the duplication of type variables that represent the member types of existing type variables. I'm unable to trigger this with a test case at the moment, but it becomes important when we begin to substitute type variables through protocol conformances.
Swift SVN r12971
its basic logic in libAST, which both makes it easier to
implement and makes it possible to use in the places that
should care about it, i.e. in IR-gen and SIL-gen.
Per Doug, none of the places that were introducing
trivial-subtype constraints really needed to do so rather
than just using subtype constraints.
Swift SVN r12679
with qualifiers on it, we have two distinct types:
- LValueType(T) aka @lvalue T, which is used for mutable values on the LHS of an
assignment in the typechecker.
- InOutType(T) aka @inout T, which is used for @inout arguments, and the implicit
@inout self argument of mutable methods on value types. This type is also used
at the SIL level for address types.
While I detangled a number of cases that were checking for LValueType (without checking
qualifiers) and only meant @inout or @lvalue, there is more to be done here. Notably,
getRValueType() still strips @inout, which is totally and unbearably wrong.
Swift SVN r11727
- Switch all the 'self' mutable arguments to take self as @inout, since
binding methods to uncurried functions expose them as such.
- Eliminate the subtype relationship between @inout and @inout(implicit),
which means that we eliminate all sorts of weird cases where they get
dropped (see the updated testcases).
- Eliminate the logic in adjustLValueForReference that walks through functions
converting @inout to @inout(implicit) in strange cases.
- Introduce a new set of type checker constraints and conversion kinds to properly
handle assignment operators: when rebound or curried, their input/result argument
is exposed as @inout and requires an explicit &. When applied directly (e.g.
as ++i), they get an implicit AddressOfExpr to bind the mutated lvalue as an
@inout argument.
Overall, the short term effect of this is to fix a few old bugs handling lvalues.
The long term effect is to drive a larger wedge between implicit and explicit
lvalues.
Swift SVN r11708
Rather than performing a two-pass walk over all of the constraints in
the system to attach them to type variables, use the existing type
variable -> constraints mapping in the constraint graph to make this a
faster single-pass process. Also clarify the type bindings a little
bit. Improves type checking time for the standard library by ~3%.
Swift SVN r11098
This shaves about 10% off the number of solution states explored when
type-checking the standard library, although it doesn't improve
overall time by much. In a more targeted benchmark, 1 + 2.0 + 1, we
get a 21% speedup.
Swift SVN r11033
Provides a 4% speedup type-checking the standard library. This
optimization brings the global constraint graph within 2% of the prior
solution, and prevents us from creating multiple constraint graphs per
constraint system, so flip the switch to always use the global
constraint graph.
Swift SVN r11003
Whenever we bind a type variable or merge two type variables, add
those constraints that could be affected to a worklist. Simplification
continues processing constraints in the worklist until the worklist is
empty.
This change reduces the number of constraints that we visit but can't
simplify by ~13x in the standard library, but this doesn't translate
into a performance win. More investigation is needed here.
Note that the worklist is only in use when we have a global constraint
graph, which isn't enabled by default yet.
Swift SVN r10936
Make the constraint graph into a scoped data structure that tracks the
changes that occur within a given scope, undoing those changes when
the scope is popped off the scope stack. The constraint graph's scopes
align with the constraint solver's scopes. Synchronize the solver's
constraint addition/removal operations with the constraint graph, and
improve our verification to make sure these stay in sync.
This is still a work in progress. Type checking the standard library
is about 5% slower with the per-constraint-system constraint graph
rather than building a new constraint graph each iteration *after*
simplification, and there are two intruiging test failures that appear
to be the constraint solver breaking its own invariants. Therefore,
this feature is off by default. See the ConstraintSystem constructor
for the one-line change to turn it back on.
Swift SVN r10927
Rather than building the constraint graph after simplification and
then never modifying it, build the constraint graph before
simplification and update it as simplification adds/removes
constraints. This is a step toward two separable performance goals:
(1) having a single constraint graph that evolves over the lifetime of
the constraint system, rather than building a new constraint graph at
each solver step, and (2) using the constraint graph to implement a
worklist traversal during simplification, so we only re-simplify those
constraints that might be affected by a choice the solver makes.
This behavior is currently optional with an ugly in-source flag
because while it works, it's a rather painful performance regression
that I don't want to subject everyone to. I'll turn it on for everyone
once it's a win, which should be after either (1) or (2) above is
implemented.
Swift SVN r10924
We still perform path compression for the representative of a type
variable, but the fixed type of a type variable is no longer
compressed: it either doesn't exist or is stored in the
representative. This preserves the equivalence-class structure of type
variables even after they've been bound to fixed types.
Swift SVN r10921
This per-component ranking selects the best partial solution (or at
least minimizes the set of partial solutions) before composing the
results of the partial solutions into set of solutions. This way, we
don't end up creating a huge number of solutions (i.e., all
permutations of the partial solutions) that we'll then have to compare.
27% improvement in type-checking time for the standard library.
Swift SVN r10865
This completes the FileUnit refactoring. A module consists of multiple
FileUnits, which provide decls from various file-like sources. I say
"file-like" because the Builtin module is implemented with a single
BuiltinUnit, and imported Clang modules are just a single FileUnit source
within a module.
Most modules, therefore, contain a single file unit; only the main module
will contain multiple source files (and eventually partial AST files).
The term "translation unit" has been scrubbed from the project. To refer
to the context of declarations outside of any other declarations, use
"top-level" or "module scope". To refer to a .swift file or its DeclContext,
use "source file". To refer to a single unit of compilation, use "module",
since the model is that an entire module will be compiled with a single
driver call. (It will still be possible to compile a single source file
through the direct-to-frontend interface, but only in the context of the
whole module.)
Swift SVN r10837
Using "T" as the contextual type, either for an implicit conversion
(in the coercion case) or as a downcast (for the checked-cast case),
opens up more type-inference opportunities. Most importantly, it
allows coercions such as "1 as UInt32" (important for
<rdar://problem/15283100>). Additionally, it allows one to omit
generic arguments within the type we're casting to.
Some additional cleanup to follow.
Swift SVN r10799
