1675 – "Identifier too long" error with OMF object files

If there were an "OPTLINK" component, I would have filed this under it.
When dealing with complex template tuples, it's very easy to overflow the maximum symbol length allowed by OPTLINK. This is, simply put, a damn shame, because it prevents otherwise completely legal code from compiling and linking with DMDWin, whereas it works perfectly fine when using DMDNix or GDC. 
I know that this is neither a simple nor a small issue to fix: either the ancient, nearly-immutable OPTLINK would have to be modified, or DMDWin would have to be changed to output a more reasonable format, in which case a new linker would probably have to be written. Until then, this issue should stand as a reminder that DMDWin is inherently limited.

Oplink isn't the issue. The OMF file format has a hard limit. This results in the only solutions being: convert DMD to use some other .obj format or have DMD do something else for name mangling.
In talking to Walter, the issue is that it's easy to get symbols that have more info in them than can be fit into the limit. (the limit has already stretched by gziping the symbols.)
The "simple solution" I have proposed is to just MD5 (or what not) the symbols. The only issue (besides a vanishingly small chance of a hash collision) is that this looses information so you can't look at a symbol and directly determine what it was. My answer to that is, who cares? The only place where hashing provides less info than compressing is in a debugger and it can grab the full symbol from a table in the static data segment.

(In reply to comment #1)
> Oplink isn't the issue. The OMF file format has a hard limit. This results in
> the only solutions being: convert DMD to use some other .obj format or have DMD
> do something else for name mangling.
> 
> In talking to Walter, the issue is that it's easy to get symbols that have more
> info in them than can be fit into the limit. (the limit has already stretched
> by gziping the symbols.)
> 
> The "simple solution" I have proposed is to just MD5 (or what not) the symbols.
> The only issue (besides a vanishingly small chance of a hash collision) is that
> this looses information so you can't look at a symbol and directly determine
> what it was. My answer to that is, who cares? The only place where hashing
> provides less info than compressing is in a debugger and it can grab the full
> symbol from a table in the static data segment.
> 
I suppose as a stopgap measure that'd work fine, and might even be controlled by a compiler switch, so that in the general case debugger info wouldn't be affected. And what's more -- the only time these issues come up is with templates, which a lot of debuggers have serious problems with anyway, so..

I would set it up as a method of last resort. It wouldn't be used unless the symbol can't be used any other way.

Fixed dmd 1.031 and 2.015