Skip to content

Conversation

@wilzbach
Copy link
Contributor

@wilzbach wilzbach commented Jul 9, 2017

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.

@dlang-bot
Copy link
Contributor

Thanks for your pull request, @wilzbach!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

@wilzbach wilzbach force-pushed the selective-imports branch from 0d54aa0 to cad303d Compare July 9, 2017 11:41
@wilzbach
Copy link
Contributor Author

wilzbach commented Jul 9, 2017

😭

ggplotd 1.1.3: building configuration "ggplotd-test-default"...
source/ggplotd/colour.d(30,7): Deprecation: catch statement without an exception specification is deprecated; use catch(Throwable) for old behavior
source/ggplotd/stat.d(511,12): Error: module std.typecons import 'Erase' not found
source/ggplotd/geom.d(1044,25): Error: template instance ggplotd.stat.statDensity2D!(MapResult!(__lambda3, Zip!(MapResult!(__lambda1, Result), MapResult!(__lambda2, Result)))) error instantiating
source/ggplotd/example.d(120,9):        instantiated from here: geomDensity2D!(MapResult!(__lambda3, Zip!(MapResult!(__lambda1, Result), MapResult!(__lambda2, Result))))
source/ggplotd/stat.d(511,12): Error: module std.typecons import 'Erase' not found
source/ggplotd/geom.d(1044,25): Error: template instance ggplotd.stat.statDensity2D!(MapResult!(__lambda1, double[][])) error instantiating
source/ggplotd/example.d(234,21):        instantiated from here: geomDensity2D!(MapResult!(__lambda1, double[][]))
source/ggplotd/stat.d(511,12): Error: module std.typecons import 'Erase' not found
source/ggplotd/stat.d(603,28): Error: template instance ggplotd.stat.statDensity2D!(Aes!(double[], "x", double[], "y")) error instantiating
dmd failed with exit code 1.

Copy link
Member

@MetaLang MetaLang left a 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?

@wilzbach wilzbach force-pushed the selective-imports branch 2 times, most recently from 9fb9e63 to c701e27 Compare July 9, 2017 21:04
@wilzbach
Copy link
Contributor Author

wilzbach commented Jul 9, 2017

Are these changes the cause of the the ggplotd errors, or did the latest release just break it?

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).

@MetaLang
Copy link
Member

MetaLang commented Jul 9, 2017

Probably because some functions were relying on a combination of nested imports and module-level blanket ones, which changing to selective broke.

@wilzbach
Copy link
Contributor Author

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;

@JackStouffer
Copy link
Contributor

Wait, what? So the import c; is somehow acting as a public import?

Did the fix for 314 make the problem its opposite?

@wilzbach
Copy link
Contributor Author

Wait, what? So the import c; is somehow acting as a public import?

AFAICT yep :/

Did the fix for 314 make the problem its opposite?

I think https://github.com/dlang/dmd/pull/5485/files simply didn't touch this. Even 2.062 treats import c as a public import.

@wilzbach
Copy link
Contributor Author

Wait, what? So the import c; is somehow acting as a public import?
AFAICT yep :/

-> https://issues.dlang.org/show_bug.cgi?id=17630

@joakim-noah
Copy link
Contributor

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.

@wilzbach
Copy link
Contributor Author

Can you investigate this a bit more and add that info to the bug report, including that it's been around for a while?

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 symtab table.

This seems like a fairly important import leak remaining, would be good to explore how large it is.

It's pretty large. AFAICT all module-level imports, non-selective imports leak their symbols.
However, even selective imports leak their selected symbols:

import imports.test17630b; // works __falsely__ as public import
import imports.test17630b : Erase; // works __falsely__ as public import

Funnily even private import X; doesn't work.

@joakim-noah
Copy link
Contributor

joakim-noah commented Jul 13, 2017

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
Copy link

codecov bot commented Sep 3, 2017

Codecov Report

Merging #5584 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #5584   +/-   ##
=======================================
  Coverage   89.56%   89.56%           
=======================================
  Files         119      119           
  Lines       78145    78145           
=======================================
  Hits        69991    69991           
  Misses       8154     8154
Impacted Files Coverage Δ
std/typecons.d 88.92% <ø> (ø) ⬆️
std/algorithm/comparison.d 95.12% <ø> (ø) ⬆️
std/algorithm/sorting.d 98.18% <ø> (ø) ⬆️
std/regex/package.d 91.2% <ø> (ø) ⬆️
std/uni.d 91.71% <ø> (ø) ⬆️
std/net/isemail.d 83.86% <ø> (ø) ⬆️
std/math.d 93.29% <ø> (ø) ⬆️
std/string.d 99.71% <ø> (ø) ⬆️
std/stdio.d 79.41% <ø> (ø) ⬆️
std/algorithm/searching.d 96.79% <ø> (ø) ⬆️
... and 7 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e9ff980...c701e27. Read the comment docs.

@MartinNowak
Copy link
Member

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.

sed -E 's!import (.*); // :!import \1 :!' -i **/*.d
@joakim-noah
Copy link
Contributor

Likely just needs to be rebased and updated, would be good if you added Andrei's commented-out selective imports from #5948 too.

Copy link
Contributor

@joakim-noah joakim-noah left a 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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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.

Copy link
Member

@quickfur quickfur left a 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.

@wilzbach
Copy link
Contributor Author

wilzbach commented Feb 2, 2018

Oh, I guess you're waiting on the 1-year deprecation period for the selective import leak to pass before getting this in?

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.
Also as a note to reviewers: new top-level imports can and should always be selective - there's no need to increase the area of the symbol leakage (and it's also dangerous because we could introduce a new symbol leak during the deprecation period).

@wilzbach wilzbach closed this Feb 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants