Skip to content
| Marketplace
Sign in
Visual Studio>Tools>VS19OutputHumanizator

VS19OutputHumanizator

Mirroanwe

|
5 installs
| (0) | Free
The translator of the output build and debug windows to the human readable format

The version for VS2022

What is it?

"Humanization" is a process of making something less unpleasant and more suitable for people. A C++ compiler sometimes produces quite sophisticated error reports, especially in case of templates. It also ignores the typedefs and the usings in the code base. This extension makes a sequence of transformations defined by the user, to make the output report human readable.

In a following example, line std::basic_string<char,std::char_traits<char>,std::allocator<char>> was transformed into string:

prog.png

The regular output:

regular.png

The transformed output:

transformed.png

How does it work?

The extension hooks into the output messages, makes a sequence of transformations described into a 'humanization.rules' file and puts the result into the additional output panes: "Build translated" for the build messages and "Debug translated" for the debug messages. The rules file can be placed in the solution directory, in any of its parent directory or in the user documents folder. There is an option to specify a custom solution-related path. Thus the rules can be set up per-project and kept in your version control.

The humanization.rules file syntax.

The file consists of 4 sections: [Build Transforms], [Build Filters], [Debug Transforms] and [Debug Filters].

The [Build Transforms] section defines the rules which are being applied during a build. The syntax of the rule is 'source part TO transformed part'. Where ' TO ' is a mandatory delimiter.

Examples:

std::basic_string<char,std::char_traits<char>,std::allocator<char>> TO string
Foo<int> TO MyType

The text of source and transformed parts are trimmed, but #SPACE keyword may be used to add leading or trailing whitespaces.

Example:

Bar<int>#SPACE#SPACE TO AnotherType

Some text can be completely removed by using an #EMPTY keyword at right part of the rule.

__stdcall#SPACE TO #EMPTY

The previous example allows removing the noise from linker messages. For example unresolved external symbol "void __cdecl foo(void)" (?foo@@YAXXZ) can be transformed into unresolved external symbol "void foo()" There is an option to remove mangled C++ names also.

The rule can use a regular expression in the source part, a leading #REGEX keyword should be added to the rule.

Example:

#REGEX source_part TO transformed_part
#REGEX ,std::allocator<.*> TO #EMPTY

The [Build Filters] section defines the rules to suppress some messages during a build. It contains a list of strings. If an output message contains any of these strings, the message will be suppressed. Can be used to suppress annoying spam from 3rd party code, if you are not able to fix them.

The [Debug Filters] section defines the rules to suppress some messages during a debug session. It uses the same syntax as [Build Filters] Can be used to suppress spam from the 3rd party code or DLLs. ‘dwmapi.dll’ for example.

The [Debug Transforms] section defines the rules which are being applied during a debug session. It uses the same syntax as [Build Transforms]

Any line can be commented by adding either leading ';' character, or by "//" characters.

The path to used rules file is shown in the output panes and can be opened by double click on that line.

The example of a file.

[Debug Filters]
dwmapi                          // Prevent Spam from microsoft dll
;has exited with code           // Spam from system threads, althoug it can be also switch off in the Tools -> Options... -> Debugging -> Output Window


[Debug Transform]

[Build Filters]
;image may not run              // Spam from linking with the 3rd party libs
;PDB '' was not found with      // Spam from linking with the 3rd party libs
;NODEFAULTLIB        ​           // Spam from linking with the 3rd party libs

[Build Transforms]
std::basic_string<char,std::char_traits<char>,std::allocator<char>> TO string  // STD Example
__cdecl#SPACE   TO #EMPTY       // Linker "noise"
__stdcall#SPACE TO #EMPTY       // Linker "noise"
(void)          TO ()           // Linker "noise"
unsinged int    TO uint32_t     // Typedef restore
int             TO int32_t      // Typedef restore

The options.

The options of extension can be found in Tools -> Options -> VSOutputHumanizator

humanizator_options__1.png

The drawbacks.

The extension doesn't have any information about the source code and just follows the rules. If your code base uses a few typedefs for the same type like uint32, uint32_t, u32, UINT32, etc..., the translated string might not correspond to the source code. For example, a function defined in the source code like foo(uint32 val) might be translated to foo(u32 val)

The activation of the translated build pane could race with the activation of the regular build pane. The best option is to activate on the first translation or on the end of build. Or try to switch off the option: Tools -> Options... -> Projects and Solutions -> Show Output window when build starts.

Misc

The text in the new output panes can be colorized by any other extension you like. Although there is an options to colorize file paths.

Known issues

The file path color isn't changed without restart of the Visual Studio.

  • Contact us
  • Jobs
  • Privacy
  • Terms of use
  • Trademarks
© 2023 Microsoft