Now that the -op switch is in I've been using modules with the same final name (I have a.b and b.b, for example) in different parts of the library.  However, calls to _d_assert are still being given just the final name of the module, making it impossible for me to tell what failed as I receive an error message along the lines of:

Error: AssertError Failure b(37)

Burton Radons schrieb:

> Now that the -op switch is in I've been using modules with the same final name (I have a.b and b.b, for example) in different parts of the library.  However, calls to _d_assert are still being given just the final name of the module, making it impossible for me to tell what failed as I receive an error message along the lines of:
> 
> Error: AssertError Failure b(37)

Can you please post the files you are compiling and the complete compiler arguments?

Thomas

Thomas Kühne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Burton Radons schrieb:
> 
> 
>>Now that the -op switch is in I've been using modules with the same
>>final name (I have a.b and b.b, for example) in different parts of the
>>library.  However, calls to _d_assert are still being given just the
>>final name of the module, making it impossible for me to tell what
>>failed as I receive an error message along the lines of:
>>
>>Error: AssertError Failure b(37)
> 
> 
> Can you please post the files you are compiling and the complete
> compiler arguments?

How odd, I can't get it to occur in a test case (it produces the full filename), while the project this came from always produces the substring ("foo" instead of "bar/foo.d").  So it's caused by some sort of interaction with the source.

I can't winnow it down to a testcase because that would mean literally removing line by line.  Walter will just have to find out what's going wrong in the backend where the assert function is created.

Burton Radons schrieb:
> I can't winnow it down to a testcase because that would mean literally removing line by line.  Walter will just have to find out what's going wrong in the backend where the assert function is created.

Let's open the box and pull out some tools:

[1]

1) you have a/b.d (A) and b/b.d (B)
2) count the total number of lines in A
3) add as many empty lines at the beginning of B as you counted
4) recompile and locate the problem
(hint: line numbers with source code are now unique across A and B)

[2 a]

1) load your project into a debugger
2) set a break for "_d_assert" / "std/asserterror.d:53"
3) run and analyze the back trace

[2 b]

1) open std/asserterror.d
2) add the code below to _d_assert

*(cast(char*)0) = "crash";

3) recompile Phobos
4) recompile your project
5) run your project inside a debugger and analyze the back trace

Thomas

Found it.  It happens when it needs to generate a ModuleInfo, which is caused by a static constructor (amongst other things).  The problem is in Module::toEfilename (part of the backend); the first branch should be cut out or it should generate an FQN for the ModuleInfo.

Burton Radons schrieb:
> Found it.  It happens when it needs to generate a ModuleInfo, which is caused by a static constructor (amongst other things).  The problem is in Module::toEfilename (part of the backend); the first branch should be cut out or it should generate an FQN for the ModuleInfo.

Extended
http://dstress.kuehne.cn/norun/assert_04.d
http://dstress.kuehne.cn/norun/assert_05.d

Thomas