This is effectively fallout from 36a44cf3 where we switched representations of DeclID
and friends, but when I went to add ++ and -- to llvm::PointerEmbeddedInt I realized
it wasn't really intended to be mutated in place, i.e. it doesn't make sense to
increment a DeclID. Represent counters as plain integers instead that get converted
to DeclID when they are first used.
There's a group of methods in `DeclContext` with names that start with *is*,
such as `isClassOrClassExtensionContext()`. These names suggests a boolean
return value, while the methods actually return a type declaration. This
patch replaces the *is* prefix with *getAs* to better reflect their interface.
The two types are nearly identical, and Fixnum is only in the Swift branches of LLVM,
not in mainline LLVM.
I do want to add ++ to PointerEmbeddedInt and fix some of this ugliness, but that'll
have to go through LLVM review, so it might take a bit.
Since resilience is a property of the module being compiled,
not decls being accessed, we need to record which types are
resilient as part of the module.
Previously we would only ever look at the @_fixed_layout
attribute on a type. If the flag was not specified, Sema
would slap this attribute on every type that gets validated.
This is wasteful for non-resilient builds, because there
all types get the attribute. It was also apparently wrong,
and I don't fully understand when Sema decides to validate
which decls.
It is much cleaner conceptually to just serialize this flag
with the module, and check for its presence if the
attribute was not found on a type.
My recent changes added "resiliently-sized" global variables, where a
global in one module is defined to be of a type from another module,
and the type's size is not known at compile time.
This patch adds the other half of the equation: when accessing a
global variable defined by another module, we want to use accessors
since we want to resiliently change global variables from stored to
computed and vice versa.
The main complication here is that the synthesized accessors are not
part of any IterableDeclContext, and require some special-casing in
SILGen and Serialization. There might be simplifications possible here.
For testing and because of how the resilience code works right now,
I added the @_fixed_layout attribute to global variables. In the
future, we probably will not give users a way to promise that a
stored global variable will always remain stored; or perhaps we will
hang this off of a different attribute, once we finalize the precise
set of attributes exposed for resilience.
There's probably some other stuff with lazy and observers I need to
think about here; leaving that for later.
Introduce a new attribute, swift3_migration, that lets us describe the
transformation required to map a Swift 2.x API into its Swift 3
equivalent. The only transformation understood now is "renamed" (to
some other declaration name), but there's a message field where we can
record information about other changes. The attribute can grow
somewhat (e.g., to represent parameter reordering) as we need it.
Right now, we do nothing but store and validate this attribute.
As part of this, use a different enum for parsed generic requirements.
NFC except that I noticed that ASTWalker wasn't visiting the second
type in a conformance constraint; fixing this seems to have no effect
beyond producing better IDE annotations.
This eliminates some minor overheads, but mostly it eliminates
a lot of conceptual complexity due to the overhead basically
appearing outside of its context.
The main idea here is that we really, really want to be
able to recover the protocol requirement of a conformance
reference even if it's abstract due to the conforming type
being abstract (e.g. an archetype). I've made the conversion
from ProtocolConformance* explicit to discourage casual
contamination of the Ref with a null value.
As part of this change, always make conformance arrays in
Substitutions fully parallel to the requirements, as opposed
to occasionally being empty when the conformances are abstract.
As another part of this, I've tried to proactively fix
prospective bugs with partially-concrete conformances, which I
believe can happen with concretely-bound archetypes.
In addition to just giving us stronger invariants, this is
progress towards the removal of the archetype from Substitution.
A protocol conformance needs to know what declarations satisfy requirements;
these are called "witnesses". For a value (non-type) witness, this takes the
form of a ConcreteDeclRef, i.e. a ValueDecl plus any generic specialization.
(Think Array<Int> rather than Array<T>, but for a function.)
This information is necessary to compile the conformance, but it causes
problems when the conformance is used from other modules. In particular,
the type used in a specialization might itself be a generic type in the
form of an ArchetypeType. ArchetypeTypes can't be meaningfully used
outside their original context, however, so this is a weird thing to
have to deal with. (I'm not going to go into when a generic parameter is
represented by an ArchetypeType vs. a GenericTypeParamType, partially
because I don't think I can explain it well myself.)
The above issue becomes a problem when we go to use the conformance from
another module. If module C uses a conformance from module B that has a
generic witness from module A, it'll think that the archetypes in the
specialization for the witness belong in module B. Which is just wrong.
It turns out, however, that no code is using the full specializations for
witnesses except for when the conformance is being compiled and emitted.
So this commit sidesteps the problem by just not serializing the
specializations that go with the ConcreteDeclRef for a value witness.
This doesn't fix the underlying issue, so we should probably still see
if we can either get archetypes from other contexts out of value witness
ConcreteDeclRefs, or come up with reasonable rules for when they're okay
to use.
rdar://problem/23892955
Under -enable-infer-default-arguments, the Clang importer infers some
default arguments for imported declarations. Rather than jumping
through awful hoops to make sure that we create default argument
generators (which will likely imply eager type checking), simply
handle these cases as callee-side expansions.
This makes -enable-infer-default-arguments usable, fixing
rdar://problem/24049927.
Parameters (to methods, initializers, accessors, subscripts, etc) have always been represented
as Pattern's (of a particular sort), stemming from an early design direction that was abandoned.
Being built on top of patterns leads to patterns being overly complicated (e.g. tuple patterns
have to have varargs and default parameters) and make working on parameter lists complicated
and error prone. This might have been ok in 2015, but there is no way we can live like this in
2016.
Instead of using Patterns, carve out a new ParameterList and Parameter type to represent all the
parameter specific stuff. This simplifies many things and allows a lot of simplifications.
Unfortunately, I wasn't able to do this very incrementally, so this is a huge patch. The good
news is that it erases a ton of code, and the technical debt that went with it. Ignoring test
suite changes, we have:
77 files changed, 2359 insertions(+), 3221 deletions(-)
This patch also makes a bunch of wierd things dead, but I'll sweep those out in follow-on
patches.
Fixes <rdar://problem/22846558> No code completions in Foo( when Foo has error type
Fixes <rdar://problem/24026538> Slight regression in generated header, which I filed to go with 3a23d75.
Fixes an overloading bug involving default arguments and curried functions (see the diff to
Constraints/diagnostics.swift, which we now correctly accept).
Fixes cases where problems with parameters would get emitted multiple times, e.g. in the
test/Parse/subscripting.swift testcase.
The source range for ParamDecl now includes its type, which permutes some of the IDE / SourceModel tests
(for the better, I think).
Eliminates the bogus "type annotation missing in pattern" error message when a type isn't
specified for a parameter (see test/decl/func/functions.swift).
This now consistently parenthesizes argument lists in function types, which leads to many diffs in the
SILGen tests among others.
This does break the "sibling indentation" test in SourceKit/CodeFormat/indent-sibling.swift, and
I haven't been able to figure it out. Given that this is experimental functionality anyway,
I'm just XFAILing the test for now. i'll look at it separately from this mongo diff.
This is necessary for some other work I'm doing, which really wants
paramdecls to have reasonable declcontexts. It is also a small step
towards generic subscripts.
This commit changes the Swift mangler from a utility that writes tokens into a
stream into a name-builder that has two phases: "building a name", and "ready".
This clear separation is needed for the implementation of the compression layer.
Users of the mangler can continue to build the name using the mangleXXX methods,
but to access the results the users of the mangler need to call the finalize()
method. This method can write the result into a stream, like before, or return
an std::string.
to make sure we are not accessing the buffer before the output is ready. The Mangler is going to be buffered (for compression), and accessing the underlying buffer is a bug.
This times each phase of compilation, so you can see where time is being
spent. This doesn't cover all of compilation, but does get all the major
work being done.
Note that these times are non-overlapping, and should stay that way.
If we add more timers, they should go in a different timer group, so we
don't end up double-counting.
Based on a patch by @cwillmor---thanks, Chris!
Example output, from an -Onone build using a debug compiler:
===-------------------------------------------------------------------------===
Swift compilation
===-------------------------------------------------------------------------===
Total Execution Time: 8.7215 seconds (8.7779 wall clock)
---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---
2.6670 ( 30.8%) 0.0180 ( 25.3%) 2.6850 ( 30.8%) 2.7064 ( 30.8%) Type checking / Semantic analysis
1.9381 ( 22.4%) 0.0034 ( 4.8%) 1.9415 ( 22.3%) 1.9422 ( 22.1%) AST verification
1.0746 ( 12.4%) 0.0089 ( 12.5%) 1.0834 ( 12.4%) 1.0837 ( 12.3%) SILGen
0.8468 ( 9.8%) 0.0171 ( 24.0%) 0.8638 ( 9.9%) 0.8885 ( 10.1%) IRGen
0.6595 ( 7.6%) 0.0142 ( 20.0%) 0.6737 ( 7.7%) 0.6739 ( 7.7%) LLVM output
0.6449 ( 7.5%) 0.0019 ( 2.6%) 0.6468 ( 7.4%) 0.6469 ( 7.4%) SIL verification (pre-optimization)
0.3505 ( 4.1%) 0.0023 ( 3.2%) 0.3528 ( 4.0%) 0.3530 ( 4.0%) SIL optimization
0.2632 ( 3.0%) 0.0005 ( 0.7%) 0.2637 ( 3.0%) 0.2639 ( 3.0%) SIL verification (post-optimization)
0.0718 ( 0.8%) 0.0021 ( 3.0%) 0.0739 ( 0.8%) 0.0804 ( 0.9%) Parsing
0.0618 ( 0.7%) 0.0010 ( 1.4%) 0.0628 ( 0.7%) 0.0628 ( 0.7%) LLVM optimization
0.0484 ( 0.6%) 0.0011 ( 1.5%) 0.0495 ( 0.6%) 0.0495 ( 0.6%) Serialization (swiftmodule)
0.0240 ( 0.3%) 0.0006 ( 0.9%) 0.0246 ( 0.3%) 0.0267 ( 0.3%) Serialization (swiftdoc)
0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0000 ( 0.0%) Name binding
8.6505 (100.0%) 0.0710 (100.0%) 8.7215 (100.0%) 8.7779 (100.0%) Total
Modeling nonescaping captures as @inout parameters is wrong, because captures are allowed to share state, unlike 'inout' parameters, which are allowed to assume to some degree that there are no aliases during the parameter's scope. To model this, introduce a new @inout_aliasable parameter convention to indicate an indirect parameter that can be written to, not only by the current function, but by well-typed, well-synchronized aliasing accesses too. (This is unrelated to our discussions of adding a "type-unsafe-aliasable" annotation to pointer_to_address to allow for safe pointer punning.)
This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
This makes Swift (a) more likely to prefer frameworks over bare headers,
reducing potential issues with non-modular headers, and (b) more likely
to fail in the same way as LLDB if the -Xcc options also contain or affect
search paths.
rdar://problem/22413525
Swift SVN r31950
The conformance lookup table is responsible for answering queries
about the protocols to which a particular nominal type conforms, so
stop storing (redundant and incorrect) protocol lists on the ASTs for
nominal types. Protocol types still store the list of protocols that
they inherit, however.
As a drive-by, stop lying about the number of bits that ProtocolDecl
uses on top of NominalTypeDecl, and move the overflow bits down into
ProtocolDecl itself so we don't bloat Decl unnecessarily.
Swift SVN r31381
These never appear in Swift code, but they can appear when serializing the
full output of SILGen ("SIB" format) because that includes code synthesized
for imported Clang declarations.
rdar://problem/22098491
Swift SVN r31364
This provides better AST fidelity through module files and further
reduces our dependencies on storing a list of protocols on nominal
type declarations.
Swift SVN r31345
This improves the fidelity of the AST printed from a loaded module, as
well as consistency in the AST. Also teach the Clang importer to add
"inherited" clauses, providing better fidelity for the mapping from
Objective-C to Swift.
With trivial update to SDKAnalyzer test.
Swift SVN r31344
This improves the fidelity of the AST printed from a loaded module, as
well as consistency in the AST. Also teach the Clang importer to add
"inherited" clauses, providing better fidelity for the mapping from
Objective-C to Swift.
Swift SVN r31337
