Skip to content

Long typenames produce extremely hard to read diagnostics and slow down compilation time #28167

@vittorioromeo

Description

@vittorioromeo
Bugzilla Link 27793
Version trunk
OS Windows NT

Extended Description

Long typenames, usually generated by heavy template metaprogramming code, result in errors that are extremely hard to read and parse. Furthermore, they slow down compilation time significantly.

Here's a benchmark and example from the boost::di project:
http://melpon.org/wandbox/permlink/7Fh0u2oaQbDmkNV0

The benchmark shows:

  • How unnecessarily long and hard-to-understand errors are.
  • How typename erasure techniques can improve compilation times (define TYPENAME_ERASURE to see compilation time improvements).

I've encountered this same issue in one of my projects (ECST) - errors were impossible to understand before GCC 6 was released. GCC 6's produced errors pinpoint the issue more accurately, but still produce an enormous amount of unnecessary output.

I think this is primarily a defect in error reporting. A flag to control long typename output would be desired and possibly necessary for projects that require the generation of long typenames.

I also think that having compilation times speed up when erasing typenames signals some sort of potential compilation optimization for long typenames.

P.S.: gcc has similar issues.

Links:
boost::di -> https://github.com/boost-experimental/di
ECST -> https://github.com/SuperV1234/ecst

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugzillaIssues migrated from bugzillaclang:frontendLanguage frontend issues, e.g. anything involving "Sema"

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions