Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove design-time __TypeConstraints functions #8825

Merged
merged 5 commits into from
Jul 4, 2023

Conversation

jjonescz
Copy link
Member

@jjonescz jjonescz commented Jun 12, 2023

Fixes #8711.
Fixes #8558.

@jjonescz jjonescz added the area-compiler Umbrella for all compiler issues label Jun 12, 2023
@jjonescz jjonescz marked this pull request as ready for review June 12, 2023 16:29
@jjonescz jjonescz requested a review from a team as a code owner June 12, 2023 16:29
Copy link
Member

@333fred 333fred left a comment

Choose a reason for hiding this comment

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

This is generally looking ok, but I'd like to have @davidwengier take a look at this change as well to make sure there's no gotchas we're missing from the IDE side. Also, if you could do a smoke test in the IDE and make sure everything appears to be working Jan, that would be appreciated.

@@ -123,10 +123,12 @@ protected override CodeTarget CreateTarget(RazorCodeDocument codeDocument, Razor
continue;
}

var constraints = typeParamNode.Tokens.Skip(1).FirstOrDefault();
Copy link
Member

Choose a reason for hiding this comment

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

What is this parameter we're skipping? Please leave a comment.

Side note: at some point we need to remove all of these IEnumerables and make them ImmutableArrays/Spans for this type of thing.

Copy link
Member Author

Choose a reason for hiding this comment

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

image

This is just extracted variable from existing code. But will add a comment.

Copy link
Member

@davidwengier davidwengier left a comment

Choose a reason for hiding this comment

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

From looking at the new baselines, this looks good from a tooling perspecitve. Would appreciate a smoke test, for sure. I would just make sure that if you hover over an interface name in a constraint, the hover shows correctly. I had a quick play and it seems formatting doesn't work currently anyway (logged #8827)

It is surprising to me that there is no padding on the output, ie this generates:

where T : IFoo

rather than

where
          T : IFoo

but the previous code didnt' do it either, so its fine. Normally this means that certain Roslyn code actions may not apply well (the padding is so that the C# code ends up at the same column positions as the original user written Razor code). It's also possible there just arent any problematic code actions issued by roslyn for type constraints.

In general though, I think this change is perfectly in line with the direction we need to be going, regardless of bug fixing. Having the "real" C# code source mapped, instead of generating design time helpers, should provide a better experience for users, and gets us ever so slightly closer to runtime and designtime being the same.

@jjonescz
Copy link
Member Author

jjonescz commented Jun 14, 2023

It is surprising to me that there is no padding on the output

Yeah, I also noticed, but didn't want to change the code more than necessary in one PR. Also I'm wondering - padding is equivalent to using enhanced line pragma, right?

if you could do a smoke test in the IDE

Everything seems to be working fine (except for sometimes hitting this issue #8572).

image

image

image

@davidwengier
Copy link
Member

padding is equivalent to using enhanced line pragma, right?

That is also my understanding, and I don't see why we can't move to enhanced line pragmas across the board at some point. The source mappings we get directly from the compiler already have that level of fidelity anyway.

Definitely something for another PR though :)

@jjonescz jjonescz requested review from 333fred and chsienki June 15, 2023 08:06
@jjonescz
Copy link
Member Author

@chsienki @dotnet/razor-compiler for a second review, thanks

@jjonescz jjonescz enabled auto-merge (squash) July 4, 2023 06:55
@jjonescz jjonescz added this to the 17.8 P1 milestone Jul 4, 2023
@jjonescz jjonescz merged commit ddae74f into dotnet:main Jul 4, 2023
@jjonescz jjonescz deleted the 8711-ShadowedTypeParam branch July 4, 2023 07:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-compiler Umbrella for all compiler issues
Projects
None yet
4 participants