Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
Replace the loop over all known protocols with a query into the
actual conformance lookup table, which more properly deals with
out-of-order conformance queries, inheritance of protocol
conformances, and conformance queries in multi-file situtations.
The SILGen test change is because we're no longer emitting redundant
conformances, while the slight diagnostic regression in
circular-inheritance cases is because we handle circular inheritance
very poorly throughout the compiler.
While not the end, this is a major step toward finishing
rdar://problem/18448811.
Swift SVN r26299
This flag indicates that internal APIs within the module should be made
available to client code for testing purposes. Currently does nothing.
Not ready for developer consumption yet, ergo a hidden frontend-only flag.
Part of testability (rdar://problem/17732115)
Swift SVN r26292
Previously, we would require the type checker to be able to build a
conformance, which meant we would actually have to lie in the AST
about having a conformance (or crash; we did the form). Now, we can
form the conformance in the AST and it will be checked in the type
checker when needed. The intent here is to push conformance creation
into the conformance lookup table.
To get here, we had to stop relying on the broken, awful,
ASTContext-wide conformance "cache". A proper cache can come back once
the model is sorted out.
Swift SVN r26250
Instead of relying on Sema to set the existential-conforms-to-self bit, compute it lazily in the AST. This is far cleaner and more dependable than the previous solution.
Swift SVN r26225
Previously, a multi-pattern var/let decl like:
var x = 4, y = 17
would produce two pattern binding decls (one for x=4 one for y=17). This is convenient
in some ways, but is bad for source reproducibility from the ASTs (see, e.g. the improvements
in test/IDE/structure.swift and test/decl/inherit/initializer.swift).
The hardest part of this change was to get parseDeclVar to set up the AST in a way
compatible with our existing assumptions. I ended up with an approach that forms PBDs in
more erroneous cases than before. One downside of this is that we now produce a spurious
"type annotation missing in pattern"
diagnostic in some cases. I'll take care of that in a follow-on patch.
Swift SVN r26224
Resolving signatures of declarations from files other than the primary source
file causes first-pass type checking, including diagnostics for potential
unavailability, to be performed on those declarations. Prior to this commit, the
type refinement context hierarchy was only constructed for the primary file, so
spurious errors were emitted when checking declarations in other files. With
this commit, the availability checker builds the hierarchy for a source file the
first time its hierarchy is queried. We will eventually want to build the
hierarchy more lazily, but that will come later.
Swift SVN r25746
Easy cut down on exported symbols. Unless a private type is referenced in
an inlineable function, there's no way to generate a reference to it
outside of the current file, except in the debugger. (That last bit is why
we can't use fully private linkage, which would keep the symbol out of the
symbol table completely.)
We should be doing this for "internal" declarations as well, but the
standard library /does/ have references to internal types in inlineable
functions, and also has tests that directly access these types.
Swift SVN r24838
Local type declarations are saved in the source file during parsing,
now serialized as decls. Some of these may be defined in DeclContexts
which aren't Decls and previously weren't serialized. Create four new
record kinds:
* PatternBindingInitializer
* DefaultArgumentInitializer
* AbstractClosureExpr
* TopLevelCodeDecl
These new records are used to only preserve enough information for
remangling in the debugger, and parental context relationships.
Finally, provide a lookup API in the module to search by mangled name.
With the new remangling API, the debugging lifecycle for local types
should be complete.
The extra LOCAL_CONTEXT record will compressed back down in a
subsequent patch.
Swift SVN r24739
PrintAsObjC behaves slightly differently in apps vs. frameworks: for apps,
you get internal decls exposed in the header as well as public ones. This
is because the generated header is not being shipped anywhere and thus we
don't have a secrecy leak.
However, we were detecting whether we were in an app based on whether or
not we had a bridging header. That's no good for mixed-source apps where
there's no bridging header, so now we also check for a main entry point,
whether generated from @UIApplicationMain or @NSApplicationMain, or from
a script source file (main.swift).
rdar://problem/17877235
Swift SVN r24532
This isn't being used for much yet, but it will allow us to tell whether
something is an app target even at the module-merging stage, which is a
better way to tell if something is an app than whether it has a bridging
header.
We'll also need this if we ever take advantage of reusing "partial modules"
(serialized ASTs for other parts of the module that aren't affected by the
current source file) for compiling source files in incremental builds;
unfortunately that's unlikely given our dependency model.
Swift SVN r24531
Rather than keeping just a "main class" in every module, track the "main file"
that's responsible for producing the module's entry point. This covers both
main source files and files containing classes marked @UIApplicationMain or
@NSApplicationMain.
This should have no functionality change, but is preparation for the next
commit, where we will preserve some of this information in serialization.
Swift SVN r24529
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
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
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
