Skip to content
This repository was archived by the owner on Apr 27, 2026. It is now read-only.

Magic command hover text plus some bug fixes#3604

Merged
jonsequitur merged 5 commits into
dotnet:mainfrom
jonsequitur:bug-fixes-for-new-magic-command-parser
Jul 19, 2024
Merged

Magic command hover text plus some bug fixes#3604
jonsequitur merged 5 commits into
dotnet:mainfrom
jonsequitur:bug-fixes-for-new-magic-command-parser

Conversation

@jonsequitur

@jonsequitur jonsequitur commented Jul 19, 2024

Copy link
Copy Markdown
Contributor

This PR adds support for hover text in magic commands.

It also includes fixes for a couple of issues with the new magic command parser:

  • Inputs trigger user prompts when certain language service commands are sent. They should only do this for SubmitCode.
  • Name the previously-nameless parameter for #!import to --file
  • Fix the description for the #!import --file parameter

@jonsequitur
jonsequitur marked this pull request as ready for review July 19, 2024 16:34

result.Events.Should().NotContainErrors();

requestInputWasSent.Should().BeFalse();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

consider: Add an AssertionScope since there are multiple asserts

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typically that's only useful if the multiple asserts can fail independently. The first assert here is more of a sanity check.


[Theory]
[MemberData(nameof(LanguageServiceCommands))]
public async Task Language_service_commands_do_not_trigger_input_requests(KernelCommand command)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this test fails - will this display the name of the command that is failing? It would be nice if we could do something so that it is easier to know the command (and code) for the failure case

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, test output shows the parameters for the failing case.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah was asking if we can tell by looking at the view in the test runner itself without clicking to inspect the output. But not a huge issue either way.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, most test runners support this.

hoverText = parameter.Description;
}

break;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add a defualt: case to throw for unexpected node type?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. It's not an exceptional case. Some node types don't (currently) support hover text.

var bindingResult = await bind(expressionNode);

if (bindingResult.IsSuccessful)
if (bindingResult is not null)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When can this return null? Should an error be reported (or an exception thrown) when null is returned?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it can be modeled differently but we don't want to perform binding during language service commands, since the resulting directive command won't actually be invoked.

if (expressionType is "input" or "password")
{
var parametersNode = expressionNode.ChildNodes.OfType<DirectiveExpressionParametersNode>().SingleOrDefault();
if (command is SubmitCode)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this always going to be a SubmitCode? If yes, should this throw an exception if some other command is present?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Submission splitting happens for many different command types, including language service commands. We don't want the non-SubmitCode commands to trigger user prompts though.

bool allowByRef,
DirectiveExpressionNode expressionNode)
{
// FIX: (RequestSingleValueFromKernel) make sure this is not dispatched on language service commands

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you intend to remove the // FIX comments before merge or is this something that needs to be fixed up in follow up PRs?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll remove this one since it was resolved.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants