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

Check the bounds in impls against concrete types #16955

Closed
nrc opened this issue Sep 3, 2014 · 2 comments · Fixed by #17003
Closed

Check the bounds in impls against concrete types #16955

nrc opened this issue Sep 3, 2014 · 2 comments · Fixed by #17003
Milestone

Comments

@nrc
Copy link
Member

nrc commented Sep 3, 2014

E.g., impl<X: ...> Trait<X> for Struct<X> { ... } we check the bounds of X satisfy the bounds given by Trait, but not those given by Struct. I don't think this is a soundness issue (because any use of X is limited to the impl and relies on the given bounds, not the bounds given by Struct), but it is a bit odd and not the behaviour I would expect, especially given RFC 11 (https://github.com/rust-lang/rfcs/blob/master/active/0011-bounded-type-parameters.md).

@nrc
Copy link
Member Author

nrc commented Sep 3, 2014

Nominating because it is a backwards incompatible change

@nrc nrc added the I-nominated label Sep 3, 2014
@brson brson added this to the 1.0 milestone Sep 4, 2014
@nrc
Copy link
Member Author

nrc commented Sep 5, 2014

Turns out this only affects impls with no trait, we already do the expected thing if there is a trait. Example,

trait T {}
impl<X> C<X> {}
struct C<X: T>;

Should not type check.

nrc added a commit to nrc/rust that referenced this issue Sep 5, 2014
bors added a commit that referenced this issue Sep 6, 2014
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 31, 2024
…lnicola

fix: check for client support of relative glob patterns before using them

Fixes rust-lang#16955
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.

2 participants