Skip to content

/rust

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

Items with 'lexical' scope have poor scoping #23880

Closed
nrc opened this Issue Mar 31, 2015 · 4 comments

Comments

Assignees

@nrc nrc

Labels
A-resolve P-medium T-compiler
Projects
None yet
Milestone
No milestone
6 participants
@nrc @oli-obk @pnkfelix @nikomatsakis @brson @rust-highfive
@nrc
Copy link
Member

nrc commented Mar 31, 2015

E.g.,

struct Foo;

impl Foo {
    fn bar(&self) {}

    fn foo(&self) {
        fn bar(x: &Foo) {}

        bar(self);
    }
}

fn main() {}

Is an error, but shouldn't be, because the bar method hides the locally declared bar function inside foo.

I think this is a bug, so it shouldn't be on any milestone, but nominating just in case.

@nrc nrc added I-wrong A-resolve I-nominated labels Mar 31, 2015

@oli-obk

This comment has been minimized.

Sign in to view
Copy link
Contributor

oli-obk commented Apr 1, 2015

It's not an error anymore: http://is.gd/CKvJn3
@nrc

This comment has been minimized.

Sign in to view
Copy link
Member Author

nrc commented Apr 1, 2015

Ah curses, that isn't an error. Here's another go:

struct Foo<X> {
    x: Box<X>
}

impl<Bar> Foo<Bar> {
    fn foo(&self) {
        type Bar = i32;

        let _: Bar = 42;
    }
}

In this case the let statement should see the local type alias, but sees the type parameter.
@pnkfelix

This comment has been minimized.

Sign in to view
Copy link
Member

pnkfelix commented Apr 2, 2015

classifying as "just a bug", P-high, not 1.0.

Actually leaving as P-backcompat-lang, to represent the fact that this can lead to programs being accpeted that shoudl be rejected. So we will keep that tag as is.

But still not 1.0 blocker.

@pnkfelix pnkfelix removed the I-nominated label Apr 2, 2015

@brson brson added P-high and removed P-backcompat-lang labels Apr 29, 2015

@pnkfelix pnkfelix assigned nrc Apr 30, 2015

@nrc nrc added the T-compiler label Nov 2, 2015

@nikomatsakis

This comment has been minimized.

Sign in to view
Copy link
Contributor

nikomatsakis commented Nov 12, 2015

triage: P-medium

This has been sitting for a while and we don't expect immediate action, though hopefully a refactoring of resolve would lead to this being fixed.

@rust-highfive rust-highfive added P-medium and removed P-high labels Nov 12, 2015

jseyfried added a commit to jseyfried/rust that referenced this issue Jan 22, 2016

@jseyfried
resolve: Fix rust-lang#23880, a bug in lexical scoping
dddbd4b

jseyfried added a commit to jseyfried/rust that referenced this issue Jan 22, 2016

@jseyfried
resolve: Fix rust-lang#23880, a bug in lexical scoping
611c268

jseyfried added a commit to jseyfried/rust that referenced this issue Jan 22, 2016

@jseyfried
resolve: Fix rust-lang#23880, a scoping bug
64e2023

@jseyfried jseyfried referenced this issue Jan 22, 2016

Merged

resolve: Fix #23880, a scoping bug #31105

jseyfried added a commit to jseyfried/rust that referenced this issue Jan 26, 2016

@jseyfried
[breaking-change] fix rust-lang#23880, a scoping bug
5821219

jseyfried added a commit to jseyfried/rust that referenced this issue Jan 26, 2016

@jseyfried
Resolve: fix rust-lang#23880, a scoping bug
e1dd02c

jseyfried added a commit to jseyfried/rust that referenced this issue Jan 26, 2016

@jseyfried
Resolve: fix rust-lang#23880, a scoping bug 
This fixes a bug in which items in a block are shadowed by local variables and type parameters that are in scope.
It is a [breaking-change]. For example, the following code breaks:

```rust
fn foo() {
    let mut f = 1;
    {
        fn f() {}
        f += 1; // This will now resolve to the function instead of the local variable
    }
}
```

Any breakage can be fixed by renaming the item that is no longer shadowed.
faf0852

bors added a commit that referenced this issue Jan 26, 2016

@bors
Auto merge of #31105 - jseyfried:fix_lexical_scoping, r=nrc 
This fixes #23880, a scoping bug in which items in a block are shadowed by local variables and type parameters that are in scope.

After this PR, an item in a block will shadow any local variables or type parameters above the item in the scope hierarchy. Items in a block will continue to be shadowed by local variables in the same block (even if the item is defined after the local variable).

This is a [breaking-change]. For example, the following code breaks:
```rust
fn foo() {
    let mut f = 1;
    {
        fn f() {}
        f += 1; // This will resolve to the function instead of the local variable
    }
}
43c1a17

@bors bors closed this in #31105 Jan 26, 2016

mitaa added a commit to mitaa/rust that referenced this issue Jan 28, 2016

@jseyfried @mitaa
Resolve: fix rust-lang#23880, a scoping bug 
This fixes a bug in which items in a block are shadowed by local variables and type parameters that are in scope.
It is a [breaking-change]. For example, the following code breaks:

```rust
fn foo() {
    let mut f = 1;
    {
        fn f() {}
        f += 1; // This will now resolve to the function instead of the local variable
    }
}
```

Any breakage can be fixed by renaming the item that is no longer shadowed.
6ebdd73

Yoric pushed a commit to Yoric/rust that referenced this issue Jan 29, 2016

@jseyfried David Rajchenbach-Teller
Resolve: fix rust-lang#23880, a scoping bug 
This fixes a bug in which items in a block are shadowed by local variables and type parameters that are in scope.
It is a [breaking-change]. For example, the following code breaks:

```rust
fn foo() {
    let mut f = 1;
    {
        fn f() {}
        f += 1; // This will now resolve to the function instead of the local variable
    }
}
```

Any breakage can be fixed by renaming the item that is no longer shadowed.
cf30500

rthomas added a commit to rthomas/rust that referenced this issue Feb 1, 2016

@jseyfried @rthomas
Resolve: fix rust-lang#23880, a scoping bug 
This fixes a bug in which items in a block are shadowed by local variables and type parameters that are in scope.
It is a [breaking-change]. For example, the following code breaks:

```rust
fn foo() {
    let mut f = 1;
    {
        fn f() {}
        f += 1; // This will now resolve to the function instead of the local variable
    }
}
```

Any breakage can be fixed by renaming the item that is no longer shadowed.
1116f74

@jseyfried jseyfried referenced this issue Feb 24, 2016

Closed

Regression (?) in name resolution of items defined in functions/blocks #31845

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.