add eSink to library file generation #15505
Conversation
|
Thanks for your pull request, @WalterBright! Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub run digger -- build "master + dmd#15505" |
WalterBright
force-pushed
the
libFactory
branch
5 times, most recently
from
7d89013
to
af7136a
Compare
| @@ -9,7 +10,7 @@ Use a regex because the path is really strange on Azure (OMF_32, 64): | |||
|
|
|||
| TEST_OUTPUT: | |||
| ---- | |||
| $r:.*$: Error: corrupt $?:windows=MS Coff|osx=Mach|ELF$ object module $?:windows=fail_compilation\extra-files\fake.lib|fail_compilation/extra-files/fake.a$ $n$ | |||
| Error: corrupt ELF object module fail_compilation/extra-files/fake.a 112 | |||
There was a problem hiding this comment.
If this PR is a refactor, why is the test changed? Did the behavior change?
There was a problem hiding this comment.
I did not understand the test case. There are no comments in it.
There was a problem hiding this comment.
It's testing that linking with a corrupt library generates the correct message, which depends on the platform. Now there is no test for Mac or Windows anymore. Can't you leave it as it is?
There was a problem hiding this comment.
It failed as is, saying it got the green message instead of the red one.
There was a problem hiding this comment.
I see, it's because you now pass Loc.initial to the error functions instead of this.loc. Please add the correct location back, that's useful information.
WalterBright
force-pushed
the
libFactory
branch
4 times, most recently
from
e4f8bb0
to
7c32b41
Compare
WalterBright
force-pushed
the
libFactory
branch
from
7c32b41
to
9459283
Compare
|
@dkorpel thanks for putting your finger on the actual problem. It's working now! |
Also: