-
-
Notifications
You must be signed in to change notification settings - Fork 609
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix issue 20810: Freshly built DMD fails to read config file #11111
Conversation
|
Thanks for your pull request, @AndrejMitrovic! Bugzilla references
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#11111" |
src/dmd/root/filename.d
Outdated
| @@ -1005,10 +1005,13 @@ nothrow: | |||
| auto fullPath = (cast(wchar*) mem.xmalloc_noscan((fullPathLength + 1) * wchar.sizeof))[0 .. fullPathLength + 1]; | |||
| scope(exit) mem.xfree(fullPath.ptr); | |||
|
|
|||
| import core.stdc.stdio; | |||
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
d4cbadd to
f5c37cc
Compare
|
Needs a test tho |
|
I'll see if I can add a test-case. It's coming from the call to |
|
I added a test, but I haven't been able to unittest on Windows locally yet. There's some issue with the I'll try and sort this out soon. |
See #11112 |
|
It looks like the test-suite fails with the change. So it's not the appropriate fix. I wonder if the bug is related to any recent Windows updates as I'm running v1909. But the only changes that are mentioned are for version 1607 in https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfullpathnamew. |
test/dshell/test20810.d
Outdated
|
|
||
| int main() | ||
| { | ||
| run("$DMD"); // should print usage and exit with 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dmd without arguments returns exit code 1...
| run("$DMD"); // should print usage and exit with 0 | |
| run("$DMD --help"); // should print usage and exit with 0 |
|
You could also try a EDIT: I would rather add the |
I've just refactored this and misread the docs, that's why. And canonicalName() is either unused during the whole testsuite, or no tested DMD built with enabled assertions. Anyway, I think a little unittest would be the best way to test this. |
a9857d7 to
5c1b8c9
Compare
According to MSDN docs, the return value of GetFullPathName does *not* count the terminating null character. In the first call, it *does* include this count because a buffer was not specified in that initial call. Fix Issue 20810
5c1b8c9 to
77ae162
Compare
|
I thought And actually, I don't think this compilable test-case is correct. Because it's not testing the call properly. The |
It does, the problem lies in the platform specific options (and a whitespace error due to markdown).
Actually, you're right because the test runner invokes dmd with Sorry for the distraction. |
|
Alright, I'll fix it up later.
Not at all. Thanks for help from both of you! |
| @@ -0,0 +1,126 @@ | |||
| /* | |||
| REQUIRED_ARGS: --help | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't use --help but pass a simple module containing an empty main func. The use of --help is, in addition of not testing the right thing, something that would have to be maintained over years.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't use
--helpbut pass a simple module containing an empty main func. The use of--helpis, in addition of not testing the right thing.
Not an ideal test but running dmd --help triggers that bug.
something that would have to be maintained over years.
Only the current version, I'll re-enable a maintenance free version after this PR is merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A brittle integration test for this is overkill; a trivial little unittest would do the job perfectly, just like
Lines 363 to 370 in 77ae162
| unittest | |
| { | |
| version (Windows) | |
| assert(combine("foo"[], "bar"[]) == "foo\\bar"); | |
| else | |
| assert(combine("foo"[], "bar"[]) == "foo/bar"); | |
| assert(combine("foo/"[], "bar"[]) == "foo/bar"); | |
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, a unittest is the best solution here.
|
Any updates @AndrejMitrovic ? |
|
Well it seems that master works with your test, so it looks like the issue might be somewhere else? |
|
it fails with current master, the PR was accidentally merged by dlang-bot and got reverted. |
|
I'll close this since I can't reproduce it anymore, sorry. |
The assertion was wrong and guaranteed to fail when enabled (my bad). This is a reboot of dlang#11111. Also make sure to return a new root.rmem-managed memory allocation in all cases, i.e., not the malloc'd memory directly for the canonicalize_file_name version. E.g., the memory is released via mem.xfree() in FileName.safeSearchPath().
The assertion was wrong and guaranteed to fail when enabled (my bad). This is a reboot of dlang#11111. Also make sure to return a new root.rmem-managed memory allocation in all cases, i.e., not the malloc'd memory directly for the canonicalize_file_name version. E.g., the memory is released via mem.xfree() in FileName.safeSearchPath().
The assertion was wrong and guaranteed to fail when enabled (my bad). This is a reboot of dlang#11111. Also make sure to return a new root.rmem-managed memory allocation in all cases, i.e., not the malloc'd memory directly for the canonicalize_file_name version. E.g., the memory is released via mem.xfree() in FileName.safeSearchPath().
The assertion was wrong and guaranteed to fail when enabled (my bad). This is a reboot of dlang#11111. Also make sure to return a new root.rmem-managed memory allocation in all cases, i.e., not the malloc'd memory directly for the canonicalize_file_name version. E.g., the memory is released via mem.xfree() in FileName.safeSearchPath().
According to MSDN docs the return value of GetFullPathName does not count the terminating null character on a successful call.
See here: https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfullpathnamew
I'm not sure how this was never caught before though. But on my Win10 machine
masterfails.Fixes https://issues.dlang.org/show_bug.cgi?id=20810