When typing up the following expression:

section Section1;

shared A = @A; // for simplicity's sake; for a real life example, pretend that A is a recursive function 
shared B = A;

IntelliSense for B's expression correctly includes identifier A in the list of options provided; however, the IntelliSense for A's expression does not include itself, even when using an inclusive identifier reference (@A).

Seems like A's IntelliSence should include itself, at least when an @-reference is being used.

We currently return context sensitive keywords in the completion item list, but are missing

• primitive type constants (number, datetime, etc)
• type/parameter modifier constants (nullable, optional)

Ideally these would be context sensitive (like keywords). This is being tracked in the parser repo:
microsoft/powerquery-parser#161

In M, it is valid to name function parameters after M types, as parameter names will not be interpreted as type names when defining a function’s signature. However, syntax highlighting does not seem to make this distinction.

Expected behavior
In a function signature, parameters that have the same names as M types should be syntax highlighted the same as parameters with other names.

Actual behavior
Parameters with the same names as M types are highlighted differently.

Notice below how the red-underlined parameter names (which are identical to M type names) receive different syntax highlighting than the green-underlined one.

To Reproduce
In VSCode, create a Power Query file containing the following content:

(table as table, function as function, a as number) as any => ...

Expected behavior
If there are duplicate keys in a record type I'd assume it to mark them as duplicate.

Actual behavior
No checks are made against RecordType.

To Reproduce

type [ foo, foo]

Additional context
It was originally included as part of the check but there was a mistake in the assumptions. You can't use the parser's existing helper functions to iterate over a RecordType (or more specifically a FieldSpecificationList + FieldSpecification). Enhancements to the parser is recommended first, then the logic should be simplified in the language services layer.

Expected behavior
I was testing some things in the language services layer. Take for example the following setup:

let
    foo.bar = 1,
    #"unneededQuote" = 2,
    #"quoted identifier" = 3
in
    |

• With no text it has the following recommendations: foo.bar, unneededQuote, #"uneededQuote", and #"quoted identifier".
• With foo. for text it has the following recommendations: foo.bar
• With any subset of a quoted identifier (eg. #, #", #"", etc) it should recommend the quoted identifier.

Actual behavior

• With no text it has the following recommendations: foo.bar, unneededQuote, #"uneededQuote", and #"quoted identifier".
• With foo. for text it has the following recommendations: foo.bar
• With any subset of a quoted identifier (eg. #, #", #"", etc) it does not recommend anything.

To Reproduce
See the setup in expected behavior

Additional context
The initial hurdle is the lexer will fail to lex if it encounters a trailing #, as it's attempting to read a keyword but fails. Instead I might want to attempt to read a keyword but fallback in starting a quoted identifier. Additionally we might need to tweak the trailing token logic to include quoted identifiers.

Repro in VS Code.

When defining a let member, keywords show up in the completion items when there is no value ...

but do not show up once you start typing.

settings:

{
  "powerquery.diagnostics.typeStrategy": "Extended",
  "powerquery.general.mode": "SDK",
  "powerquery.general.experimental": true
}

An inspection on the code below evaluates fn as a function that returns none.

let fn = (optional x as text) => if x <> null then 1 else 2 in fn

Expected behavior
The type system to not experience infinite loops.

Actual behavior
The type system is experiencing an infinite loop.

To Reproduce
Attempt to resolve the type for the following expression:

let count = (x as number) => if x = 0 then 0 else 1 + @count(x - 1) in @count(10)

Repro:

section grr;

var = Table.TransformColumns(expandEntity, {
{"attributes", TableTypeFromAttributes},
{"culture", each if (_ = null) then defaultCulture else _}
});

In VS Code, this simple section document was giving me validation errors:

{
    "kind": "Error",
    "error": {
        "innerError": {
            "innerError": {
                "kind": "Error",
                "error": {
                    "innerError": {
                        "innerError": {
                            "kind": "Error",
                            "error": {
                                "innerError": {
                                    "innerError": {}
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}

Expected behavior
Non-value identifiers should not have a jump to definition option.

Actual behavior
Given let foobar = 1 in [foobar = foobar], getDefinitions will return a Location instance for the record key. This happens because foobar is under the identifier and is also in scope. The correct behavior would be to exclude getDefinitions except for value identifierKinds.

To Reproduce
See above.

Additional context
N/A

#16 adds duplicate identifier warnings, but doesn't cover duplicate function parameters.

If we're expecting an identifier constant (i.e. lefthand side of variable declaration), we shouldn't return completion items.

let a = 1,|

We should follow the process used for powerquery-parser to support localized error messages.

section example;

shared foo = "foo";

shared bar =
    let
        tbl = Odbc.DataSource(""),
        bar = "bar"
    in
        Table.AddColumn(
            tbl,
            "foobar",
            each foo & bar
        );

I'd expect it to recognize foo and bar, but they're both marked as unknown. De-sugaring the each into a FunctionExpression ((x as any) => foo & bar) makes it work as expected.

currentDocumentSymbolProvider needs to be updated to support Hover and SignatureHelp functionality for locally defined symbols.

analysis needs to be updated to call additional providers for this information.

The FieldProjection is expecting to be part of a RecursivePrimaryExpression.

ref: microsoft/vscode-powerquery#105

Given function definition:

Table.Combine = (tables as list, optional columns as any) => ...

We should report diagnostic errors for function invocations when:

1. parameters are missing (Table.Combine())
2. too many parameters are specified (`Table.Combine({ myTable, myTable2 }, tableType, "extra parameter")
3. parameter type mismatches (Table.Combine("hello"))

Return diagnostic for unknown identifiers.

Notes

• Validate will need to start using the symbol providers
• We'll likely want to adjust the logic in (or at least share code with) currentDocumentSymbolProvider to track local symbols
• We might need this check to be optional, or at least allow the caller to set the diagnostic severity level (this might be a general feature we want to support for all diagnostic codes)

Expected behavior

Validation should not report unknown identifiers when @ is used unnecessarily.

Actual behavior

[{
	"resource": "/d:/pq/Table.ChangeType.pqm",
	"owner": "_generated_diagnostic_collection_name_#1",
	"code": "Error.UnknownIdentifier",
	"severity": 8,
	"message": "Cannot find the name '@List.ChangeType', did you mean 'List.ChangeType'?",
	"source": "powerquery",
	"startLineNumber": 135,
	"startColumn": 77,
	"endLineNumber": 135,
	"endColumn": 93
}]

To Reproduce

Repro'd with the Table.ChangeType.pqm sample file. There are three errors for the use of @ in the GetTransformByType function.

https://raw.githubusercontent.com/microsoft/DataConnectors/master/samples/TripPin/10-TableView1/Table.ChangeType.pqm

Additional context

I know the @ is not needed, but it doesn't cause a compilation error, so I feel it shouldn't be reported as a validation error. This would be something we could report as part of a lint utility for code health.

The repo should have tests that replicate common integration scenarios for VS Code and Monaco Editor.

• Replicates integration code / library usage
• Check that all expected exports are available

Expected behavior
I'd expect the following to not give autocomplete items:

let foo |=

Actual behavior
Returns a list of keywords for expressions:

To Reproduce
See above.

Additional context
Add any other context about the problem here.