PowerShell / PowerShell/PowerShell
The Parser is handing out Internal objects like candy and (may be) poisoning children
Personne n'a encore pris cette issue.
- Langage dominant
- C#
- Étoiles
- 55.5k
- Forks
- 8.5k
- Merge moyen
- 1 j 2 h
- PR mergées (30 j)
- 88
Description
Trying to write a ScriptAnalyzer rule, and needed to generate an Extent for the DiagnosticRecord which is slightly modified from the ones found in the AST object that are passed to me ...
Imagine my surprise when I tried to cast the .Extent on one of these AST objects to a System.Management.Automation.Language.ScriptExtent and got an exception saying PowerShell doesn't know how to convert a System.Management.Automation.Language.InternalScriptExtent to that.
So then I tried to just make one:
[System.Management.Automation.Language.ScriptExtent]::new(
$FunctionAst.Extent.StartScriptPosition,
$FunctionAst.Extent.EndScriptPosition)
Did you know that InternalScriptExtent.StartScriptPosition and EndScriptPosition are also internal classes? Of course! So now I get a giant wall of red which is best summarized as:
Cannot convert "InternalScriptPosition" to type "ScriptPosition"
All I wanted to do was increment the line numbers, so I had to write this:
# Because we can't just modify $comment.Extent:
# $comment.Extent.StartScriptPosition.LineNumber += $Extent.StartLineNumber -1
# We have to create a whole new ScriptExtent object:
$Extent = [System.Management.Automation.Language.ScriptExtent]::new(
[System.Management.Automation.Language.ScriptPosition]::new(
$FunctionAst.Extent.StartScriptPosition.File,
($FunctionAst.Extent.StartScriptPosition.LineNumber + $comment.Extent.StartScriptPosition.LineNumber - 1),
$FunctionAst.Extent.StartScriptPosition.ColumnNumber,
$comment.Extent.StartScriptPosition.Line,
$FunctionAst.Extent.StartScriptPosition.GetFullScript()),
[System.Management.Automation.Language.ScriptPosition]::new(
$FunctionAst.Extent.EndScriptPosition.File,
($FunctionAst.Extent.EndScriptPosition.LineNumber + $comment.Extent.EndScriptPosition.LineNumber - 1),
$FunctionAst.Extent.EndScriptPosition.ColumnNumber,
$comment.Extent.EndScriptPosition.Line,
$FunctionAst.Extent.EndScriptPosition.GetFullScript())
)
But I found the output of this has the StartOffset and EndOffset always equal to zero -- and they are not settable in any way, because they're ReadOnly and not exposed to the constructors.
- Feature request: add a cast operator to the ScriptExtents please
- Feature request: add a cast operator to the ScriptPositions please
- Feature request: make all of the numbers on the public objects settable
- Bug: stop returning Internal objects from public APIs (in this case,
Parser.Parse)
cc @daxian-dbw
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par suivre Parser.Parse ainsi que les types publics ScriptExtent et ScriptPosition, en les comparant aux objets InternalScriptExtent et InternalScriptPosition décrits dans le rapport. Clarifiez lequel des quatre changements demandés entre dans le périmètre, puis ajoutez une couverture ciblée pour le comportement choisi de l’API publique, y compris la préservation des offsets le cas échéant.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- csharp, powershell
- Domaine
- backend-api-design, cli, compilers
- Type d'issue
- Fonctionnalité
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Activité
- À l'abandon
- Clarté
- Plutôt claire
- Accessibilité débutants
- 30/100