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

Incorrect fn subtyping with bound regions and 'static #13974

Closed
nikomatsakis opened this issue May 6, 2014 · 0 comments · Fixed by #13975
Closed

Incorrect fn subtyping with bound regions and 'static #13974

nikomatsakis opened this issue May 6, 2014 · 0 comments · Fixed by #13975

Comments

@nikomatsakis
Copy link
Contributor

This test file incorrect returns a compilation error:

struct S;
type F = fn<'cx>(&'cx S) -> &'cx S;
fn foo(x: &S) -> &'static S { fail!() }
fn want_F(f: F) { }
pub fn main() {
    want_F(foo); // Incorrect error here
}

In particular, a fn like foo which always returns a pointer with 'static lifetime should be considered a subtype of a fn type that always returns pointer with same lifetime as its input.

nikomatsakis added a commit to nikomatsakis/rust that referenced this issue May 9, 2014
…e they

have no value. This also ensures that we can handle some obscure cases of fn
subtyping with bound regions that we didn't used to handle correctly.

Fixes rust-lang#13974.
bors added a commit that referenced this issue May 20, 2014
…-static, r=pnkfelix

Tweak region inference to ignore constraints like `'a <= 'static`, since they
have no value. This also ensures that we can handle some obscure cases of fn
subtyping with bound regions that we didn't used to handle correctly.

Fixes #13974.
bors added a commit to rust-lang-ci/rust that referenced this issue Jun 5, 2023
…=Veykril

Introduce macro sub-namespaces and `macro_use` prelude

This PR implements two mechanisms needed for correct macro name resolution: macro sub-namespace and `macro_use` prelude.

- [macro sub-namespaces][subns-ref]

  Macros have two sub-namespaces: one for function-like macro and the other for those in attributes (including custom derive macros). When we're resolving a macro name for function-like macro, we should ignore non-function-like macros, and vice versa.

  This helps resolve single-segment macro names because we can (and should, as rustc does) fallback to names in preludes when the name in the current module scope is in different sub-namespace.

- [`macro_use` prelude][prelude-ref]

  `#[macro_use]`'d extern crate declarations (including the standard library) bring their macros into scope, but they should not be prioritized over local macros (those defined in place and those explicitly imported).

  We have been bringing them into legacy (textual) macro scope, which has the highest precedence in name resolution. This PR introduces the `macro_use` prelude in crate-level `DefMap`s, whose precedence is lower than local macros but higher than the standard library prelude.

The first 3 commits are drive-by fixes/refactors.

Fixes rust-lang#8828 (prelude)
Fixes rust-lang#12505 (prelude)
Fixes rust-lang#12734 (prelude)
Fixes rust-lang#13683 (prelude)
Fixes rust-lang#13821 (prelude)
Fixes rust-lang#13974 (prelude)
Fixes rust-lang#14254 (namespace)

[subns-ref]: https://doc.rust-lang.org/reference/names/namespaces.html#sub-namespaces
[prelude-ref]: https://doc.rust-lang.org/reference/names/preludes.html#macro_use-prelude
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant