codeCompleteOpen() has own sorting algorithm, codeComplete() calls this
sortCompletionResults() in its callback. So this pre-sorting is
completely unnecessary.
SwiftSourceInfo files provide source location information for decls coming from
loaded modules. For most IDE use cases it either has an undesirable impact on
performance with no benefit (code completion), results in stale locations being
used instead of more up-to-date indexer locations (cursor info), or has no
observable effect (live diagnostics, which are filtered to just those with a
location in the primary file).
For non-IDE clients of SourceKit though, cursor info providing declaration
locations for symbols from other modules is useful, so add a global
configuration option (and a new request to set it) to control whether
.swiftsourceinfo files are loaded or not based on use case (they are loaded by
default).
Get source locations from '.swiftsourceinfo' is currently expensive.
Since they are not necessary for code completion, set
'IgnoreSwiftSourceInfo' to 'true'.
rdar://problem/57194358
https://bugs.swift.org/browse/SR-11767
- Use `performParseAndResolveImportsOnly()` to invoke the frontend
- Do `bindExtensions()` in `ide::typeCheckContextUntil()`
- Typecheck preceding `TopLevelCodeDecl`s only if the compleiton is in
a `TopLevelCodeDecl`
- Other related tweaks
rdar://problem/56636747
The clang importer has to deal with two virtual file systems, one coming
from clang, and one coming from swift. Currently, if both are set, we
emit a diagnostic that we'll pick the swift one.
This commit changes that, by merging the two virtual file systems. The
motivation for this change is the reproducer infrastructure in LLDB,
which adds a third virtual file system to the mix.
(cherry picked from commit 94ef5431ff)
IDE functionality needs some internal type checking logics, e.g. checking
whether an extension is applicable to a concrete type. We used to directly
expose an header from sema called IDETypeChecking.h so that IDE functionalities
could invoke these APIs. The goal of the commit and following commits is to
expose evaluator requests instead of directly exposing function entry points from
sema so that we could later move IDETypeChecking.h to libIDE and implement these functions
by internally evaluating these requests.
The invocation options are not an appropriate place to put this state,
since it can change between requests. This moves it to the editor
document, allowing us to change the specific VFS instance without
causing a rebuild (unless the contents/timestamps for a dependency
change).
Extend the support for single-expression closures to handle
single-expression functions of all kinds. This allows, e.g.
func foo() -> MyEnum { .<here> }
to complete members of `MyEnum`.
Addressing review feedback: this avoids calling shared_from_this() from
outside the implementation. Note: it is not possible to use private
inheritance of enable_shared_from_this to prevent this issue in general,
because enabled_shared_from_this relies on the shared_ptr constructor
being able to detect that the type has this inheritance, which means it
must be public.
Refactors the diagnostic code to be run whenever a compilation
notification has been started and there are diagnostics available in the
consumer. This allows us to capture diagnostics on all exit paths, and
specifically when code-completion fails because of invalid arguments.
Note: the editor.open code path still doesn't report invalid arguments
because it fails before even trying to create an AST.
This code was an experiment in how to collect information after a crash,
that did not end up being used. It's unclear how much it has bitrotted
at this point, since it has no tests and was not designed with automated
testing in mind. Parts of it interfere with some changes I want to make
to the underlying tracing mechanism, so I am finally removing it. This
also lets us remove the buffer copying in the parts of tracing used by
the compile notifications, improving performance.
For rdar://39538847
The only interesting change here is that I stopped filtering out
non-note diagnostics from outside the "inputs". This matches better how
code-completion gets inputs, and shouldn't hurt anything else since only
the tracing code will look at diagnostics that aren't in specific
buffers anyway.
rdar://38438512
When enabled, send a notification before/after every "compilation",
which for now means `performSema`. This piggy-backs and modifies some
existing code that we had for "tracing" operations in sourcekitd that
unfortunately was untested. At least now some of the basic parts are
tested via the new notifications.
Part of rdar://38438512
This is how it was used in all but one place anyway, and makes it easier
to understand. It also aligns better with some further refactoring I
want to do...
Stop parsing frontend arguments directly and use the driver instead. The
most intersting part of this change is that it forces us to consider
whether our compiler invocation will have inputs or not. We have
several kinds of requests that need to create a compiler instance, but
not parse any inputs (interface-generation, doc-info, and indexing when
operating on a module instead of source files).
Incidentally, add an error when trying to do doc-info on multiple source
files. This was already very broken (assertion failures and bogus source
locations), so add an error for it.
rdar://problem/17897287
After my PR 13591 to adjust for LLVM r321257, the Linux bots are failing with
errors about missing conversions. For some reason that I don't understand,
those errors do not reproduce when I build locally on macOS. I think this
change should fix them. I also cleaned up some const_casts that should now
be unnecessary when using WritableMemoryBuffer.
When completing
Foo(<here>
We will now provide
bar: <#value#>
instead of
bar: <#value#>)
Inserting the rparen caused some problems in practice:
* the old behaviour optimized for typing Foo(<complete> instead of
Foo(<complete>), which can conflict with user behaviours or ...
* in editors with automatic brace-matching, we often conflicted with the
editor, leading to extraneous closing parens
And in general, it is much more predictable for tooling to either insert
matching ( and ) or to not insert either. While this change may not be
ideal For users of editors that do not do automatic brace-matching, I
believe it is still better overall to have to type a missing paren than
to have to delete an extraneous one.
rdar://31113161
The original hope was we could make these heuristics really good, but
since that is not currently in sight (and may never be), we want to be
able to turn them off. For now, just plumb through an internal flag to
control the behaviour. A future change will customize the behaviour in
SourceKit.
rdar://31113161
- Outlaw duplicate input files, fix driver, fix tests, and add test.
- Reflect that no buffer is present without a (possibly pseudo) named file.
- Reflect fact that every input has a (possible pseudo) name.
- Break up CompilerInstance::setup.
Don't bail on dups.
Change “have” routines to “has”.
Use more consistent casing.
Remove spurious “DelayedFunctionParsing” option.
Move debugFail routines to top lexical level.
Rename and reorder declaration of functions in FrontendArgsToOptionsConverter.
Move, reword, and doxygenate comments for some of those functions.
Fix casing on some more setUp* functions.
Return NoneAction instead of existing RequestedAction in FrontendArgsToOptionsConverter::determineRequestedAction.
Remove test names and put in FIXME’s.
Remove “Jordan” from comments & reword.
Reorder if-then arms of FrontendArgsToOptionsConverter::computeOutputFilenames for readability.
Test for empty string instead of equality with “”.
Use hasUnusedModuleDocOutputPath.
Remove optionality from return type of getOutputFilenamesFromCommandLineOrFilelist.
Rename isPrimaryInputAFileAt to isThereAPrimaryInputWithAFilenameAt.
Added a FIXME in doesActionProduceOutput to reflect that some actions actually do not produce output.
Change “have” routines to “has”.
Use more consistent casing.
Remove spurious “DelayedFunctionParsing” option.
Move debugFail routines to top lexical level.
Rename and reorder declaration of functions in FrontendArgsToOptionsConverter.
Move, reword, and doxygenate comments for some of those functions.
Fix casing on some more setUp* functions.
Return NoneAction instead of existing RequestedAction in FrontendArgsToOptionsConverter::determineRequestedAction.
Remove test names and put in FIXME’s.
Remove “Jordan” from comments & reword.
Reorder if-then arms of FrontendArgsToOptionsConverter::computeOutputFilenames for readability.
Test for empty string instead of equality with “”.
Use hasUnusedModuleDocOutputPath.
Remove optionality from return type of getOutputFilenamesFromCommandLineOrFilelist.
Rename isPrimaryInputAFileAt to isThereAPrimaryInputWithAFilenameAt.
Added a FIXME in doesActionProduceOutput to reflect that some actions actually do not produce output.
Encapsulate uses of the variables in FrontendInputs with intention-describing functions. Move some code that sets these variables into FrontendInputs and FrontendOptions classes.
Create new FrontendInputs class to encapsulate InputFilenames, InputBuffers and PrimaryInput, which were formerly in Frontend.
Includes one change in SwiftEditor.cpp to resolve a merge conflict.
With broken code you can end up with non-postfix completions when
searching for inner operators, which you never want because you end up
creating compound results like "fooUIColor".
rdar://problem/34145229
When using completion options that will allow the lone "." completion,
provide that result when in contexts that expect an enum type. Note:
this is a crappy approximationg for whether the type can have "implicit
member expression" syntax, since uninhabited enums should not support
it, and many non-enum types should. However, it is currently expensive
to compute the accurate answer and this approximation is good enough for
some clients.
rdar://problem/31260505
The filter name isn't helpful if you want to make rules about specific
overloads - e.g. only show the [Int] subscript on Array.
rdar://problem/28920034
* [Parse] Refactored internal structure of Tokens.def and documented usage.
Added a level of structure to the macro definitions to allow Swift
keywords to be cleanly accessed separately from SIL and Swift keywords
together. Documented structure and usage.
* [Parse] Made use of new guarantees and abstractions in Tokens.def
Used guarantees about undefining macros after import and new
SWIFT_KEYWORD abstraction to simplify usage of the Token.def
imports.
* Gardening
1. Make sure the actions taken by fixits are reflected in diagnostics messages.
2. Issue missing cases diagnostics at the start of the switch statement instead of its end.
3. Use <#code#> instead of <#Code#> in the stub.
Add an option to the lexer to go back and get a list of "full"
tokens, which include their leading and trailing trivia, which
we can index into from SourceLocs in the current AST.
This starts the Syntax sublibrary, which will support structured
editing APIs. Some skeleton support and basic implementations are
in place for types and generics in the grammar. Yes, it's slightly
redundant with what we have right now. lib/AST conflates syntax
and semantics in the same place(s); this is a first step in changing
that to separate the two concepts for clarity and also to get closer
to incremental parsing and type-checking. The goal is to eventually
extract all of the syntactic information from lib/AST and change that
to be more of a semantic/symbolic model.
Stub out a Semantics manager. This ought to eventually be used as a hub
for encapsulating lazily computed semantic information for syntax nodes.
For the time being, it can serve as a temporary place for mapping from
Syntax nodes to semantically full lib/AST nodes.
This is still in a molten state - don't get too close, wear appropriate
proximity suits, etc.
