www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Best error msg ever

reply Daniel Kozak <kozzi11 gmail.com> writes:
source/app.d(51,37): Error: function 
dub.internal.utils.jsonFromFile (Path file, bool silent_fail = 
false) is not callable using argument types (Path, bool)

WTF?
Feb 09
next sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 09.02.2017 um 22:20 schrieb Daniel Kozak:
 source/app.d(51,37): Error: function dub.internal.utils.jsonFromFile
 (Path file, bool silent_fail = false) is not callable using argument
 types (Path, bool)

 WTF?
Must be caused by Path meaning two different type definitions. The most likely cause is that by default the DUB sources use their own version of Path, while if vibe.d is available in the dependency graph, they will use the ones defined there instead. But the error message is indeed awful.
Feb 09
next sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 9.2.2017 v 22:28 Sönke Ludwig via Digitalmars-d napsal(a):

 Am 09.02.2017 um 22:20 schrieb Daniel Kozak:
 source/app.d(51,37): Error: function dub.internal.utils.jsonFromFile
 (Path file, bool silent_fail = false) is not callable using argument
 types (Path, bool)

 WTF?
Must be caused by Path meaning two different type definitions. The most likely cause is that by default the DUB sources use their own version of Path, while if vibe.d is available in the dependency graph, they will use the ones defined there instead. But the error message is indeed awful.
Yes, btw it is impossible to build https://github.com/dlang/dub-registry right now because of this
Feb 09
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 09.02.2017 um 22:44 schrieb Daniel Kozak via Digitalmars-d:
 Dne 9.2.2017 v 22:28 Sönke Ludwig via Digitalmars-d napsal(a):

 Am 09.02.2017 um 22:20 schrieb Daniel Kozak:
 source/app.d(51,37): Error: function dub.internal.utils.jsonFromFile
 (Path file, bool silent_fail = false) is not callable using argument
 types (Path, bool)

 WTF?
Must be caused by Path meaning two different type definitions. The most likely cause is that by default the DUB sources use their own version of Path, while if vibe.d is available in the dependency graph, they will use the ones defined there instead. But the error message is indeed awful.
Yes, btw it is impossible to build https://github.com/dlang/dub-registry right now because of this
Thanks for the notice, I've committed a fix for DUB 1.2.1
Feb 10
prev sibling parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Thursday, 9 February 2017 at 21:28:58 UTC, Sönke Ludwig wrote:
 Am 09.02.2017 um 22:20 schrieb Daniel Kozak:
 source/app.d(51,37): Error: function 
 dub.internal.utils.jsonFromFile (Path file, bool silent_fail = 
 false) is not callable using argument types (Path, bool)

 WTF?
Must be caused by Path meaning two different type definitions.
I'll have to agree. Back in ... 2009? I was in a company where we were doing web development for a bit, and one curious error that came up was when trying to assign or work with the Date object. Seems the built in Date class wasn't the same as the Sql.Date that was being used (but had the same name). Apparently it took like 2 hours to figure out what was going on. In cases like these i really wish the structure of the class/struct had a hash or something (based on source or struct layout or something) to help differentiate it rather than just by name, and reverse lookup the exact file location(s) of where the struct in question comes from.
Feb 09
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 10 February 2017 at 02:53:50 UTC, Era Scarecrow
  In cases like these i really wish the structure of the 
 class/struct had a hash or something (based on source or struct 
 layout or something)
They do have different full names, which includes the module name and uniquely differentiates them. The compiler knows it too, just isn't smart enough to actually display it in times like this.
Feb 09
next sibling parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Friday, 10 February 2017 at 03:07:28 UTC, Adam D. Ruppe wrote:
 They do have different full names, which includes the module 
 name and uniquely differentiates them. The compiler knows it 
 too, just isn't smart enough to actually display it in times 
 like this.
So maybe when the class name along can be ambiguous program it to give a full or non-ambiguous path for which class/structs they actually are? Seems like it would be a 1-2 line change...
Feb 09
prev sibling parent Profile Anaysis <PA gotacha.com> writes:
On Friday, 10 February 2017 at 03:07:28 UTC, Adam D. Ruppe wrote:
 On Friday, 10 February 2017 at 02:53:50 UTC, Era Scarecrow
  In cases like these i really wish the structure of the 
 class/struct had a hash or something (based on source or 
 struct layout or something)
They do have different full names, which includes the module name and uniquely differentiates them. The compiler knows it too, just isn't smart enough to actually display it in times like this.
The compiler actually has no brains, it's the people that program the compiler that you have to look at. Either they have no brains or are too lazy to care. After all, it's not their time that gets wasted.
Feb 11
prev sibling parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Friday, 10 February 2017 at 02:53:50 UTC, Era Scarecrow wrote:
 Seems the built in Date class wasn't the same as the Sql.Date 
 that was being used (but had the same name). Apparently it took 
 like 2 hours to figure out what was going on.
