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

Resolve is not detecting out-of-scope type parameters #14603

Closed
nikomatsakis opened this issue Jun 2, 2014 · 0 comments · Fixed by #14604
Closed

Resolve is not detecting out-of-scope type parameters #14603

nikomatsakis opened this issue Jun 2, 2014 · 0 comments · Fixed by #14604

Comments

@nikomatsakis
Copy link
Contributor

There is currently some incorrect code in substitutions attempting to check for out-of-scope type parameters by detecting out-of-bounds indices. This is the wrong phase; this sort of lexical binding stuff is supposed to be handled by resolve. I have a fix coming in a PR today.

Here is a test that incorrectly compiles today as a result:

trait Trait<A> {
    fn outer(self) {
        enum Foo<B> {
            Variance(A)
        }
    }
}

fn main() { }
mcpherrinm pushed a commit to mcpherrinm/rust that referenced this issue Jun 10, 2014
bors added a commit that referenced this issue Jun 13, 2014
… r=pcwalton

The current setup is to have a single vector of type parameters in
scope at any one time. We then have to concatenate the parameters from
the impl/trait with those of the method. This makes a lot of things
awkward, most notably associated fns ("static fns"). This branch
restructures the substitutions into three distinct namespaces (type,
self, fn). This makes most of the "type parameter management"
trivial. This also sets us up to support UFCS (though I haven't made
any particular changes in that direction in this patch).

Along the way, this patch fixes a few miscellaneous bits of code cleanup:

1. Patch resolve to detect references to out-of-scope type parameters,
   rather than checking for "out of bound" indices during substitution
   (fixes #14603).

2. Move def out of libsyntax into librustc where it belongs. I should have
   moved DefId too, but didn't.
   
3. Permit homogeneous tuples like `(T, T, T)` to be used as fixed-length
   vectors like `[T, ..3]`. This is awfully handy, though public facing.
   I suppose it requires an RFC.

4. Add some missing tests.

cc #5527

r? @pcwalton or @pnkfelix
bors added a commit to rust-lang-ci/rust that referenced this issue Jun 5, 2023
fix: Deduplicate passed workspaces by top level cargo workspace they belong to

Fixes rust-lang/rust-analyzer#14571

With this we should be supporting vscode workspaces properly
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