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

cyclic trait inheritance leads to a rustc stack overflow #12511

Closed
nrc opened this issue Feb 24, 2014 · 8 comments
Closed

cyclic trait inheritance leads to a rustc stack overflow #12511

nrc opened this issue Feb 24, 2014 · 8 comments
Assignees
Labels
A-traits Area: Trait system E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.

Comments

@nrc
Copy link
Member

nrc commented Feb 24, 2014

trait t1 : t2 {
}
trait t2 : t1 {
}

or even

trait t : t {
}

gives a stack overflow:

task 'rustc' has overflowed its stack
./build.sh: line 1: 22351 Illegal instruction (core dumped) /home/nick/rust2/x86_64-unknown-linux-gnu/stage1/bin/rustc $1.rs -o $1

@nrc
Copy link
Member Author

nrc commented Feb 24, 2014

I would expect an error message.

@huonw
Copy link
Member

huonw commented Feb 24, 2014

Seems similar to #8762 and possibly #9095.

@nrc
Copy link
Member Author

nrc commented Feb 24, 2014

Yeah, I think we need to be checking for logical cycles in a lot of places.

@nikomatsakis
Copy link
Contributor

cc me and #5527

@lilyball
Copy link
Contributor

cc me

@nikomatsakis
Copy link
Contributor

This is related to the work on trait-reform and where clauses, actually. The immediate cause for this is that typeck's collect phase attempts to gather both the bounds and the set of type parameters in one step. It should do a first-pass that just collects, for each nominal type, what its type parameter names are. Then a second pass to gather bounds. This is natural with where clauses. The next problem will occur when gathering up "implied" trait bounds -- if we're not careful, we'll get a cycle there too, as we go from A to B and back again. But we can patch that too, both by checking for recursion and reporting an error (no matter what), but also by seeing if we've already visited one of the type-trait-pairs and avoiding recursion in that case (this would allow us to reach a fixed point).

@nikomatsakis
Copy link
Contributor

I'll fix this soon.

@nikomatsakis nikomatsakis self-assigned this Feb 11, 2015
@tamird
Copy link
Contributor

tamird commented Apr 22, 2015

This no longer reproduces:

$ rustc main.rs
main.rs:1:1: 2:2 error: unsupported cyclic reference between types/traits detected
main.rs:1 trait t1 : t2 {
main.rs:2 }
note: the cycle begins when computing the supertraits of `t1`...
note: ...which then requires computing the supertraits of `t2`...
note: ...which then again requires computing the supertraits of `t1`, completing the cycle.
main.rs:3:1: 4:2 error: unsupported cyclic reference between types/traits detected
main.rs:3 trait t2 : t1 {
main.rs:4 }
note: the cycle begins when computing the supertraits of `t2`...
note: ...which then requires computing the supertraits of `t1`...
note: ...which then again requires computing the supertraits of `t2`, completing the cycle.
error: aborting due to 2 previous errors

@alexcrichton alexcrichton added the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label Apr 22, 2015
@bors bors closed this as completed in 846b368 May 4, 2015
matthiaskrgr pushed a commit to matthiaskrgr/rust that referenced this issue Mar 21, 2024
…r=Alexendoo

`assigning_clones` should respect MSRV

Fixes: rust-lang#12502

This PR fixes the `assigning_clones` lint suggesting to use `clone_from` or `clone_into` on incompatible MSRVs.

`assigning_clones` will suggest using either `clone_from` or `clone_into`, both of which were stabilized in 1.63. If the current MSRV is below 1.63, the lint should not trigger.

changelog: [`assigning_clones`]: don't lint when the MSRV is below 1.63.
matthiaskrgr pushed a commit to matthiaskrgr/rust that referenced this issue Mar 21, 2024
…r=Alexendoo

Make `assigning_clones` MSRV check more precise

Continuation of rust-lang#12511

`clone_into` is the only suggestion subject to the 1.63 MSRV requirement, and the lint should still emit other suggestions regardless of the MSRV.

changelog: [assigning_clones]: only apply MSRV check to `clone_into` suggestions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-traits Area: Trait system E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
Projects
None yet
Development

No branches or pull requests

6 participants