-
-
Notifications
You must be signed in to change notification settings - Fork 746
Use more selective imports at module imports #5584
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
Conversation
|
Thanks for your pull request, @wilzbach! 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. |
0d54aa0 to
cad303d
Compare
|
😭 |
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.
LGTM. Are these changes the cause of the the ggplotd errors, or did the latest release just break it?
9fb9e63 to
c701e27
Compare
I haven't seen this particular ggplotd error on the project tester before, so it's most likely from this PR (I rebased to force a rerun to be sure though). |
|
Probably because some functions were relying on a combination of nested imports and module-level blanket ones, which changing to selective broke. |
And I foolishly assumed that this was fixed / deprecated, but it seems like it's not: module foo;
import c;
//import c : NotErase; // <- breaks build of module `bar`module bar;
unittest
{
import foo : Erase;
assert(Erase == 2);
}module c;
int Erase = 2;
int NotErase = 2; |
|
Wait, what? So the Did the fix for 314 make the problem its opposite? |
AFAICT yep :/
I think https://github.com/dlang/dmd/pull/5485/files simply didn't touch this. Even 2.062 treats |
|
|
Can you investigate this a bit more and add that info to the bug report, including that it's been around for a while? This seems like a fairly important import leak remaining, would be good to explore how large it is. Ironically, using selective imports at module scope, as you do in this PR, actually plugs the leak, but breaks code that unintentionally relies on leaking symbols. |
Yeah I tried to. My DMD foo is pretty low atm unfortunately. So I can only say that the leaked symbols are found in the local
It's pretty large. AFAICT all module-level imports, non-selective imports leak their symbols. import imports.test17630b; // works __falsely__ as public import
import imports.test17630b : Erase; // works __falsely__ as public importFunnily even |
|
It seems like the entire implementation of selective imports never took visibility into account properly. This is where having so few compiler devs' eyes on the frontend source of such a massive language is hurting D. |
Codecov Report
@@ Coverage Diff @@
## master #5584 +/- ##
=======================================
Coverage 89.56% 89.56%
=======================================
Files 119 119
Lines 78145 78145
=======================================
Hits 69991 69991
Misses 8154 8154
Continue to review full report at Codecov.
|
|
I plan to remove the current visibility deprecation for 2.077, would be a good timing for this change as well. Still need to check how many projects still haven't fixed their deprecations though. |
c701e27 to
2ed3410
Compare
sed -E 's!import (.*); // :!import \1 :!' -i **/*.d
2ed3410 to
97ab0c9
Compare
|
Likely just needs to be rebased and updated, would be good if you added Andrei's commented-out selective imports from #5948 too. |
joakim-noah
left a comment
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.
Oh, I guess you're waiting on the 1-year deprecation period for the selective import leak to pass before getting this in? Didn't think of that, guess this will have to wait.
| import std.functional : unaryFun, binaryFun; | ||
| import std.range.primitives; | ||
| import std.traits; | ||
| // FIXME |
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.
Can be removed?
| */ | ||
| module std.algorithm.iteration; | ||
|
|
||
| // FIXME |
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.
Same here.
|
|
||
| import std.range.primitives; | ||
| import std.traits : isArray, isBlitAssignable, isNarrowString, Unqual, isSomeChar; | ||
| // FIXME |
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.
ditto
| */ | ||
| module std.algorithm.searching; | ||
|
|
||
| // FIXME |
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.
I'll stop here, just remove all unneeded comments.
quickfur
left a comment
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.
FWIW, this is still a step forward, even if it's not perfect. I say we should just move ahead with this, and let future improvements come in their own time.
Yes and it hasn't even started yet, see e.g. dlang/dmd#6676 I will close this PR now to avoid other people bumping into it, but once the selective import leak has been deprecated, imports at Phobos can finally made selective. |
AFAICT selective imports have been fixed in 2.071.0 and now enough time has passed down the road.
FWIW I still hope that we get Dependency-Carrying Declarations (DIP1005) at some point and can completely get rid of these global imports and make Phobos entirely pay for what you need.