Oh right forgot to mention one important detail. In Java the program compiled without errors; It was when it was trying to be used that it would crash unexpectedly. Refusing to compile is slightly better than crashing unexpectedly later.
Feb 09
parent reply Nemanja Boric <4burgos gmail.com> writes:
On Friday, 10 February 2017 at 04:02:17 UTC, Era Scarecrow wrote:
 On Friday, 10 February 2017 at 02:53:50 UTC, Era Scarecrow 
 wrote:
 Seems the built in Date class wasn't the same as the Sql.Date 
 that was being used (but had the same name). Apparently it 
 took like 2 hours to figure out what was going on.
Oh right forgot to mention one important detail. In Java the program compiled without errors; It was when it was trying to be used that it would crash unexpectedly. Refusing to compile is slightly better than crashing unexpectedly later.
I saw it happen with D as well: everything compiles, everything is fine, and suddenly segfault. The issue was caused by template argument, two modules with the same name, but from different packages (think `myalib.blah.morebla.foo` and `myblib.blah.morebla.foo`) and a cast somewhere in the middle of the callstack which casted the first template argument to the second one, where the `myalib`'s foo was casted to `myblib`'s interface. Worse of all, `myalib` and `myblib` were just mentioned in the imports, far away from the call site.
Feb 10
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/10/2017 4:41 AM, Nemanja Boric wrote:
 I saw it happen with D as well: everything compiles, everything is
 fine, and suddenly segfault. The issue was caused by template argument, two
 modules with the same name, but from different packages (think
 `myalib.blah.morebla.foo` and `myblib.blah.morebla.foo`) and a cast
 somewhere in the middle of the callstack which casted the first template
 argument to the second one, where the `myalib`'s foo was casted to `myblib`'s
 interface.
That's why such casts are not allowed in safe code.
Feb 10
parent reply Chris Wright <dhasenan gmail.com> writes:
On Fri, 10 Feb 2017 12:32:19 -0800, Walter Bright wrote:

 On 2/10/2017 4:41 AM, Nemanja Boric wrote:
 I saw it happen with D as well: everything compiles, everything is
 fine, and suddenly segfault. The issue was caused by template argument,
 two modules with the same name, but from different packages (think
 `myalib.blah.morebla.foo` and `myblib.blah.morebla.foo`) and a cast
 somewhere in the middle of the callstack which casted the first
 template argument to the second one, where the `myalib`'s foo was
 casted to `myblib`'s interface.
That's why such casts are not allowed in safe code.
I'm a bit surprised by that. In system code, you can cast, and it results in a null pointer. A well-known value. Just like using an uninitialized variable. And safe doesn't stop you from using uninitialized variables.
Feb 10
next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
On Saturday, 11 February 2017 at 01:14:03 UTC, Chris Wright wrote:
 And  safe doesn't stop you from using uninitialized variables.
Yes it does, for pointers anyway void main() safe { int[] a = void; } /d296/f663.d(3): Error: variable f663.main.a void initializers for pointers not allowed in safe functions
Feb 10
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/10/2017 5:14 PM, Chris Wright wrote:
 On Fri, 10 Feb 2017 12:32:19 -0800, Walter Bright wrote:

 On 2/10/2017 4:41 AM, Nemanja Boric wrote:
 I saw it happen with D as well: everything compiles, everything is
 fine, and suddenly segfault. The issue was caused by template argument,
 two modules with the same name, but from different packages (think
 `myalib.blah.morebla.foo` and `myblib.blah.morebla.foo`) and a cast
 somewhere in the middle of the callstack which casted the first
 template argument to the second one, where the `myalib`'s foo was
 casted to `myblib`'s interface.
That's why such casts are not allowed in safe code.
I'm a bit surprised by that. In system code, you can cast, and it results in a null pointer. A well-known value.
It depends on just what is being cast. If you're casting an interface to an Object, it is not allowed in safe code because not all interfaces are Objects, and this is not reliably detectable at runtime.
 And  safe doesn't stop you from using uninitialized variables.
As shown, it does.
Feb 10
next sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Fri, 10 Feb 2017 21:19:37 -0800, Walter Bright wrote:
 On 2/10/2017 5:14 PM, Chris Wright wrote:
 And  safe doesn't stop you from using uninitialized variables.
As shown, it does.
Default-initialized variables, sorry. I don't see what's less safe about cast(MyInterface)new Object than cast(MyInterface)null The only difference is that there is a runtime call in between in the first example. And we'll get a similar runtime call with similar guarentees if it's instead cast(MyClass)new Object Except this version is accepted in safe code. It seems inconsistent, and I'm wondering what the reasoning behind it is. The error message doesn't offer a way to reach an explanation.
Feb 10
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/10/2017 9:42 PM, Chris Wright wrote:
 On Fri, 10 Feb 2017 21:19:37 -0800, Walter Bright wrote:
 On 2/10/2017 5:14 PM, Chris Wright wrote:
 And  safe doesn't stop you from using uninitialized variables.
As shown, it does.
Default-initialized variables, sorry. I don't see what's less safe about cast(MyInterface)new Object
It's the other way around that's unsafe - casting an interface to an Object.
Feb 11
prev sibling parent reply Kagamin <spam here.lot> writes:
On Saturday, 11 February 2017 at 05:19:37 UTC, Walter Bright 
wrote:
 not all interfaces are Objects
Do you have an example? How it can be? Only classes can implement interfaces, and classes inherit from Object.
Feb 13
next sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 13.2.2017 v 14:12 Kagamin via Digitalmars-d napsal(a):

 On Saturday, 11 February 2017 at 05:19:37 UTC, Walter Bright wrote:
 not all interfaces are Objects
Do you have an example? How it can be? Only classes can implement interfaces, and classes inherit from Object.
Not all classes, extern(C++) classes does not
Feb 13
parent Kagamin <spam here.lot> writes:
On Monday, 13 February 2017 at 13:18:33 UTC, Daniel Kozak wrote:
 Not all classes, extern(C++) classes does not
C++ only has C++ interfaces and they are different from D interfaces.
Feb 13
prev sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 13.2.2017 v 14:12 Kagamin via Digitalmars-d napsal(a):

 On Saturday, 11 February 2017 at 05:19:37 UTC, Walter Bright wrote:
 not all interfaces are Objects
Do you have an example? How it can be? Only classes can implement interfaces, and classes inherit from Object.
and I guess even ComObject does not inherit from Object
Feb 13
parent reply Kagamin <spam here.lot> writes:
On Monday, 13 February 2017 at 13:21:44 UTC, Daniel Kozak wrote:
 and I guess even ComObject does not inherit from Object
This compiles: void f() { import core.sys.windows.com; ComObject a; Object b=a; }
Feb 13
parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 13 February 2017 at 13:38:23 UTC, Kagamin wrote:
 On Monday, 13 February 2017 at 13:21:44 UTC, Daniel Kozak wrote:
 and I guess even ComObject does not inherit from Object
This compiles: void f() { import core.sys.windows.com; ComObject a; Object b=a; }
"References cannot be upcast to the enclosing class object, nor can they be downcast to a derived interface." https://dlang.org/spec/interface.html#com-interfaces
Feb 13
parent reply Kagamin <spam here.lot> writes:
On Monday, 13 February 2017 at 14:46:38 UTC, Mike Parker wrote:
 "References cannot be upcast to the enclosing class object, nor 
 can they be downcast to a derived interface."

 https://dlang.org/spec/interface.html#com-interfaces
COM interfaces can't be downcasted indeed, but it should be possible for D interfaces.
Feb 13
parent Chris Wright <dhasenan gmail.com> writes:
On Mon, 13 Feb 2017 15:09:31 +0000, Kagamin wrote:

 On Monday, 13 February 2017 at 14:46:38 UTC, Mike Parker wrote:
 "References cannot be upcast to the enclosing class object, nor can
 they be downcast to a derived interface."

 https://dlang.org/spec/interface.html#com-interfaces
COM interfaces can't be downcasted indeed, but it should be possible for D interfaces.
But the case that I brought up was cross-casting. I have an object. It's a D object, which the compiler knows. I don't know if it implements a specific interface, so I cast it. That gives me an expression of the interface type that either refers to the same object or is null. Except it isn't safe for some unknown reason.
Feb 13
prev sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 9.2.2017 v 22:20 Daniel Kozak via Digitalmars-d napsal(a):

 source/app.d(51,37): Error: function dub.internal.utils.jsonFromFile 
 (Path file, bool silent_fail = false) is not callable using argument 
 types (Path, bool)

 WTF?
Problem is with multiple Path declaration, but with this error message it is really hard to find out which one. Maybe it would be better to show full names of symbol
Feb 09
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 9 February 2017 at 21:31:48 UTC, Daniel Kozak wrote:
 Dne 9.2.2017 v 22:20 Daniel Kozak via Digitalmars-d napsal(a):

 source/app.d(51,37): Error: function 
 dub.internal.utils.jsonFromFile (Path file, bool silent_fail = 
 false) is not callable using argument types (Path, bool)

 WTF?
Problem is with multiple Path declaration, but with this error message it is really hard to find out which one. Maybe it would be better to show full names of symbol
please do submit an request for this,
Feb 09
parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 9.2.2017 v 22:36 Stefan Koch via Digitalmars-d napsal(a):

 On Thursday, 9 February 2017 at 21:31:48 UTC, Daniel Kozak wrote:
 Dne 9.2.2017 v 22:20 Daniel Kozak via Digitalmars-d napsal(a):

 source/app.d(51,37): Error: function dub.internal.utils.jsonFromFile 
 (Path file, bool silent_fail = false) is not callable using argument 
 types (Path, bool)

 WTF?
Problem is with multiple Path declaration, but with this error message it is really hard to find out which one. Maybe it would be better to show full names of symbol
please do submit an request for this,
It would be probably duplicate of this one https://issues.dlang.org/show_bug.cgi?id=9631
Feb 09