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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017