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
The regular output:
The transformed output:
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.
The text of source and transformed parts are trimmed, but #SPACE keyword may be used to add leading or trailing whitespaces.
Some text can be completely removed by using an #EMPTY keyword at right part of the rule.
The previous example allows removing the noise from linker messages.
The rule can use a regular expression in the source part, a leading #REGEX keyword should be added to the rule.
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.
The options of extension can be found in Tools -> Options -> VSOutputHumanizator
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
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:
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.
The file path color isn't changed without restart of the Visual Studio.