Prevent user code from referring to internal module names #19793
Comments
|
There is a bit of an issue with the automatic use of ChapelStandard but I think we can make a special case for that. |
|
I wonder whether that could be finessed by having the compiler-injected |
bradcray
added a commit
that referenced
this issue
May 13, 2022
…le-ref Fix failing test fallout from #19788 [trivial, not reviewed] This test is only run on linux32, so escaped my testing and refers to an internal module, which is no longer available by default. Here, I'm using an explicit `use` to bring the module's name into scope, though this will also break if/when we implement the proposal in #19793.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
PR #19788 changes things to prevent internal module names from being automatically available in user code by relying on the new
public usebehavior introduced in #19306 which is good as internal module names are not meant to be user facing, so havingChapelBasebe automatically available is a bit odd. However, it does not prevent user code from writinguse ChapelBase;/import ChapelBase;(or similarly for other internal modules). In this issue, I'm proposing that we only resolve internal module names for other internal modules, not for user/package/standard modules.The text was updated successfully, but these errors were encountered: