PSUseConsistentIndentation double-indents attribute bodies that open a scriptblock (`[Attr({ … })]`)
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 70/100
Direzione di ricerca
Inizia eseguendo la riproduzione fornita di Invoke-Formatter con PSUseConsistentIndentation abilitato, quindi traccia la gestione dell'indentazione per la regola PSUseConsistentIndentation quando un attributo o un literal di tipo apre uno scriptblock. Aggiungi un test di regressione che copra [ArgumentCompleter({ ... })] e [ValidateScript({ ... })], verificando un livello di indentazione del corpo e il })] di chiusura al livello dell'elemento di apertura.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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)
- Lingua principale
- C#
- Stelle
- 2.2k
- Fork
- 415
- Merge medio
- 13h 1m
- PR unite (30g)
- 2
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di PowerShell/PSScriptAnalyzer
-
Up-for-Grabs
Difficoltà 1/5 1-3 ore Idoneità per principianti 78/100
PowerShell/PSScriptAnalyzer#2213 · 2 commenti ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 72/100
PowerShell/PSScriptAnalyzer#2217 · 1 commento ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
PowerShell/PSScriptAnalyzer#2211 ·
-
`PSPlaceOpenBrace` and `PSPlaceCloseBrace` leave trailing whitespace when expanding one-line blocks Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 70/100
PowerShell/PSScriptAnalyzer#2210 ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
PowerShell/PSScriptAnalyzer#2209 ·
Tutte le issue di PowerShell/PSScriptAnalyzer
Issue simili
-
type/automation type/tech-debt
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
-
t/bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
-
ci-failure-cause test-failure
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
-
area:auth FE mvp P3
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
klasolsson81/jobbliggaren#1788 ·