Skip shebang when checking transitive directive feature flag#53604
Skip shebang when checking transitive directive feature flag#53604jjonescz wants to merge 2 commits intodotnet:release/10.0.3xxfrom
Conversation
There was a problem hiding this comment.
Pull request overview
Updates file-based dotnet run directive feature-flag gating so that a shebang (#!) inside an included file doesn’t incorrectly require the transitive directives experimental flag, and adds a regression test to cover the scenario.
Changes:
- Exclude
CSharpDirective.Shebangfrom the transitive-directives feature-flag check when the directive originates from a non-entrypoint file. - Add a test validating that an included file containing only a shebang works with include-directive enabled (without enabling transitive directives).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| test/dotnet.Tests/CommandTests/Run/RunFileTests.cs | Adds regression coverage for shebang in an included file not requiring the transitive-directives flag. |
| src/Microsoft.DotNet.ProjectTools/VirtualProjectBuilder.cs | Adjusts directive validation to skip shebang when deciding whether to require the transitive-directives feature flag. |
| """); | ||
|
|
||
| File.WriteAllText(Path.Join(testInstance.Path, "Util.cs"), $""" | ||
| #!/usr/bin/env dotnet |
There was a problem hiding this comment.
It feels like there is a risk that in the future, tooling will treat Util.cs as also being an entry point, due to presence of #!. Is it fine for an entry point to reference another entry point?
That said, I think I buy that the "is transitive directives feature flag enabled" check wouldn't be the place to enforce anything in particular about that anyway.
There was a problem hiding this comment.
Is it fine for an entry point to reference another entry point?
It can work. Even something as simple as file1.cs with top-level statements referencing file2.cs with a Main method - both work as standalone entry points too. Then there are the more complex cases of test frameworks that synthesize entry points - no file has an explicit entrypoint so they can reference each other but can also run separately.
Without this,
#!in an#:included file requires the experimental opt-in which seems pointless since#!is ignored by the dotnet CLI.