PSUseConsistentIndentation double-indents attribute bodies that open a scriptblock (`[Attr({ … })]`)
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 3/5
- Temps estimé
- 1-2 jours
- Accessibilité débutants
- 70/100
Piste de recherche
Commencez par exécuter la reproduction fournie de Invoke-Formatter avec PSUseConsistentIndentation activé, puis suivez la gestion de l’indentation pour la règle PSUseConsistentIndentation lorsqu’un attribut ou un littéral de type ouvre un scriptblock. Ajoutez un test de régression couvrant [ArgumentCompleter({ ... })] et [ValidateScript({ ... })], en vérifiant un niveau d’indentation du corps et le })] fermant au niveau de l’élément ouvrant.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Prerequisites
- I have read the documentation and my issue is not covered there.
- I have searched the existing issues and my issue is not already reported.
Summary
PSUseConsistentIndentation (and therefore Invoke-Formatter) double-indents the body of an attribute that opens a scriptblock, e.g. [ArgumentCompleter({...})]. The body gets IndentationSize * 2 and the closing })] gets IndentationSize * 1.
This looks like the same root cause as #2159 (hashtable inside a method call: the LParen and the AtCurly each add an indentation level). Here the two adjacent openers are ( and { from a type/attribute literal instead of @{, so [AttributeName({ hits it too. #2159 was fixed on main by #2173 ("only the last unclosed opener on a line affects indentation"), but neither that fix nor #2159 covers the attribute form, and it is still broken in the latest release 1.25.0.
Steps to reproduce
$code = @'
[ArgumentCompleter({
Param($commandName, $parameterName)
$validKeys = @('a', 'b')
$validKeys | Where-Object { $_ } | ForEach-Object { "$_=" }
})]
'@
$settings = @{
IncludeRules = @('PSUseConsistentIndentation')
Rules = @{
PSUseConsistentIndentation = @{
Enable = $true
IndentationSize = 4
Kind = 'tab'
}
}
}
Invoke-Formatter -ScriptDefinition $code -Settings $settings
Expected behavior
One level of indentation for the body, matching the opener line, and the closing })] at the opener's level:
[ArgumentCompleter({
Param($commandName, $parameterName)
$validKeys = @('a', 'b')
$validKeys | Where-Object { $_ } | ForEach-Object { "$_=" }
})]
Actual behavior
Two levels for the body and one level for the closing })]:
[ArgumentCompleter({
Param($commandName, $parameterName)
$validKeys = @('a', 'b')
$validKeys | Where-Object { $_ } | ForEach-Object { "$_=" }
})]
The same happens with spaces (Kind = 'space', IndentationSize = 4) and with NewLineAfterOpenBrace/PSPlaceOpenBrace not involved at all — PSUseConsistentIndentation alone is enough.
It also affects other attribute forms that open a scriptblock, e.g.
[ValidateScript({
$_ -gt 0
})]
and the buggy output is not idempotent in a harmless way: because the opener line itself is not re-indented, re-running the formatter keeps the body at the wrong level, and any tool that re-applies formatting sees a permanent diff.
Environment
PSVersion: 7.6.6
PSEdition: Core
OS: Windows 11 (26100)
PSScriptAnalyzer: 1.25.0
Also reproduced with PSScriptAnalyzer 1.24.0 (bundled with ms-vscode.powershell 2025.4.0) and with Windows PowerShell 5.1 / 26100 (Desktop edition), so it is not host- or edition-specific.
Related
- #2159 —
PSUseConsistentIndentation: Hashtable inside method call gets double-indented (sameLParen+XCurlydouble count; fixed by #2173) - #2173 — the fix that pops the level when an opener is not the last unclosed opener on the line; it does not catch the attribute opening
({ - #1168 — "Formatting
.whereand.foreachmethods is incorrect" (adjacent-opener family)
- Langage dominant
- C#
- Étoiles
- 2.2k
- Forks
- 415
- Merge moyen
- 13 h 1 min
- PR mergées (30 j)
- 2
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.
Autres issues de PowerShell/PSScriptAnalyzer
-
Up-for-Grabs
Difficulté 1/5 1-3 heures Accessibilité débutants 78/100
PowerShell/PSScriptAnalyzer#2213 · 2 commentaires ·
-
Difficulté 3/5 1-2 jours Accessibilité débutants 72/100
PowerShell/PSScriptAnalyzer#2217 · 1 commentaire ·
-
Difficulté 3/5 1-2 jours Accessibilité débutants 68/100
PowerShell/PSScriptAnalyzer#2211 ·
-
`PSPlaceOpenBrace` and `PSPlaceCloseBrace` leave trailing whitespace when expanding one-line blocks Ouverte
Difficulté 3/5 1-2 jours Accessibilité débutants 70/100
PowerShell/PSScriptAnalyzer#2210 ·
-
Difficulté 3/5 1-2 jours Accessibilité débutants 55/100
PowerShell/PSScriptAnalyzer#2209 ·
Toutes les issues de PowerShell/PSScriptAnalyzer
Issues similaires
-
type/automation type/tech-debt
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
-
t/bug
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
-
ci-failure-cause test-failure
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
-
area:auth FE mvp P3
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
klasolsson81/jobbliggaren#1788 ·