Missing autocompletions across the language

Since key-paths were released I always wondered why there is no autocompletion for that feature?! Is this a pure tooling limitation or are there some parts missing from compiler/language?

1 Like

There is auto completion for key paths, apparently this is an Xcode-side issue or intended limitation. Similarly, we don't get completions like .member (we have to type a dot to get them).
Or I might be wrong about the former and you've just encountered a bug. Have you tried out general cases?

Well I'm not sure in which case you meant about the .member (something like .red for UIColor works just fine because there is some anchor type to infer from).

Here is a quick example:

import UIKit

let color: UIColor = .red // The `.` + `esc key` presents possible autocompletion

struct Test {
  var foo = "swift"
  func method<T>(path: KeyPath<Test, T>) {}

// The start is there but the compiler seems not be able to infer the rest
Test().method(path: \./* this one has no autocompletion */)

On the topic of missing autocompletes:

When defining a precedencegroup, the labels (keywords?) higherThan, lowerThan, associativity, and assignment, do not participate in autocomplete (at least in Xcode 9.4.1).

Furthermore, autocomplete does not work for precedence group names themselves (eg. AdditionPrecedence). Both when defining an operator to have a certain precedence, and when specifying higherThan / lowerThan for a new precedence group, I get no autocompletion.


Do you really get completions simply after typing a space after =?

@Nevin Thanks, I'll have a look if this is a bug. Not good, it isn't your everyday syntax not to have completions.

No but after typing a dot (if Xcode fails then there is the ESC key to help), which would be analogously to \. for key-paths.

Edit: I re-read your first reply, not sure if you edited it or not, but I thoutht you wrote that we had to type the type to get the autocompletion not like it‘s written now referring to a dot. That‘s what confused me above.

If you have already typed a dot, it's a dot expression that gives completions without leading dots. That said, we do give completions for postfix expressions (where a leading dot is added i.e. Foo#^.foo()^#), but Xcode doesn't show them. Probably because it's an overkill.
I am pretty sure we do have completions for key paths. Let me have a look, if I'm wrong, we can file a bug.

@DevAndArtist Ok, yes, it's a bug. Querying completions for \. crashes. Will you do the honours of filing it? :slight_smile:

1 Like

@Nevin Please file a bug for precedencegroup related completions when there is time, I'll make them work.

How do you know that the compiler crashed or the responsible tooling system? Is it Swift or Xcode related crash? The example I posted did not crash, it just didn‘t worked at all.

I ran the tool manually. It is a Swift related crash, but it's the completion tool using a separate compiler invocation that crashes, so the compiler doesn't suffer. Here's the trace

stack trace
found code completion token SELF at offset 196
found code completion token SELF at offset 196
found KeyPathDotExpr in CSGen
UNREACHABLE executed at /Volumes/Elements/swift-source/swift/lib/Sema/CSGen.cpp:2998!
0  swift-ide-test           0x000000010c96c878 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1  swift-ide-test           0x000000010c96bae7 llvm::sys::RunSignalHandlers() + 39
2  swift-ide-test           0x000000010c96ce82 SignalHandler(int) + 258
3  libsystem_platform.dylib 0x00007fff6deedf5a _sigtramp + 26
4  libsystem_platform.dylib 000000000000000000 _sigtramp + 2450596032
5  libsystem_c.dylib        0x00007fff6dc8b1ae abort + 127
6  swift-ide-test           0x000000010c90d730 LLVMInstallFatalErrorHandler + 0
7  swift-ide-test           0x000000010914b42e (anonymous namespace)::ConstraintGenerator::visitKeyPathDotExpr(swift::KeyPathDotExpr*) + 46
8  swift-ide-test           0x0000000109126c6a swift::ASTVisitor<(anonymous namespace)::ConstraintGenerator, swift::Type, void, void, void, void, void>::visit(swift::Expr*) + 2794
9  swift-ide-test           0x0000000109132f53 (anonymous namespace)::ConstraintWalker::walkToExprPost(swift::Expr*) + 1363
10 swift-ide-test           0x0000000109a6ec26 (anonymous namespace)::Traversal::doIt(swift::Expr*) + 134
11 swift-ide-test           0x0000000109a6eb60 swift::Expr::walk(swift::ASTWalker&) + 64
12 swift-ide-test           0x00000001091256bd swift::constraints::ConstraintSystem::generateConstraints(swift::Expr*) + 269
13 swift-ide-test           0x0000000109196f05 swift::constraints::ConstraintSystem::solve(swift::Expr*&, swift::Type, swift::ExprTypeCheckListener*, llvm::SmallVectorImpl<swift::constraints::Solution>&, swift::FreeTypeVariableBinding) + 501
14 swift-ide-test           0x0000000109313c8e swift::TypeChecker::solveForExpression(swift::Expr*&, swift::DeclContext*, swift::Type, swift::FreeTypeVariableBinding, swift::ExprTypeCheckListener*, swift::constraints::ConstraintSystem&, llvm::SmallVectorImpl<swift::constraints::Solution>&, swift::OptionSet<swift::TypeCheckExprFlags, unsigned int>) + 174
15 swift-ide-test           0x000000010931643b swift::TypeChecker::getTypeOfExpressionWithoutApplying(swift::Expr*&, swift::DeclContext*, swift::ConcreteDeclRef&, swift::FreeTypeVariableBinding, swift::ExprTypeCheckListener*) + 699
16 swift-ide-test           0x00000001094f2826 getTypeOfCompletionContextExpr(swift::TypeChecker&, swift::DeclContext*, swift::CompletionTypeCheckKind, swift::Expr*&, swift::ConcreteDeclRef&) + 310
17 swift-ide-test           0x00000001094f26aa swift::getTypeOfCompletionContextExpr(swift::ASTContext&, swift::DeclContext*, swift::CompletionTypeCheckKind, swift::Expr*&, swift::ConcreteDeclRef&) + 266
18 swift-ide-test           0x0000000108af5bec (anonymous namespace)::CodeCompletionCallbacksImpl::typeCheckParsedExpr() + 732
19 swift-ide-test           0x0000000108aee8d9 (anonymous namespace)::CodeCompletionCallbacksImpl::doneParsing() + 441
20 swift-ide-test           0x0000000109867036 (anonymous namespace)::parseDelayedDecl(swift::PersistentParserState&, swift::CodeCompletionCallbacksFactory*) + 934
21 swift-ide-test           0x0000000109866bf5 swift::performDelayedParsing(swift::DeclContext*, swift::PersistentParserState&, swift::CodeCompletionCallbacksFactory*) + 245
22 swift-ide-test           0x0000000108a8e91d swift::CompilerInstance::parseAndCheckTypes(swift::CompilerInstance::ImplicitImports const&) + 1277
23 swift-ide-test           0x0000000108a8de4c swift::CompilerInstance::performSema() + 1900
24 swift-ide-test           0x00000001088fb644 doCodeCompletion(swift::CompilerInvocation const&, llvm::StringRef, llvm::StringRef, llvm::StringRef, bool, bool, bool) + 2948
25 swift-ide-test           0x00000001088f3a8f main + 20959
26 libdyld.dylib            0x00007fff6dbdf015 start + 1
Stack dump:
0.	Program arguments: ./bin/swift-ide-test -code-completion -source-filename /Users/polzovatel/Desktop/test.swift -code-completion-token=SELF
1.	While type-checking expression at [/Users/polzovatel/Desktop/test.swift:11:33 - line:11:33] RangeText="."
1 Like

TBH no idea what you run there. Mind if you file the bug with all the steps to reproduce it and get the stack trace?!

Apologies. swift-ide-test is the tool used to test and run code completion when developing and debugging it, among other actions.

Mind if you file the bug with all the steps to reproduce it and get the stack trace?!

Sure. SR-8042


Filed as SR–8043


I 100% agree. This is a really annoying issue with operators, especially because custom and preset precedence groups have quite long names (i.e. LogicalConjunctionPrecedence). Just a side note on this topic, I'd would be nice if the predefined precedence groups had documentation to show both their hierarchy (relative to the other predefined precedence groups) and also the predefined operators that are of that precedence group.

1 Like

You should add to your bug report the lack of code completion for right and left in conjunction with associativity.

This documentation exists, at least partly. See table 3 in Operator Declarations.

The table lists the precedence groups for the operators in the standard library. It doesn't explicitly list the hierarchy of precedence groups, though. I'm not sure if the order of the groups in the table follows the hierarchy. Edit: "The infix operators are grouped below by precedence group in decreasing order of precedence." Thanks @Nevin for correcting me.

From your link:

“The infix operators are grouped below by precedence group in decreasing order of precedence. ”

1 Like

I updated the thread title to reflect the discussions here.

To add one into the bucket which is kind of critical:

  • There is no autocompletion for module names since for ever. (Only after import, but not if you want to reference a specific or own module for disambiguity reasons.)

I don't believe module names are visible until after the import, which is unfortunate. Referencing one without import is a compiler error.