Windows Terminal version
n/a — source-level, main @ 922beef
Windows build number
n/a
Other Software
No response
Steps to reproduce
-
Look at line 6 of src/cascadia/TerminalSettingsEditor/Utils.h:
$ grep -in settingcontainer src/cascadia/TerminalSettingsEditor/Utils.h
6:#include "SettingContainer.h"
That is the only occurrence of SettingContainer in the file's 149 lines.
-
SettingContainer.h line 21 includes Utils.h, so the two headers include
each other.
Expected Behavior
Utils.h holds the shared enum-binding macros and a few helpers, so it sits
below the individual controls. It shouldn't depend on a specific XAML control,
and the two headers shouldn't include each other.
Actual Behavior
Utils.h includes SettingContainer.h and never references it.
The include arrived in #19519, alongside BringIntoViewWhenLoaded(). That method
resolves elements with FindName(elementName) by string name, so it doesn't need
the control's type, and SettingContainer appeared only on the include line at
that commit as well. Before #19519 the include wasn't there.
Nothing reaches the type through it. Across the Settings Editor, four files
mention SettingContainer in C++: Appearances.h and SettingContainer.cpp include
SettingContainer.h directly, SettingContainer.h defines it, and Utils.h names it
only on line 6. The XAML pages that use the control in markup don't name it in
their C++.
Deleting line 6 puts the include list back to what it was before #19519, with no
call-site changes. I'd like to send that PR.
Two smaller things I left alone and can fold in if you want them: SettingContainer.h
includes Utils.h but uses nothing from it (DEPENDENCY_PROPERTY and BASIC_FACTORY
reach it from cppwinrt_utils.h via pch.h), so that include looks removable too.
Found while running my open-source include-graph checker
(https://github.com/blurman-ai/archcheck) over the Terminal sources.
Windows Terminal version
n/a — source-level, main @ 922beef
Windows build number
n/a
Other Software
No response
Steps to reproduce
Look at line 6 of src/cascadia/TerminalSettingsEditor/Utils.h:
$ grep -in settingcontainer src/cascadia/TerminalSettingsEditor/Utils.h
6:#include "SettingContainer.h"
That is the only occurrence of SettingContainer in the file's 149 lines.
SettingContainer.h line 21 includes Utils.h, so the two headers include
each other.
Expected Behavior
Utils.h holds the shared enum-binding macros and a few helpers, so it sits
below the individual controls. It shouldn't depend on a specific XAML control,
and the two headers shouldn't include each other.
Actual Behavior
Utils.h includes SettingContainer.h and never references it.
The include arrived in #19519, alongside BringIntoViewWhenLoaded(). That method
resolves elements with FindName(elementName) by string name, so it doesn't need
the control's type, and SettingContainer appeared only on the include line at
that commit as well. Before #19519 the include wasn't there.
Nothing reaches the type through it. Across the Settings Editor, four files
mention SettingContainer in C++: Appearances.h and SettingContainer.cpp include
SettingContainer.h directly, SettingContainer.h defines it, and Utils.h names it
only on line 6. The XAML pages that use the control in markup don't name it in
their C++.
Deleting line 6 puts the include list back to what it was before #19519, with no
call-site changes. I'd like to send that PR.
Two smaller things I left alone and can fold in if you want them: SettingContainer.h
includes Utils.h but uses nothing from it (DEPENDENCY_PROPERTY and BASIC_FACTORY
reach it from cppwinrt_utils.h via pch.h), so that include looks removable too.
Found while running my open-source include-graph checker
(https://github.com/blurman-ai/archcheck) over the Terminal sources.