-
-
Notifications
You must be signed in to change notification settings - Fork 610
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
Simplify Module.read and its interaction with FileManager
#13828
Conversation
Geod24
commented
Mar 17, 2022
It is only used once and has redundant logic (e.g. initialization).
|
Thanks for your pull request, @Geod24! 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#13828" |
|
compilable\issue17167.sh seems to fail everywhere on Azure |
|
Yep, legit failure, looking into it. |
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.
Check headers, modules.h, file.h, etc. For declarations that should be removed.
|
@ibuclaw : |
e1a520a to
853c8d8
Compare
While attempting to refactor Module.read not to call 'File.read' twice, test17167 started to fail. The only possible difference was that the first File.read call was conditional on FileName.exists succeeding, while the second call was inconditional. After a bit of research, it turns out that the fix for issue 17167 was apparently missing one key detail (the prefix) to enable long path. This was not visible at the time because the fix for File.read was complete, and so the second attempt would succeed, hiding the issue. This brings into question the correctness / need for toWStringzThen, as it's mostly used for long path, and is still being used in cannonicalName.
Since the FileManager will read a file if it exists on the filesystem, the else clause of Module.read was only ever called if File.read would fail. As a result, the code can be simplified, and loadSourceBuffer can be renamed to match its true purpose (printing a decent error message on missing file).
|
Found (and fixed) the bug |
|
To answer @ibuclaw more precisely: I could remove |
It could be a Just making sure that the C++ interface has been checked against for the removals here. |