Allow use macro imports to shadow global macros by jseyfried · Pull Request #40501 · rust-lang/rust (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation24 Commits2 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

jseyfried

Terminology:

Today, the legacy scope can shadow the global scope (modulo RFC 1560 expanded shadowing restrictions). However, the modern scope cannot shadow or be shadowed by either the global or legacy scopes, leading to ambiguity errors.

This PR allows the modern scope to shadow the global scope (subject to some restrictions).
More specifically, a name in the global scope is as shadowable as a glob import in the module self. In other words, we imagine a special, implicit glob import in each module item:

mod foo { #[lexical_only] // Not accessible via foo::<name>, like pre-RFC 1560 use imports. #[shadowable_by_legacy_scope] // for back-compat use ::*; }

r? @nrc

@jseyfried

@jseyfried jseyfried changed the titleAllow use macro imports to shadow built macors Allow use macro imports to shadow builtin macors

Mar 14, 2017

@jseyfried jseyfried changed the titleAllow use macro imports to shadow builtin macors Allow use macro imports to shadow builtin macros

Mar 14, 2017

@nrc

I think the terminology could be improved - built-in suggests that it is part of the compiler, but only a small subset of macros are and they are (iirc) in the prelude too. If I understand correctly, the distinction is more between legacy-imported and legacy-local?

@nrc

LGTM, I'd like to fix (or better understand) the naming issue, but r+ with that.

@jseyfried jseyfried changed the titleAllow use macro imports to shadow builtin macros Allow use macro imports to shadow global macros

Mar 16, 2017

@jseyfried

Agreed -- I renamed "builtin scope" to "global scope".
@bors r=nrc

@bors

📌 Commit a0707df has been approved by nrc

bors added a commit that referenced this pull request

Mar 18, 2017

@bors

Rollup of 22 pull requests

@bors

☔ The latest upstream changes (presumably #40346) made this pull request unmergeable. Please resolve the merge conflicts.

@jseyfried

@bors

📌 Commit d123e76 has been approved by nrc

frewsxcv added a commit to frewsxcv/rust that referenced this pull request

Mar 24, 2017

@frewsxcv

Allow use macro imports to shadow global macros

Terminology:

Today, the legacy scope can shadow the global scope (modulo RFC 1560 expanded shadowing restrictions). However, the modern scope cannot shadow or be shadowed by either the global or legacy scopes, leading to ambiguity errors.

This PR allows the modern scope to shadow the global scope (subject to some restrictions). More specifically, a name in the global scope is as shadowable as a glob import in the module self. In other words, we imagine a special, implicit glob import in each module item:

mod foo {
    #[lexical_only] // Not accessible via `foo::<name>`, like pre-RFC 1560 `use` imports.
    #[shadowable_by_legacy_scope] // for back-compat
    use <global_macros>::*;
}

r? @nrc

bors added a commit that referenced this pull request

Mar 24, 2017

@bors

@bors

@jseyfried

@jseyfried

@jseyfried

@bors

📌 Commit d64d381 has been approved by nrc

alexcrichton added a commit to alexcrichton/rust that referenced this pull request

Mar 25, 2017

@alexcrichton

Allow use macro imports to shadow global macros

Terminology:

Today, the legacy scope can shadow the global scope (modulo RFC 1560 expanded shadowing restrictions). However, the modern scope cannot shadow or be shadowed by either the global or legacy scopes, leading to ambiguity errors.

This PR allows the modern scope to shadow the global scope (subject to some restrictions). More specifically, a name in the global scope is as shadowable as a glob import in the module self. In other words, we imagine a special, implicit glob import in each module item:

mod foo {
    #[lexical_only] // Not accessible via `foo::<name>`, like pre-RFC 1560 `use` imports.
    #[shadowable_by_legacy_scope] // for back-compat
    use <global_macros>::*;
}

r? @nrc

bors added a commit that referenced this pull request

Mar 25, 2017

@bors

Rollup of 11 pull requests

bors added a commit that referenced this pull request

Mar 25, 2017

@bors

Rollup of 11 pull requests

@bors

⌛ Testing commit d64d381 with merge 7022e44...

@bors

@arielb1

@bors

⌛ Testing commit d64d381 with merge 1a95c82...

@bors

@arielb1

@bors

⌛ Testing commit d64d381 with merge 20ae752...

@bors

@arielb1

@bors

⌛ Testing commit d64d381 with merge ae3186d...

@arielb1

@bors

bors added a commit that referenced this pull request

Mar 26, 2017

@bors

Allow use macro imports to shadow global macros

Terminology:

Today, the legacy scope can shadow the global scope (modulo RFC 1560 expanded shadowing restrictions). However, the modern scope cannot shadow or be shadowed by either the global or legacy scopes, leading to ambiguity errors.

This PR allows the modern scope to shadow the global scope (subject to some restrictions). More specifically, a name in the global scope is as shadowable as a glob import in the module self. In other words, we imagine a special, implicit glob import in each module item:

mod foo {
    #[lexical_only] // Not accessible via `foo::<name>`, like pre-RFC 1560 `use` imports.
    #[shadowable_by_legacy_scope] // for back-compat
    use <global_macros>::*;
}

r? @nrc

@bors