Skip to content
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 21651 - Unimported package doesn't error out when used as p… #12215

Merged
merged 1 commit into from
Mar 8, 2021

Conversation

BorisCarvajal
Copy link
Member

…art of fully qualified type

There are a few instances of phobos relying on this bug.

@Geod24
Copy link
Member

Geod24 commented Feb 21, 2021

Is this the right fix ? To me it looks like a flaw in importAll, which makes symbol visible when they shouldn't.

@BorisCarvajal
Copy link
Member Author

BorisCarvajal commented Feb 21, 2021

From what I know Packages need to be check using checkAccess() as is done in expression.d, IIRC visibility doesn't take into account unless the package happens to be an import symbol, this is another peculiarity of dmd that should be addressed by maybe not inserting import symbols to the current scope.

@dlang-bot
Copy link
Contributor

Thanks for your pull request and interest in making D better, @BorisCarvajal! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

  • My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
  • My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
  • I have provided a detailed rationale explaining my changes
  • New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.


If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close Bugzilla Severity Description
21651 normal Unimported package doesn't error out when used as part of fully qualified type

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#12215"

@@ -33,6 +33,7 @@ import dmd.errors;
import dmd.expression;
import dmd.func;
import dmd.globals;
import dmd.glue;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a result of fixing the bug?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it's to fix a instance of the bug in DMD.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two lines a little below:

alias toSymbol = dmd.tocsym.toSymbol;
alias toSymbol = dmd.glue.toSymbol;

dmd.glue is not imported but is working because of the bug.

@RazvanN7
Copy link
Contributor

I kind of agree with @Geod24 . symbolIsVisible should definitely be false in this situation. Why would we require a different check?

@BorisCarvajal
Copy link
Member Author

I've tracked the necessity of this additional check to #5426

@BorisCarvajal
Copy link
Member Author

I agree that maybe checkAccess(Package) should be merged with symbolIsVisible, the former needs an Scope parameter to work, though.

@BorisCarvajal
Copy link
Member Author

I should've noted that the compiler already shows the error if the qualified name is encapsulated as an expression (DotIdExp) vs a type.

For example in the test test/fail_compilation/imports/test21651a.d

// both statements should be error
imports.test21651b.T a;
int b = imports.test21651b.x;   <-- currently prints "Error: undefined identifier `ice10598b` in package `imports`, perhaps add `static import imports.ice10598b;`"

// so the bug occurs mainly is the following cases:
imports.test21651b.T a;
alias a = imports.test21651b.T;
SomeTemplate!(imports.test21651b.T);

// anything else is already an error, like:
imports.test21651b.somefunction();
++imports.test21651b.variable;
auto v = imports.test21651b.x + imports.test21651b.x;

@RazvanN7, So there is nothing to deprecate.
And if imports had not been previously public by default I think the instances of code using this bug would be almost zero.

@RazvanN7
Copy link
Contributor

@RazvanN7, So there is nothing to deprecate.

The fact that we had to modify druntime and phobos to accomodate this change and we still have buildkite failing more than 10 projects is more than enough to warrant a deprecation.

@BorisCarvajal
Copy link
Member Author

That deprecation already happened 5 years ago -> #5426

@CyberShadow
Copy link
Member

That deprecation already happened 5 years ago -> #5426

How do I get the deprecation to show up for ae? I don't see it.

Are you sure that the deprecation you have in mind covers all the cases broken by this PR?

@Geod24
Copy link
Member

Geod24 commented Feb 25, 2021

That deprecation already happened 5 years ago -> #5426

It clearly didn't. Phobos and druntime compile with deprecations as errors, if there was a deprecation in place the code wouldn't have compiled and you wouldn't have had to fix them. So please make this a deprecation.

@BorisCarvajal
Copy link
Member Author

Sorry, what I meant was that the intent of #5426 was to deprecate using fully-qualified names to bypass imports.
This deprecation succeeded and now it's an error but unfortunately due to parser/semantic differences between types and expressions not all the cases were covered, for example:

import std.algorithm;

enum a = std.range.isForwardRange!string;  // Error.  Deprecation happened 5 years ago.

alias isFR = std.range.isForwardRange;   // Absurdly, this still works.
enum b = isFR!string;

Anyway, it seems adding a deprecation message is the way to go.

@BorisCarvajal
Copy link
Member Author

What should be the deprecation period or version to put inside the @@@DEPRECATED@@@ comment?

@RazvanN7
Copy link
Contributor

RazvanN7 commented Mar 3, 2021

@BorisCarvajal According to DIP1013 [1], the minimum required deprecation period is 10 non-patch releases. Since we have 6 releases per year [2], I guess that the minimum period is 20 months. I would round it up to 2 years just to have a well rounded number, but that is up to you.

[1] https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1013.md
[2] https://dlang.org/changelog/release-schedule.html

@BorisCarvajal BorisCarvajal force-pushed the fix21651 branch 2 times, most recently from 45f68d3 to 8243f10 Compare March 4, 2021 10:05
compilable/imports/ice10598a.d(5): Deprecation: module imports.ice10598b is not accessible here, perhaps add 'static import imports.ice10598b;'
compilable/imports/ice10598a.d(5): Deprecation: module imports.ice10598b is not accessible here, perhaps add 'static import imports.ice10598b;'
---
*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe move this to fail_compilation and add REQUIRED_ARGS: -de

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@@ -0,0 +1,5 @@
module imports.test21651a;

// both statements should be error
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The contents of this file should be moved to fail_compilation/test21651.d. That way we use only 2 files.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

/* TEST_OUTPUT:
---
fail_compilation/imports/test21651a.d(4): Deprecation: module imports.test21651b is not accessible here, perhaps add 'static import imports.test21651b;'
fail_compilation/imports/test21651a.d(5): Error: undefined identifier `test21651b` in package `imports`, perhaps add `static import imports.test21651b;`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This error is not necessary as it is covered already by other tests. Simply compile with -de and keep the minimum required lines of code to reproduce the code that this PR actually fixes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

// @@@DEPRECATED_2.096@@@
// Should be an error in 2.106. Just remove the deprecation call
// and uncomment the null assignment
deprecation(loc, "%s %s is not accessible here, perhaps add 'static import %s;'", sm.kind(), sm.toPrettyChars(), sm.toPrettyChars());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here does not sound very professional. I suggest replacing it with the module name.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, is the static really necessary?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the exact message of the original deprecation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough.

Copy link
Contributor

@RazvanN7 RazvanN7 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One last thing and we are good to go. This requires a changelog entry since it is deprecating behavior. I know that this is just a slipped case of a former deprecation, still, folks reading the changelog should be notified about it.

@BorisCarvajal BorisCarvajal force-pushed the fix21651 branch 3 times, most recently from dda8bf2 to aed8584 Compare March 4, 2021 15:11
@RazvanN7 RazvanN7 merged commit 7f866e2 into dlang:master Mar 8, 2021
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.

5 participants