After experimenting more, I think
- it ignores the return type of the function itself. even if it's
any.
- instead the type resolution seems to be determined based on the final expression in the function, overriding method return type ?
Based on this thread #206 , I tried both settings. It did not appear to change anything.
{ "powerquery.general.mode": "SDK",
"powerquery.general.mode": "Power Query" }
// like it determines this as any
= () as text => "str" as any
// and this as type text
= () as any => "str" as text
Expected behavior
For some of these cases I think the return type is guaranteed to be text but display as none instead.
Example = () as text => Text.Combine( {"a"} )
// tooltip: [let-variable] Example: none

I thought if the parser didn't know the return type of Text.Combine, the function assert forces it to be either text or errors ?
1] If it can't resolve it my function, should it say any instead? Because the function is using a return type that's not type none, so type none would not be possible in this case?
2] Is this correct? I thought a function with a return type declared, guaranteed the return value is compatible using a type assertion on the final value?
If I explicitly assert it twice, then it displays text
Example = () as text =>
Text.Combine( {"a"} ) as text
I think it's some interaction with the standard library definitions
One reason is because of this case. I tried asserting the return type as any
But the parser was able to tell adding two string literals has must be type text
// text 🟢
Any = () as any => "foo " & "bar",
// text 🟢
AnySum = () => Any(),
I was able to break the return type when the value was assert as any
Maybe the type resolution doesn't use function return types at all? It's resolving the type of the final value, instead?
// none ⛔
AnyExplicit2 = () as text => "foo " & "bar" as any,
// none ⛔
AnyExp2 = () => AnyExplicit2(),
Actual behavior

Is this a different repo ?
Nothing in the log stood out. Is it just the showing results from the Language Server ?
Everything is a TRACE
There are zero matches if you search it with the regex: info|warning|debug|error
So maybe this should be filed in a different repository ?
Long log: 2024-06-05-PowerQueryExtension-hoverTests.log
To Reproduce
I started a new vscode window -> new tab -> set language powerquery
Then pasted this script
The tooltip for Text.Combine has a return type
[library function] Text.Combine: (texts: list, separator: optional nullable text) => text
let
// text 🟢
GetText4 = () as text =>
"sdfd" & "23",
// none ⛔
GetText = (texts as list) as text =>
Text.Combine( {"a"} ),
// text 🟢
GetText2 = (texts as list) as text =>
Text.Combine( {"a"} ) as text,
// none ⛔
GetText3 = (texts as list) as text =>
"prefix" & Text.Combine( {"a"} ),
// none ⛔
GetText3B = (texts as list) as text =>
("prefix" as text) & Text.Combine( {"a"} ),
// text 🟢
GetText3C = (texts as list) as text =>
"prefix" & Text.Combine( {"a"} ) as text
in
...
Environment
- extension: 'PowerQuery.vscode-powerquery'
version: '0.1.60'
- extension: 'PowerQuery.vscode-powerquery-sdk'
version: '0.4.0'
- name: 'vscode'
version: '1.89.1 dc96b837cf6bb4af9cd736aa3af08cf8279f7685 x64'
Settings.json
I don't think the SDK engine is involved. It logged 1 line total.
After experimenting more, I think
any.Based on this thread #206 , I tried both settings. It did not appear to change anything.
{ "powerquery.general.mode": "SDK", "powerquery.general.mode": "Power Query" }Expected behavior
For some of these cases I think the return type is guaranteed to be
textbut display asnoneinstead.I thought if the parser didn't know the return type of
Text.Combine, the function assert forces it to be eithertextorerrors?1] If it can't resolve it my function, should it say
anyinstead? Because the function is using a return type that's nottype none, sotype nonewould not be possible in this case?2] Is this correct? I thought a function with a return type declared, guaranteed the return value is compatible using a type assertion on the final value?
If I explicitly assert it twice, then it displays text
I think it's some interaction with the standard library definitions
One reason is because of this case. I tried asserting the return type as
anyBut the parser was able to tell adding two string literals has must be type text
I was able to break the return type when the value was assert as any
Maybe the type resolution doesn't use function return types at all? It's resolving the type of the final value, instead?
Actual behavior
Is this a different repo ?
Nothing in the log stood out. Is it just the showing results from the
Language Server?Everything is a
TRACEThere are zero matches if you search it with the regex:
info|warning|debug|errorSo maybe this should be filed in a different repository ?
Long log: 2024-06-05-PowerQueryExtension-hoverTests.log
To Reproduce
I started a new vscode window -> new tab -> set language powerquery
Then pasted this script
The tooltip for
Text.Combinehas a return typeEnvironment
Settings.json
{ "powerquery.diagnostics.typeStrategy": "Extended", "powerquery.trace.server": "verbose", "powerquery.general.mode": "SDK", }I don't think the SDK engine is involved. It logged 1 line total.