These won't have bodies in generated interfaces,
and generally aren't useful things to jump to. The
property ought to be used instead.
rdar://130775560
Apart from mildly speeding up indexing, this also keeps the compiler
from running into issues with implementation-only imports that may not
be present while we're trying to index.
rdar://problem/52083709
This has been an unnecessary code path for a long time now and should be removed particularly because it triggers wasteful `stat` calls.
rdar://51523161
Previously 'isSystemModule()' returns true only if the module is:
- Standard library
- Clang module and that is `IsSystem`
- Swift overlay for clang `IsSystem` module
Now:
- Clang module and that is `IsSystem`; or
- Swift overlay for clang `IsSystem` module
- Swift module found in either of these directories:
- Runtime library directoris (including stdlib)
- Frameworks in `-Fsystem` directories
- Frameworks in `$SDKROOT/System/Library/Frameworks/` (Darwin)
- Frameworks in `$SDKROOT/Library/Frameworks/` (Darwin)
rdar://problem/50516314
We previously shied away from this in order to not /accidentally/
depend on it, but it becomes interesting again with textual
interfaces, which can certainly be read by humans. The cross-file
order is the order of input files, which is at least controllable by
users.
This can't arise from a clean build, but it can happen if you have
products lingering in a search path and then either rebuild one of
the modules in the cycle, or change the search paths.
The way this is implemented is for each module to track whether its
imports have all been resolved. If, when loading a module, one of its
dependencies hasn't resolved all of its imports yet, then we know
there's a cycle.
This doesn't produce the best diagnostics, but it's hard to get into
this state in the first place, so that's probably okay.
https://bugs.swift.org/browse/SR-7483
I noticed in a follow-up patch that if you just swiftc without passing Onone
these flags are not set and sometimes happen to default to right thing ... or
not; as can be seen by the test cases modified. For example, at Onone we are
supposed to include an extra swift module "SwiftOnoneSupport".
- Report accessor function definitions for stored properties as well
- Fix issue where a call to a computed accessor was not reported if its parent was a statement
- Take into account if the stored property is member or not to adjust the symbol kind for the accessor
Two problems:
1) We were tearing down the type checker too early, before all
relevant decls in other files had been type checked, so there
was no LazyResolver available for use in the ASTContext.
This might explain the crashes coming through
diagnoseUnintendedObjCMethodOverrides().
2) When a lazy resolver was set in the ASTContext, we were not
using it in the case where nullptr was passed in as the
'resolver' parameter to inheritsSuperclassInitializers().
This might fix the crashes where we were coming in from other
code paths, but I'm less confident about this case.
Possibly fixes <rdar://problem/29043074>, <rdar://problem/30976765>,
<rdar://problem/31122590>, and <rdar://problem/31286627>, and the
many other similar-looking dupes.
We were implicitly assuming that a function reference could only happen
in an expression, ignoring the case of
import func Module.fooFunc
For now, this doesn't actually add the reference to the index because
initCallRefIndexSymbol doesn't allow references without a parent
expression. We can look at adding the reference, or maybe doing
something special to the import itself separately.
rdar://problem/26496135
The code goes into its own sub-tree under 'tools' but tests go under 'test',
so that running 'check-swift' will also run all the SourceKit tests.
SourceKit is disabled on non-darwin platforms.
