Remove typestate from the language #2588
Conversation
Issue 2526 showed a test case where a library exported only a type that was a synonym for a class. Because the class's destructor wasn't getting marked as reachable, its linkage was wrongly getting set to "internal". The solution is for reachability to traverse types. Closes rust-lang#2526.
It was a little hard for me to believe, but it seems that re-exporting an impl doesn't work at a, because encoder::encode_info_for_mod requires that all the impls in the current module's impl map be local (that is, bound to a value in the current crate's item map). Fixed it. Closes rust-lang#2414.
|
Uh, this is based on whatever is on incoming right now. That's why there are so many unrelated commits. |
|
Is there anything wrong with simply leaving the code as it is and not advertising it as a feature, which is the conclusion I thought we came to in the meeting? |
|
@catamorphism Last time I checked it was still taking 0.8s to typestate check rustc. I also just don't like having dead code around. |
|
Agreed with @brson. Also, keeping the (huge) typestate code in sync when making changes is just not a very good use of people's time if it doesn't have a future anyway. |
|
The conclusion in the meeting was "we need to have a separate actual conversation about typestate since it's a separate concern from the topic at hand". The 0.8s is not killing us presently, so let's think and talk a bit more carefully. I'm not comfortable with doing from "static-optimized DBC system" to "no DBC system" in a single step without being absolutely sure. That said, bitrotting code in the compiler is a no-go. If it does wind up disabled, we should remove it. |
Update toolchain and remove dependency on line number since we match exact value only, this generate a lot of noise whenever we update the toolchain.
During our planning meeting today it sounded like the end is near, so here it is.
107 files changed, 105 insertions(+), 5342 deletions(-)