digitalmars.D - dmd: why not use fully qualified names for types in error messages?
- Timothee Cour via Digitalmars-d (6/6) Jun 13 2017 eg:
- Jacob Carlborg (6/14) Jun 13 2017 Technically, for templates, the fully qualified name include all the
- Nicholas Wilson (8/21) Jun 14 2017 Perhaps some simple heuristic of length (> 80 chars?) would
- Daniel Kozak via Digitalmars-d (5/30) Jun 14 2017 http://forum.dlang.org/post/fyzwknqumopldiktiuvj@forum.dlang.org
- Jonathan M Davis via Digitalmars-d (13/25) Jun 14 2017 It's also frequently something that you wouldn't want to read even if it
eg: Error: no property 'IF_gray' for type 'ImageFormat' => Error: no property 'IF_gray' for type 'foo.bar.ImageFormat' and also, why not show where the symbol is defined? would PR's for that be accepted? is that hard to implement?
Jun 13 2017
On 2017-06-14 06:50, Timothee Cour via Digitalmars-d wrote:eg: Error: no property 'IF_gray' for type 'ImageFormat' => Error: no property 'IF_gray' for type 'foo.bar.ImageFormat' and also, why not show where the symbol is defined? would PR's for that be accepted? is that hard to implement?Technically, for templates, the fully qualified name include all the template arguments. In many (some) cases this will be way too long to print. -- /Jacob Carlborg
Jun 13 2017
On Wednesday, 14 June 2017 at 06:33:26 UTC, Jacob Carlborg wrote:On 2017-06-14 06:50, Timothee Cour via Digitalmars-d wrote:Perhaps some simple heuristic of length (> 80 chars?) would suffice? Or perhaps Error: no property 'IF_gray' for type 'ImageFormat' from module 'foo.bar'. One of the most confusing errors to get iseg: Error: no property 'IF_gray' for type 'ImageFormat' => Error: no property 'IF_gray' for type 'foo.bar.ImageFormat' and also, why not show where the symbol is defined? would PR's for that be accepted? is that hard to implement?Technically, for templates, the fully qualified name include all the template arguments. In many (some) cases this will be way too long to print.Error: no property 'IF_gray' for type 'ImageFormat'when 'ImageFormat ' does have that property but it uses a different 'ImageFormat' (in another module) that doesn't.
Jun 14 2017
http://forum.dlang.org/post/fyzwknqumopldiktiuvj forum.dlang.org http://forum.dlang.org/post/xpmpakmusudanwuzzezl forum.dlang.org https://issues.dlang.org/show_bug.cgi?id=9631 On Wed, Jun 14, 2017 at 10:21 AM, Nicholas Wilson via Digitalmars-d < digitalmars-d puremagic.com> wrote:On Wednesday, 14 June 2017 at 06:33:26 UTC, Jacob Carlborg wrote:On 2017-06-14 06:50, Timothee Cour via Digitalmars-d wrote:Perhaps some simple heuristic of length (> 80 chars?) would suffice? Or perhaps Error: no property 'IF_gray' for type 'ImageFormat' from module 'foo.bar'. One of the most confusing errors to get iseg: Error: no property 'IF_gray' for type 'ImageFormat' => Error: no property 'IF_gray' for type 'foo.bar.ImageFormat' and also, why not show where the symbol is defined? would PR's for that be accepted? is that hard to implement?Technically, for templates, the fully qualified name include all the template arguments. In many (some) cases this will be way too long to print.Error: no property 'IF_gray' for type 'ImageFormat'when 'ImageFormat ' does have that property but it uses a different 'ImageFormat' (in another module) that doesn't.
Jun 14 2017
On Wednesday, June 14, 2017 08:33:26 Jacob Carlborg via Digitalmars-d wrote:On 2017-06-14 06:50, Timothee Cour via Digitalmars-d wrote:It's also frequently something that you wouldn't want to read even if it were shorter. And having the fully qualified names in the error messages would tend to make them harder to read in many cases when you're not dealing with nasty, long templates. Likely, the best solution is for the compiler to do what it does now in the typical case but to be more specific when needed for clarity (e.g. when dealing with multiple types with the same name or with overloads). But the examples that we sometimes get now where the same name is listed multiple times, and it's actually different symbols from different modules with the same name are definitely the sort of thing that indicates that we need to improve how we handle qualifying names in error messages. - Jonathan M Daviseg: Error: no property 'IF_gray' for type 'ImageFormat' => Error: no property 'IF_gray' for type 'foo.bar.ImageFormat' and also, why not show where the symbol is defined? would PR's for that be accepted? is that hard to implement?Technically, for templates, the fully qualified name include all the template arguments. In many (some) cases this will be way too long to print.
Jun 14 2017