A variety of enhancements from SE-154 and SE-165:
- Custom Keys and Values collections for Dictionary
- Two sequence-based Dictionary initializers
- Merging methods for Dictionary
- Capacity checking and reserving for Dictionary and Set
- Type-specific filter(_:) methods for Dictionary and Set
- A mapValues(_:) method for Dictionary
- A grouping Dictionary initializer
* swift-api-digester: ensure constructors are detected as removed if not moved. rdar://31694119
* swift-api-digester: types with the same printed name are considered behavior-preserving. rdar://31694085
* [test] Using tmp directory from build.
This structure serves multiple purposes:
a. Allow migrator to speak in the same language with swift-api-digester in terms of API changes.
b. Serialize/Deserialize detected API change items in JSON format.
c. Manage memory after deserializing API change items.
d. Facilitate look up by USRs of APIs under migration.
The structure is tested by round-trip serialization and deserialization.
* swift-api-digester: Add a test for generating migrator script.
* swift-api-digester: Add #ifndef guard before each macro category.
* swift-api-digester: Avoid printing macro categories with empty content.
* swift-api-digester: Add test for multiple type changes in a single decl.
* swift-api-digester: simplify some code. NFC
LLVM's lit implementation switched to use process pools in r299775.
This exposed some pickling problems in Swift's lit files. For a function
or class to be pickle-able, it has to be in the top-level of a real
Python module.
* The SwiftTest lit format class was embedded in the lit.cfg file, so
I moved it out to a separate Python file.
* The inferSwiftBinary function was being stashed in the
config.inferSwiftBinary field and later used to find tools for SourceKit
testing. I moved the config settings for those tools into the top-level
lit.cfg file. I expect this will cause warnings about them not existing
in some cases, but that should be fairly harmless. Maybe someone can
come up with a better solution later.
* The config.substitutions for SourceKit's lit.local.cfg was storing a
reference to an embedded sed_clean function, which just returned a
constant string. I changed the function to be a string, using Python's
raw string feature to avoid the problems that likely led to it being a
function in the first place. (Just guessing.)
Remove 16 concrete init(stringInterpolationSegment:) overloads and
replace them with 3 generic overloads, significantly reducing the
exponential blow-up from larger string interpolations.
Fixes rdar://problem/29389887.
Remove 16 concrete init(stringInterpolationSegment:) overloads and
replace them with 3 generic overloads, significantly reducing the
exponential blow-up from larger string interpolations.
Fixes rdar://problem/29389887.
This patch contains several intertwined changes:
- Remove some unnecessary complexity and duplication.
- Adds a new TypeChecker::lookupUnqualifiedType() which bypasses most of
the logic in TypeChecker::lookupUnqualified(), such as the
LookupResultBuilder. Use this when resolving unqualified references
to types.
- Fixes for generic typealiases to better preserve the type parameters of
the parent type, and clean up the logic for applying the inner generic
arguments. Some uses of generic typealiases that used to crash now work,
and those tests have been uncommented.
- Avoid an unnecessary desugaring of TypeAliasDecls which map directly
to GenericTypeParamTypes. Once again this perturbs the source-stability
test.
- When looking up a nested type of a base class with a derived class base,
always use the base class as the parent of the nested type. This fixes
a recent regression where in some cases we were using the wrong parent.
Fixes <rdar://problem/29782186>.
- TypeAliasDecl::getAliasType() is gone. Now, getDeclaredInterfaceType()
always returns the NameAliasType.
- NameAliasTypes now always desugar to the underlying type as an
interface type.
- The NameAliasType of a generic type alias no longer desugars to an
UnboundGenericType; call TypeAliasDecl::getUnboundGenericType() if you
want that.
- The "lazy mapTypeOutOfContext()" hack for deserialized TypeAliasDecls
is gone.
- The process of constructing a synthesized TypeAliasDecl is much simpler
now; instead of calling computeType(), setInterfaceType() and then
setting the recursive properties in the right order, just call
setUnderlyingType(), passing it either an interface type or a
contextual type.
In particular, many places weren't setting the recursive properties,
such as the ClangImporter and deserialization. This meant that queries
such as hasArchetype() or hasTypeParameter() would return incorrect
results on NameAliasTypes, which caused various subtle problems.
- Finally, add some more tests for generic typealiases, most of which
fail because they're still pretty broken.
In Jenkins bot, we've seen "exception std::length_error: vector" for
api-digester tests. Tentatively, this patch initializes a major vector with a
reasonably large size, which may avoid its wild capacity growth.
First, ensure all ParamDecls that are synthesized from scratch are given
both a contextual type and an interface type.
For ParamDecls written in source, add a new recordParamType() method to
GenericTypeResolver. This calls setType() or setInterfaceType() as
appropriate.
Interestingly enough a handful of diagnostics in the test suite have
improved. I'm not sure why, but I'll take it.
The ParamDecl::createUnboundSelf() method is now only used in the parser,
and no longer sets the type of the self parameter to the unbound generic
type. This was wrong anyway, since the type was always being overwritten.
This allows us to remove DeclContext::getSelfTypeOfContext().
Also, ensure that FuncDecl::getBodyResultTypeLoc() always has an interface
type for synthesized declarations, eliminating a mapTypeOutOfContext()
call when computing the function interface type in configureInterfaceType().
Finally, clean up the logic for resolving the DynamicSelfType. We now
get the interface or contextual type of 'Self' via the resolver, instead
of always getting the contextual type and patching it up inside
configureInterfaceType().
The swift-api-digester doesn't know about generic typealiases (yet?).
So it picks up some changes that are not actually source-breaking from
the previous patch.
