shortenFullyQualifiedTypes can change type resolution for inherited nested types
メンテナーはふだん 1 日以内に返信
評価
調査の方向性
Start with the shortenFullyQualifiedTypes() implementation and reproduce the issue using the linked Gradle project and ./gradlew spotlessApply. Trace how inherited nested types affect shortening decisions, then verify that the qualified external.Type reference remains safe and the formatted project still compiles.
索引モデルが issue の本文から書いたものです。
説明
Summary
shortenFullyQualifiedTypes can change the meaning of a qualified type when the simple name is also an inherited nested type.
The formatter avoids some collisions with types declared in the same compilation unit, but does not appear to account for member types inherited from a superclass or interface.
Reproducer
Spotless Gradle plugin 8.10.3, with shortenFullyQualifiedTypes() as the only configured Java step:
The complete Gradle project is available here:
https://gist.github.com/MattAlp/a50100bc9d712c470ded424c36e8f315
The reproducer contains:
Base, which declares nested typeTypeChild, which extendsBaseexternal.Type, which is referenced by fully qualified name
Before formatting, Child contains:
public static String use(external.Type value) {
return value.externalOnly();
}
The project compiles successfully. After running:
./gradlew spotlessApply
Spotless adds import external.Type; and changes the code to:
public static String use(Type value) {
return value.externalOnly();
}
The unqualified Type resolves to the inherited Base.Type, not external.Type. Compilation then fails:
cannot find symbol
method externalOnly()
location: variable value of type Type
Suggested behavior
Leave a qualified reference alone when its simple name can resolve to an inherited member type. If this cannot be determined without a classpath, the conservative behavior should be to leave the qualification intact.
Related work
This appears related to:
- #3033 — same-compilation-unit type collisions
- #3031 — collisions with types declared in the same file
- #3037 — preserving existing unqualified type resolution
- 主要言語
- Java
- スター
- 5.7k
- フォーク
- 563
- 平均マージ
- 2日 2時間
- マージ済み PR（30日）
- 57
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
diffplug/spotless のほかの issue
-
google-java-format 1.37.0: NoSuchMethodError on JavaFormatterOptions$Style.valueOf (Style is now a record)対応中かも @Goooler が 3 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
diffplug/spotless#3126 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
diffplug/spotless#3125 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Add support for org.eclipse.jdt.core.formatter.insert_new_line_after_annotation_on_record_parameterオープン
難易度 3/5 1〜2日 初心者へのやさしさ 67/100
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
メンテナーはふだん 1 日以内に返信
diffplug/spotless の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
jenkinsci/gitlab-plugin#1950 ·
-
It's not necessary to copy the memory block in the readWrite() of org.h2.store.fs.mem.FileMemDataオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
h2database/h2database#4435 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
micronaut-projects/micronaut-core#13717 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
ADORSYS-GIS/token-status-link#145 ·
メンテナーはふだん 3 日以内に返信
-
enhancement
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
helidon-io/helidon#12721 ·
メンテナーはふだん 1 日以内に返信