Bug 71167 - Long typenames produce extremely hard to read diagnostics and slow down compilation time
Summary: Long typenames produce extremely hard to read diagnostics and slow down compi...
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 6.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2016-05-17 19:14 UTC by Vittorio Romeo
Modified: 2023-10-31 00:18 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vittorio Romeo 2016-05-17 19:14:15 UTC
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.: clang has similar issues.

Links:
boost::di -> https://github.com/boost-experimental/di
ECST -> https://github.com/SuperV1234/ecst
Comment 1 Drea Pinski 2016-07-04 07:03:32 UTC
Most likely a dup of bug 17693.
Comment 2 Eric Gallager 2018-03-16 23:04:13 UTC
(In reply to Andrew Pinski from comment #1)
> Most likely a dup of bug 17693.

I'll just put it under "See Also" until there's more certainty that this is a dup of it