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.
The index may be at the end of the ArrayRef of chunks if the completion
ends with a simple parameter with no type annotation. Check that the
index is in-bounds before adding text.
rdar://problem/26273906
Surface these results in the codecomplete code path (they're already
there in the codecomplete.open code path) so we can use them from IDEs.
For now, just use ad-hoc filtering to show them when the type matches
(or there is no expected type). Ideally we would make this filtering
configurable like we do in the codecomplete.open code path.
rdar://problem/25836544
... and don't try to filter the extended results. Once the results are
extended with the common prefix they will not match identifier filter
rules, which will create differences between completions depending on
whether they had a filter text or were a postfix expression. Also,
allow filtering by name directly on the inner operator name for inner
operators.
rdar://problem/26312235
We want inputs for function names to follow SE-0021 with the exception
that a function with no arguments is spelled `foo()` instead of `foo`,
because we have no type to disambiguate with and it's not ambiguous with
a call in this context.
Internally, we use a filter name without underscores because we don't
want to introduce spurious matches to the `_` character which might be
part of identifiers.
For now, continue to accept the old names to ease the transition.
rdar://problem/24350800
In the new code-completion code path, force any known operators to go
through a fixed sort order. To identify operators unambiguously, add a
new BuiltinOperator code-completion kind to handle non-decl operators
(!, ., ?., and =).
rdar://problem/25994246
rdar://problem/23440367
This sort is only for codeComplete, not for codeCompleteOpen, but we
were doing it indiscrimiately leading to ~15% performance penalty in the
latter code path.
rdar://problem/25887631
As implied in rdar://24818863, striking through a module name may be an overkill to suggest the module is redundant to import. We try to
fine-grain not-recommended-reason so that proper UI cue can be adopted in the future.
When the LHS is an lvalue/assignable tuple and there is no leading
sequence of binary expressions.
It's a bit hacky right now since we don't have a good way to
differentiate general pattern completions from builtin operators.
rdar://problem/23209683
In the experimental operator completion, we were mysteriously missing
some operators like ||. It turns out it was all operators
alphabetically after '.', because the filtering code was very broken.
rdar://problem/23539465
Experiment with having some locals or nominal members come first, but
only a few so that the literals are still predictably near the top.
Part of rdar://problem/23865118
If there is a type context, hide literal suggesetions that don't match
it, unless they are keywords and we have filtered to their names.
Incidentally fix an output buffering issue when combining filtering with
the -raw flag in complete-test.
Part of rdar://problem/23865118
On a per-request basis. Allows hiding/showing at multiple granularities
* everything
* module
* API by name
* keywords (by uid or all of them)
* literals (by uid or all of them)
With more specific rules overriding less specific ones (so you can hide
everything and then selectively show certain API for example).
rdar://24170060
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.
