Except GenericEnvironment.h, because you can't meaningfully use a
GenericEnvironment without its signature. Lots less depends on
GenericSignature.h now. NFC
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
Rename AccessibilityAttr to AccessControlAttr and
SetterAccessibilityAttr to SetterAccessAttr, then track down the last
few uses of "accessibility" that don't have to do with
NSAccessibility. (I left the SourceKit XPC API alone because that's
supposed to be more stable.)
The small-but-significant change to the generic signature builder is
to refuse to create unresolved potential archetypes. Instead, delay
any requirement that depends on such type, to be reprocessed once
we've seen all of the other requirements. If the type can be resolved
later, it will be; Otherwise, the type checker will complain when it
sees an unresolvable type. By itself, this fixes the crash in SR-2796.
Doing this by itself regresses diagnostics because typo correction in
the generic signature builder no longer kicks in. Therefore, implement
typo correction for these cases in the type checker proper, using its
existing facilities for typo correction. The result is more consistent
code with a better result.
Fixes SR-2796 / rdar://problem/28544316.
The typedef `swift::Module` was a temporary solution that allowed
`swift::Module` to be renamed to `swift::ModuleDecl` without requiring
every single callsite to be modified.
Modify all the callsites, and get rid of the typedef.
...and use it when top-level type lookup fails, to produce better
diagnostics.
Really this should be using an option set, or setting flags on the
UnqualifiedLookup instance or something, but I want to cherry-pick
this to the swift-3.0-branch without major disturbances.
More rdar://problem/27663403
This removes the logic which issued warnings when accessing enum
elements as instance members (SE-0036), making room for a new
implementation that will issue errors instead.
This reverts commit ae1058a39a.
With the previous resolveTypeInContext() patch, a few compiler
crashers regressed with this problem, presumably because we were now
performing lookups in more contexts than before.
This is a class of problems where we would attempt a recursive
validation:
1) Generic signature validation begins for type T
2) Name lookup in type context finds a non-type declaration D nested in T
3) Generic signature validation begins for D
4) The outer generic context of D is T, but T doesn't have a generic
signature yet
The right way to break such cycles is to implement the iterative
decl checker design. However when the recursion is via name lookup,
we can try to avoid the problem in the first place by not validating
non-type declarations if the client requested a type-only lookup.
Note that there is a small semantic change here, where programs that
were previously rejected as invalid because of name clashes are
now valid. It is arguable if we want to allow stuff like this or not:
class A {
func A(a: A) {}
}
or
class Case {}
enum Foo {
case Case(Case)
}
However at the very least, the new behavior is better because it
gives us an opportunity to add a diagnostic in the right place
later. The old diagnostics were not very good, for example the
second example just yields "use of undeclared type 'Case'".
In other examples, the undeclared type diagnostic would come up
multiple times, or we would generate a cryptic "type 'A' used within
its own definition".
As far as I understand, this should not change behavior of any existing
valid code.
Implement basic code completion support for #selector with property
getters/setters. The vast majority of this implementation comes from
Alex Hoppen (@ahoppen), with only a handful of my own tweaks. Alex has
more interesting ideas on improving this that I wasn't quite ready to
commit to, so this is more basic than the overall goal.
They had already diverged even before my last commit. Let's not have that
happen again!
This re-fixes code completion for bindings declared in top-level guard
statements.
More rdar://problem/21928533
Swift SVN r30525
For now, just update NameLookup's FindLocalVal to use a
VisibleDeclConsumer just like lookupVisibleDecl().
A subsequent patch will continue removing duplicated code
now that this is place.
This fixes compiler crashers where we were not handling
declarations with duplicate names (which of course is an
error, diagnosed elsewhere).
Swift SVN r29913
Fold the witness-mapping code and deduplication logic into the main
lookup path, so we don't end up performing redundant lookups. Delay
the removal of overridden and shadowed declarations until after we've
done witness mapping, so we're not wasting effort the first time
around. NFC except for a small performance optimization.
Swift SVN r29060
Members of protocols found via unqualified name lookup are mapped to
their corresponding witnesses, as we do for qualified name
lookup. This is the bulk of the compiler changes for
rdar://problem/20509152. Performing this mapping for unqualified name
lookup of types will follow.
Swift SVN r28333
We're still doing too much work to form these unqualified lookup
results that should really move into semantic analysis, but this is
the NFC part we need now.
Swift SVN r28331
Make unqualified lookup always provide a declaration for the things it
finds, rather than providing either a module or a declaration. Unify
various code paths in our type checker now that module declarations
come in with the other declarations.
Swift SVN r28286
...and thus does not affect downstream files...
...and adopt it in several places:
- when looking up the default type for a literal (test included)
- when looking up the first component in an IdentTypeRepr (test included)
- when deciding which ~= to use in a switch (test forthcoming)
- when a protocol has an operator function requirement (test forthcoming)
- when validating @NSApplicationMain and @UIApplicationMain
- when an enum element shows up unqualified in a switch
- several places where it doesn't matter because we're looking something up
in the standard library.
Part of rdar://problem/15353101
Swift SVN r23670
This API didn't take accessibility into account in a useful way, and
usually did a more general search than what was actually needed. We've
gradually been replacing uses of it with either more safe or more direct
APIs, including a regular UnqualifiedLookup, DeclContext::lookupQualified,
or Module::lookupValue. Now it's gone.
No functionality change.
Swift SVN r23449
llvm::Optional lives in "llvm/ADT/Optional.h". Like Clang, we can get
Optional in the 'swift' namespace by including "swift/Basic/LLVM.h".
We're now fully switched over to llvm::Optional!
Swift SVN r22477
This applies to both qualified and unqualified lookups, and is controlled
by the -enable-access-control and -disable-access-control flags. I've
included both so that -disable-access-control can be put into specific tests
that will eventually need to bypass access control (e.g. stdlib unit tests).
The default is still -disable-access-control.
Swift SVN r19146
conformances
rdar://16539292
This is a hack in visible decl lookup. The general solution that would also
improve type checker errors would be to make the type checker keep these broken
conformances and syntethize missing declarations to make downstream code type
check. For that, see:
<rdar://problem/16723339> [QoI] Type checker should not be dropping protocol
conformances explicitly spelled in the source
Swift SVN r16818
Make the name lookup interfaces all take DeclNames instead of identifiers, and update the lookup caches of the various file units to index their members by both compound name and simple name. Serialized modules are keyed by identifiers, so as a transitional hack, do simple name lookup then filter the results by compound name.
Swift SVN r14768
This started out life as a helper class, but it's been used in multiple places.
Better to just have a single copy.
No functionality change.
Swift SVN r10835
I tried hard find all references to 'func' in documentation, comments and
diagnostics, but I am sure that I missed a few. If you find something, please
let me know.
rdar://15346654
Swift SVN r9886
And, properly treat imports as per-file: when looking up decls through the
TU module, don't pick up every other source file's imports.
This implements our resolution rules:
1. Check the current source file.
2. Check the current module.
3. Check imported modules.
Currently, "import Foo" is treated as a file-private import and
"@reexported import Foo" is treated as a public /and/ module-wide import.
This further suggests that access control is the right tool for re-export
control:
(private) import Foo // current file only
package import Foo // whole module
public import Foo // whole world
Swift SVN r9682
ASTContexts
This introduces swift::ide::CodeCompletionCache, which is a persistent code
completion result cache.
Right now REPL happens to use it (try importing Cocoa and doing code
completion), and the difference is noticeable. But completion in REPL is
still slow, because Cocoa goes through the AST Verifier on every completion
(for unknown reasons).
This commit does not implement cache invalidation yet, and it does not use
libcache to evict cache entries under memory pressure.
This commit also introduces two regressions:
- We get fewer Cocoa results that expected. Module::isModuleVisible in Clang
does not incorrectly reports that that ObjectiveC.NSObject submodule is not
visible from Cocoa.
- We are not implementing the decl hiding rules correctly. We used to rely on
visible decl lookup to do it for us, but now we have a different data structure
we have real decls from the current module and we have a text-only cache, so we
are forced to reimplement this part of name lookup in code completion.
Swift SVN r9633
Semantic context describes the origin of the declaration and serves the same
purpose as opaque numeric "priority" in Clang -- to determine the most likely
completion.
This is the initial implementation. There are a few opportunities to bump the
priority of a certain decl by giving it SemanticContextKind::ExprSpecific
context that are not implemented yet.
Swift SVN r9052
Instead, pass a LazyResolver down through name lookup, and type-check
things on demand. Most of the churn here is simply passing that extra
LazyResolver parameter through.
This doesn't actually work yet; the later commits will fix this.
Swift SVN r8643
There were two overloads of lookupVisibleDecls: one that performed
unqualified lookup from a particular decl context, the other performing
qualified lookup into a given type from a particular decl context.
They don't really behave the same, so let's give them different names.
Swift SVN r8641
Previously, TypeAliasDecl was used for typealiases, generic
parameters, and assocaited types, which is hideous and the source of
much confusion. Factor the latter two out into their own decl nodes,
with a common abstract base for "type parameters", and push these
nodes throughout the frontend.
No real functionality change, but this is a step toward uniquing
polymorphic types, among other things.
Swift SVN r7345
