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
Previously we reported them once for their base name and once for their
full name, which is unnecessary. All clients were already de-duping, though.
Swift SVN r24051
"private" is a very overloaded term already. "Cascading" instead of
"non-private" is a bit more clear about what will happen with this sort
of lookup.
No functionality change. There are some double negatives I plan to clean
up in the next commit, but this one was supposed to be very mechanical.
Swift SVN r23969
Previously we could fail to capture dependencies on other modules. Why is
this a problem? Because a file in the main module could introduce a new
operator decl with the same name (at least in theory).
Swift SVN r23448
This is sort of two commits squashed into one: first, update
ReferencedNameTracker to record whether a name or type is non-private,
along with changing all clients to assume non-private; and second,
actually try to (conservatively) decide if a particular unqualified lookup can
be considered private.
What does "private" mean? That means that a dependency does not affect
"downstream" files. For example, if file A depends on B, and B depends on C,
then a change in C normally means A will get rebuilt. But if B's dependencies
on C are all private dependencies (e.g. lookups from within function bodies),
then A does not need to be rebuilt.
In practice there are several rules about when we can make this assumption,
and a few places where our current DeclContext model is not good enough to
distinguish private uses from non-private uses. In these cases we have to
be conservative and assume that the use is non-private (and thus that
downstream files will need to be rebuilt).
Part of rdar://problem/15353101
Swift SVN r23447
This comes through as UncheckedConforms, and we expect a null conformance, so pass it through. DaveA's incoming patches will exercise this. Fixes rdar://problem/18992875.
Swift SVN r23377
This tracks top-level qualified and unqualified lookups in the primary
source file, meaning we see all top-level names used in the file. This
is part of the intra-module dependency tracking work that can enable
incremental rebuilds.
This doesn't quite cover all of a file's dependencies. In particular, it
misses cases involving extensions defined in terms of typealiases, and
it doesn't yet track operator lookups. The whole scheme is also very
dependent on being used to track file-level dependencies; if C is a subclass
of B and B is a subclass of A, C doesn't appear to depend on A. It only
works because changing A will mark B as dirty.
Part of rdar://problem/15353101
Swift SVN r22925
This might not matter for the compiler, but both LLDB and SourceKit have to
deal with multiple ASTContexts and multiple SourceFiles all the time.
Swift SVN r22869
Updating r22145, this patch adds pointers from a TypeRefinementContext to the
AST node that introduced the context, along with the reason for refinement. This
reason supports the scenario where an AST node may introduce multiple refinement
contexts (e.g., eventually we want an IfStmt to introduce two refinement
contexts, one for the Then branch and one for the Else branch.
The patch also fixes a memory leak for the storage holding a refinement
context's children.
Swift SVN r22232
This patch adds the beginning of building the type refinement context tree for
availability checking in Sema, guarded by by the
-enable-experimental-availability-checking option. This tree parallels the AST
but is much more sparse: we introduce a new TypeRefinementContext only when
needed. Each context refines the range of potential OS versions that could be
encountered at run time. For the moment, we only refine contexts for function
bodies. I will add refinement contexts for #os(...) in a later commit.
The AST is not directly connected to the TRC tree except at the SourceFile
level; when type checking, we use source locations to look up the TRC
corresponding to an AST element. For the moment, we emit a diagnostic when the
programmer references a potentially unavailable declaration. We will later
change this to treat the declaration as if it had optional type.
Swift SVN r22145
This works using the nominal's normal lookupDirect to gather decls from the
original declaration and all its extensions, then filters them by module and
private-discriminator. This does not yet do the right thing for extensions
because we don't include the extension's module in a member's mangling except
in very specific circumstances. In order to make this work in general we'll
have to start doing this more generally.
Part of rdar://problem/17632175
Swift SVN r21785
Now that there's just one entry point for discriminated lookup, there's not
really a need for this extra abstraction.
One thing still up in the air is unqualified lookup support for discriminator
preferences (for, say, breakpoint conditions), but we'll cross that bridge
when we come to it.
Part of rdar://problem/17632175
Swift SVN r21755
Since the primary purpose here is to go from a mangled name to a decl, and
discriminators are only valid in the context of a particular module, it
makes sense to make this an API on Module. Eventually this will also support
lookup into a type or its extensions, limited by module and discriminator.
Swift SVN r21754
This behaves like @UIApplicationMain, except for AppKit. Attach it to your NSApplicationDelegate, and an artificial "main" will be generated that invokes NSApplicationMain() for you. Implements rdar://problem/16904667.
Swift SVN r21697
This is useful both for caching purposes and for comparison of discriminators
(something the debugger will need to do when looking up a particular decl).
No observable functionality change.
Swift SVN r21610
Now we can test the mangling rules set up in the previous commit: include
the discriminator for the top-most 'private' decl, but not anything nested
within it.
Part of rdar://problem/17632175
Swift SVN r21599
We currently mangle private declarations exactly like public declarations,
which means that private entities with the same name and same type will
have the same symbol even if defined in separate files.
This commit introduces a new mangling production, private-decl-name, which
includes a discriminator string to identify the file a decl came from.
Actually producing a unique string has not yet been implemented, nor
serialization, nor lookup using such a discriminator.
Part of rdar://problem/17632175.
Swift SVN r21598
... and stop doing it when we're separating the archetypes of
extensions from the types they extend. I wasn't able to isolate a
useful test case for this; it triggers when building the standard
library with extension archetypes separated.
Swift SVN r20814
Expose Substitution's archetype, replacement, and conformances only through getters so we can actually assert invariants about them. To start, require replacement types to be materializable in order to catch cases where the type-checker tries to bind type variables to lvalue or inout types, and require the conformance array to match the number of protocol conformances required by the archetype. This exposes some latent bugs in the test suite I've marked as failures for now:
- test/Constraints/overload.swift was quietly suffering from <rdar://problem/17507421>, but we didn't notice because we never tried to codegen it.
- test/SIL/Parser/array_roundtrip.swift doesn't correctly roundtrip substitutions, which I filed as <rdar://problem/17781140>.
Swift SVN r20418
This always wrapped a single GenericTypeParamDecl *, and provided no benefit
over just using the decl directly.
No (intended) functionality change.
Swift SVN r19628
No validation is done yet on whether the user-specified access control makes
sense in context, but all ValueDecls should at least /have/ accessibility now.
/Still/ no tests yet. They will be much easier to write once we're actually
enforcing access control and/or printing access control.
Swift SVN r19143
...in preparation for non-source locations, i.e. locations that don't come
frome source buffers.
No functionality change, but a fair bit of SourceManager API and idioms have
changed.
Swift SVN r18942
This is better than requiring people to go through Ctx.getModule() using
Ctx.StdlibModuleName. There aren't that many cases of this, but they
shouldn't be using a completely different API.
The default behavior remains the same: if the standard library has not been
loaded, null will be returned.
Refinement of r18796, which modified the behavior of SourceFiles to assume
that the standard library had already been loaded.
Swift SVN r18813
Previously, it had a *nearly* pre-order traversal, but included private
imports before the top-level module being searched. This was leading to
strange errors that relied on search order, like
<rdar://problem/17127940> Qualifying Swift types by their module name doesn't work
Swift SVN r18806
This doesn't really affect anyone in real life, but it will catch cases
where someone's trying to compile for iOS without the iOS stdlib around.
Swift SVN r18796
Drop a note in the source file containing the top-level code to make it easier to navigate to (and avoid hardcoding the magic "main.swift" name).
Swift SVN r18093
If a source file contains the main class for its module, then implicitly emit a top_level_code that invokes UIApplicationMain with the name of the marked class.
Swift SVN r18088
These types may not have a conformance for AnyObject explicitly declared,
but being class-bound in some other way is good enough.
<rdar://problem/16818324>
Swift SVN r17581
The use of ASTContext-allocated arrays to store the members of nominal
type declarations and the extensions thereof is an
abomination. Instead, introduce the notion of an "iterable"
declaration context, which keeps track of the declarations within that
context (stored as a singly-linked list) and allows iteration over
them. When a member is added, it will also make sure that the member
goes into the lookup table for its context immediately.
This eliminates a ton of wasted memory when we have to reallocate the
members arrays for types and extensions, and moves us toward a much
more sane model. The only functionality change here is that the Clang
importer no longer puts subscript declarations into the wrong class,
nor does it nested a C struct within another C struct.
Swift SVN r16572
NFC. DeclRange is a range over DeclIterators, and is used rather than
ArrayRef<Decl*> to retrieve the members of a nominal type declaration
or extension thereof. The intent is to change the representation of
DeclRange next.
Swift SVN r16571
