[SourceKit] Report cursor info information for literals

[barinsim]

Adds literals support for the CursorInfo request.
Previously CursorInfo just returned error for literals.
Resolves #57725

[ahoppen]

Thanks a lot for the PR, @barinsim. I’ve got a couple of minor comments inline. On a more general level, I think the problem you’ve been facing is that all of cursor info is designed to always reference a declaration, if you’re doing cursor info on a function call, we report the function declaration or if you’re doing cursor info on a variable, we return the corresponding variable declaration.

For literals, there isn’t such a natural declaration and that’s why you needed to add a LitExpr to DeclInfo, which doesn’t really make sense since the information about a declaration (that’s what DeclInfo is), shouldn’t need an expression. And that’s also why you needed the isLiteral checks.

What I would suggest is that we report the initializer that actually constructs eg. a Double from the literal (Double.init(_builtinIntegerLiteral:)) in cursor info. That initializer returns a value of type Double so you shouldn’t need all the special isLiteral handling anymore. You should be able to get that initializer using getBuiltinInitializer on BuiltinLiteralExpr.

Let me know if you need help with anything or have any questions about my suggestion or in general.

---

And one small thing: Could you run git-clang-format before committing your sources to make sure they are formatted correctly?

[barinsim]

@ahoppen Thank you very much for your feedback! Reporting the actual initializer definitely fits better 🙂 I hope I addressed everything.

2 quick notes:

• I preferred the getInitializer() and use getBuiltinInitializer() as a fallback, because I would argue in this case:

struct A: ExpressibleByIntegerLiteral {
    init(integerLiteral value: Int) {
        self.value = value
    }
    let value: Int
}
var a: A = 42

for 42 we want to report the user defined init instead of the builtin one.

• The node for the nil literal does not contain any initializer info. I am not sure why nor if it is expected. For now, I removed the 2 testcases testing the nil

[ahoppen]

• I preferred the getInitializer() and use getBuiltinInitializer() as a fallback, because I would argue in this case:

struct A: ExpressibleByIntegerLiteral {
    init(integerLiteral value: Int) {
        self.value = value
    }
    let value: Int
}
var a: A = 42

for 42 we want to report the user defined init instead of the builtin one.

Oh, that’s even better. I didn’t think to look for getInitializer after I found getBuiltinInitializer. Good catch 👍🏽

• The node for the nil literal does not contain any initializer info. I am not sure why nor if it is expected. For now, I removed the 2 testcases testing the nil

Cursor info still works on nil if you have a custom type that conforms to ExpressibleByNilLiteral, e.g.

struct MyOptional: ExpressibleByNilLiteral {
  init(nilLiteral: ()) {}
}
let _: MyOptional = nil

The issue why we don’t get cursor info when nil is used for Optional is that the initializer doesn’t get set here

swift/lib/Sema/CSApply.cpp

Lines 2628 to 2634 in 0591975

	// By far the most common 'nil' literal is for Optional<T>.none.
	// We don't have to look up the witness in this case since SILGen
	// knows how to lower it directly.
	if (auto objectType = type->getOptionalObjectType()) {
	cs.setType(expr, type);
	return expr;
	}

If you wanted to, you could look into setting the initializer here as well but I’m not entirely sure what the trade-off is between performance of looking up Optional.init(nilLiteral:) vs the value you get out of cursor info on these nil literals. In either case, I think this change shouldn’t be part of this PR.

[ahoppen]

Looks very good. I just have a few minor comments.

[barinsim]

@ahoppen Thank you very much for iterating on this with me! 🙂 I addressed the last changes you proposed. If they look alright to you, could you please run the CI?

[ahoppen]

Thank you @barinsim. Looks great to me

[ahoppen]

@swift-ci Please test

[ahoppen]

This change breaks test/refactoring/RefactoringKind/basic.swift:

When you have an interpolated string literal and perform cursor info on it, previously we got an interpolated string literal expression. With this change, we get the string literal expression of the first segment inside the string literal before the first interpolation and thus offer to localize the string, which we shouldn’t. I checked and it looks like this change is no longer necessary to get cursor info for literals. Could you revert it?

[barinsim]

@ahoppen Yes, you are right 👍 I added a test case into the CursorInfo suite as well.

During which I found that getting info of the expression segment in the interpolated string does not work. We consider the whole interpolated string as a single token which has nested tokens within the expression segments. For example this causes that getSourceRange() for ValueDecl returns such range:

<START>var foo = <END>"Hello \(42) world"

This does not work if you are looking for the node of the 42. Converting to a char based range fixed this.

[ahoppen]

Oh, the good old char source range conversion for interpolated string literals. I so wish this wouldn’t be necessary. 🙄 Good catch though.

[ahoppen]

@swift-ci Please smoke test