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

Clean up and rationalize imports in the compiler #11409

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

DustinCampbell
Copy link
Member

@DustinCampbell DustinCampbell commented Jan 23, 2025

This change represents a lot of clean up and consolidate a lot of code around how imports are provided and queried for in the compiler.

There are a couple of API breaking changes here that shouldn't have external impact. In particular, I've made IImportProjectFeature internal and changed its API significantly. In addition, I've rewritten RazorProjectFileSystem.FindHierarchicalItems(...) to reduce allocations, make it more efficient, and return its results in reversed order (since every caller immediately called Reverse()).

CI Build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2626377&view=results
Test Insertion: https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/605137

This provides better debugger strings for the RazorProjectItems that represent default imports.
Some were sealed, some weren't.
This change makes the IImportProjectFeature interface internal. In addition, the SetImportFeature extension method on RazorProjectEngineBuilder has been moved to the common test library, since it's really intended to be used by tests.

This is a public API breaking change, but there are no users of these APIs in dotnet/sdk.
Consolidate the three "TestImportProjectFeature" classes and place it in Microsoft.AspNetCore.Razor.Test.Common.
This change introduces a DefaultImportProjectItem that is shared across features that add default imports.
Add a couple of methods to PooledArrayBuilder to produce a reversed ImmutableArray.
This change rewrites RazorProjectFileSystem.FindHierarchicalItems(...) to avoid allocations. It now returns results in reverse order, since every caller in Razor immediately called `Reverse()`. In addition, the access has been reduced to internal since there are no external callers of this method.
@DustinCampbell DustinCampbell requested review from a team as code owners January 23, 2025 01:58
@DustinCampbell
Copy link
Member Author

This change will require @dotnet/razor-compiler reviews. cc @chsienki, @333fred, @jjonescz, and @jaredpar

FindHierarchicalItem has a "max depth" check to ensure that it returns a maximum of 255 file paths. However, all this method does is perform string manipulation by looking for '/' characters. It does not actually touch the file system.

Technically, this could result in a breaking change because this method is used to find applicable Imports files. So, if the user had a Razor project with 256+ nested subdirectories, the compiler would now consider Imports that it might not have considered in the past. However, that seems like a highly unlikely situation and it's even more unlikely that a user would depend on that behavior.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants