- Addresses many common user-reported "expression too complex" bugs, including rdar://problem/18876786.
- Shaves up to 10% off of the total time to run our unit tests. (Unscientifically measured on my iMac: 427.46s before, 385.17s after.)
Swift SVN r24514
Require 'as' when converting from Objective-C type to native type (but
continue to allow implicit conversion from native to Objective-C). This
conversion constraint is called ExplicitConversion; all implicit
conversions are covered by the existing Conversion constraint. Update
standard library and tests to match.
Swift SVN r24496
This has been long in coming. We always had it in IRGenOpts (in string form).
We had the version number in LangOpts for availability purposes. We had to
pass IRGenOpts to the ClangImporter to actually create the right target.
Some of our semantic checks tested the current OS by looking at the "os"
target configuration! And we're about to need to serialize the target for
debugging purposes.
Swift SVN r24468
When dealing with multiple levels of generic parameters, the mapping
from potential archetypes down to actual archetypes did not have
access to the archetypes for outer generic parameters. When same-type
requirements equated a type from the inner generic parameter list with
one from the outer generic parameter list, the reference to the outer
generic parameter list's type would remain dependent. For example,
given:
struct S<A: P> {
init<Q: P where Q.T == A>(_ q: Q) {}
}
we would end up with the dependent type for A (τ_0_0) in the same-type
constraint in the initializer requirement.
Now, notify the ArchetypeBuilder of outer generic signatures (and,
therefore, outer generic parameters), so that it has knowledge of the
mapping from those generic parameters to the corresponding
archetypes. Use that mapping when translating potential archetypes to
real archetypes. Additionally, when a potential archetype is mapped to
a concrete type (via a same-type constraint to a concrete type),
substitute archetypes for any dependent types within the concrete
type.
Remove a bunch of hacks in the compiler that identified dependent
types in "strange" places and tried to map them back to
archetypes. Those hacks handled some narrow cases we saw in the
standard library and some external code, but papered over the
underlying issue and left major gaps.
Sadly, introduce one hack into the type checker to help with the
matching of generic witnesses to generic requirements that follow the
pattern described above. See ConstraintSystem::SelfTypeVar; the proper
implementation for this matching involves substituting the adoptee
type in for Self within the requirement, and synthesizing new
archetypes from the result.
Fixes rdar://18435371, rdar://18803556, rdar://19082500,
rdar://19245317, rdar://19371678 and a half dozen compiler crashers
from the crash suite. There are a few other radars that I suspect this
fixes, but which require more steps to reproduce.
Swift SVN r24460
Changing the design of this to maintain more local context
information and changing the lookup API.
This reverts commit 4f2ff1819064dc61c20e31c7c308ae6b3e6615d0.
Swift SVN r24432
rdar://problem/18295292
Locally scoped type declarations were previously not serialized into the
module, which meant that the debugger couldn't reason about the
structure of instances of those types.
Introduce a new mangling for local types:
[file basename MD5][counter][identifier]
This allows the demangle node's data to be used directly for lookup
without having to backtrack in the debugger.
Local decls are now serialized into a LOCAL_TYPE_DECLS table in the
module, which acts as the backing hash table for looking up
[file basename MD5][counter][identifier] -> DeclID mappings.
New tests:
* swift-ide-test mode for testing the demangle/lookup/mangle lifecycle
of a module that contains local decls
* mangling
* module merging with local decls
Swift SVN r24426
a non-native owner. This is required by Slice, which
will use an ObjC immutable array object as the owner
as long as all the elements are contiguous.
As part of this, I decided it was best to encode the
native requirement in the accessor names. This makes
some of these accessors really long; we can revisit this
if we productize this feature.
Note that pinning addressors still require a native
owner, since pinning as a feature is specific to swift
refcounting.
Swift SVN r24420
The archetype opener only needs to perform basic substitutions; let it
do so, avoiding the creation of a pile of type variables that simply
get immediately bound.
Swift SVN r24399
Permit non-Ordinary accesses on references to functions,
with the semantics of devirtualizing the call if the
function is a class member. This is important for
constructing direct call to addressors from synthesized
materializeForSet accessors: for one, it's more
performant, and for another, addressors do not currently
appear in v-tables.
Synthesize trivial accessors for addressed class members.
We weren't doing this at all before, and I'm still not
sure we're doing it right in all cases. This is a mess.
Assorted other fixes. The new addressor kinds seem
to work now.
Swift SVN r24393
Change all the existing addressors to the unsafe variant.
Update the addressor mangling to include the variant.
The addressor and mutable-addressor may be any of the
variants, independent of the choice for the other.
SILGen and code synthesis for the new variants is still
untested.
Swift SVN r24387
use a thin function type.
We still need thin-function-to-RawPointer conversions
for generic code, but that's fixable with some sort of
partial_apply_thin_recoverable instruction.
Swift SVN r24364
Append "did you mean 'static'?" when hitting the unimplemented class
stored properties diagnostic in a class context.
Provide a fix-it for typing "static final" in a class, which is
redundant.
Swift SVN r24358
This reverts commit r23030.
This puts non-primary archetypes back in the all-archetypes list,
which is the deepest underlying problem behind
rdar://problem/19049566.
Conflicts:
lib/AST/ArchetypeBuilder.cpp
validation-test/compiler_crashers/0033-error.swift
validation-test/compiler_crashers/035-multiple-typecheck-segfault.swift
Swift SVN r24333
The previous patch to allow static class stored properties
inadvertently allowed 'class final' spellings for static
stored properties in classes. This patch only allows 'static'
spellings to create the global storage.
Swift SVN r24323
rdar://problem/17198298
- Allow 'static' in protocol property and func requirements, but not 'class'.
- Allow 'static' methods in classes - they are 'class final'.
- Only allow 'class' methods in classes (or extensions of classes)
- Remove now unneeded diagnostics related to finding 'static' in previously banned places.
- Update relevant diagnostics to make the new rules clear.
Swift SVN r24260
Previously the "as" keyword could either represent coercion or or forced
downcasting. This change separates the two notions. "as" now only means
type conversion, while the new "as!" operator is used to perform forced
downcasting. If a program uses "as" where "as!" is called for, we emit a
diagnostic and fixit.
Internally, this change removes the UnresolvedCheckedCastExpr class, in
favor of directly instantiating CoerceExpr when parsing the "as"
operator, and ForcedCheckedCastExpr when parsing the "as!" operator.
Swift SVN r24253
if-let statements (also while and var, of course) that include multiple bindings
and where clauses.
SILGen support still remains, it currently just asserts on the new constructs.
Swift SVN r24239
wrapping up rdar://16323038. Pieces still remaining are a Clang attribute+
importer support for it, plus adoption in the stdlib (tracked by other radars).
Swift SVN r24223
- Make @autoclosure imply @__noescape everywhere, not just in the stdlib.
- Change various noescape diagnostics to refer to "parameters", not "arguments" of the function.
- Teach the noescape diagnostics to notice if the noescape problem is due to an
@autoclosure argument that is implicitly noescape. In this case, produce a helpful note
that indicates that the invalid use of the noescape is due to the autoclosure implying it.
Swift SVN r24222
Make @autoclosure imply @__noescape as described in rdar://18447257. This is currently limited to the stdlib only right now, since @__noescape isn't a user visible feature and implying it would make it user visible.
This has no effect other than enforcing limitations on the stdlib that it doesn't currently break.
More interesting pieces coming soon.
Swift SVN r24210
Even though the tests were broken by r24141, now that there are more
commits on top of it, reverting just r24141 does not fix tests. I'm
reverting r24141, r24142 and r24143.
Swift SVN r24150
optional callback; retrofit existing implementations.
There's a lot of unpleasant traffic in raw pointers here
which I'm going to try to clean up.
Swift SVN r24123
propagate the no-escape bit from a parameter into a closure-expr argument. When a
ClosureExpr is thus inferred to be non-escape, disable the "self." requirement.
.. with fixes. Thanks again to Dmitri for reverting + adding testcase.
Swift SVN r24115
closure-expr argument. When a "
This reverts commit r24085. It causes crashes in the validation
testsuite even with r24094. Testcase:
var x = { f: Int {} }
Swift SVN r24102
The previous approach -- which attempted to put an llvm::Fixnum<52> into an
llvm::PointerUnion -- failed to compile for 32-bit platforms. This approach now
explicitly uses 62 bits of a uint64_t for storing either an ArchetypeType * or
an llvm::Fixnum<62>, using the remaining 2 bits to store what kind of value is
in storage.
This fixes <rdar://problem/19283881>.
Swift SVN r24084
