4 ms·

I hope the Rust team also starts prioritizing compiler crashes. I started using Rust exclusively for hobby projects after the 1.0 release, to force myself to l

I hope the Rust team also starts prioritizing compiler crashes. I started using Rust exclusively for hobby projects after the 1.0 release, to force myself to learn the language, but I found myself running into compiler panics on nearly a daily basis. Admittedly, the code the compiler tended to crash on was very macro-heavy, but a goal of rust is safe macros. (And even if the macro-expanded code was invalid, the compiler should just report an error, not crash). There are currently 207 open issues regarding ICE (Internal Compiler Error): https://github.com/rust-lang/rust/labels/I-ICE https://github.com/rust-lang/rust/labels/I-ICE

steveklabnik 11y ago
It's not perfect, but https://github.com/rust-lang/rust/issues?page=1&q=is%3Aissue+label%3AI-ICE+closed%3A%3E2015-05-15+is%3Aclosed https://github.com/rust-lang/rust/issues?page=1&q=is%3Aissue... seems to indicate that we closed 81 issues tagged ICE between 1.0 and now. Not all of those made it into 1.1, bunches are in 1.2, and some of them are duplicates... If you're running into ICEs or any other bug, please either open up a ticket or :+1: the ticket that exists. It helps to know which things are biting people more often.
- deleted 11y ago
  [deleted]
arielby 11y ago
1.2 is much less ICE-ey than 1.0 (the annoying "capacity overflow" macro ICE is no longer an ICE - it still prints "internal compiler error: unprintable span" but doesn't crash).
kibwen 11y ago
It's definitely something to work on, but note that the Rust compiler tries hard to eagerly crash rather than possibly generate broken code. I'm very pleased at how few codegen-related bugs have been found since 1.0.
Jenny1975 11y ago
I've seen this complaint about the Rust compiler a number of times now, here and at other sites. Isn't one of the main selling points of Rust that it's supposed to make it much harder to write code that crashes? It is my understanding that the Rust compiler is mostly written in Rust. While maybe these ICEs aren't traditional segfaults that can be exploited, they're still unexpected crashes none the less! The software stops working without warning. If the best Rust experts around have so much trouble avoiding those kinds of crashes, then how is an average Rust user, or even a complete beginner like me, supposed to write Rust code that's any less susceptible to crashing?
- steveklabnik 11y ago
  TL;DR: don't underestimate the power of technical debt. Longer answer: The Rust compiler was written in Rust before the Rust language was even what it was today. As one particular example, the AST used to be garbage collected! And when you have a codebase that's 320,000 lines long, you don't update the entire codebase to the latest idiom, because if you did, you'd never actually ship the language. Basically no other Rust program will ever have to contend with this kind of situation. As such, while I can sympathize with this line of argument, I don't think it's representative. EDIT: I previously had 750,000 but it's actually 323,326 LOC as of right now. Whoops!
  - Jenny1975 11y ago
    Legacy code and inexperience with new technologies are not problems that are unique to Rust and the Rust compiler. And presumably Rust will continue to evolve, will it not? If my team starts a large, multi-year project using Rust 1.1 today, does Rust offer anything that will help us avoid the sorts of crashes that the Rust compiler suffers from?
    - steveklabnik 11y ago
      Your language changing literally every other day is a problem unique to a pre-1.0 language. You're right that technical debt in general is not. > And presumably Rust will continue to evolve, will it not? Right, but it will evolve in a backwards-compatible way, rather than in a "the fundamental semantics of the language have changed Yet Again" kind of way.
Aatch 11y ago
Just to note that by far and away, the most common cause of an ICE is a missing error message. Others are related to unstable features, which isn't particularly fair, since they're unstable for a reason. The remainder tend to be caused by odd combinations of features we didn't think of (which more often than not tend to be constructions with simple, working equivalents), often they become a question of "do we want to support this or not". Trust me, there are far worse things lurking in the compiler than a few improperly-handled error cases.

steveklabnik 11y ago

It's not perfect, but https://github.com/rust-lang/rust/issues?page=1&q=is%3Aissue+label%3AI-ICE+closed%3A%3E2015-05-15+is%3Aclosed https://github.com/rust-lang/rust/issues?page=1&q=is%3Aissue... seems to indicate that we closed 81 issues tagged ICE between 1.0 and now. Not all of those made it into 1.1, bunches are in 1.2, and some of them are duplicates... If you're running into ICEs or any other bug, please either open up a ticket or :+1: the ticket that exists. It helps to know which things are biting people more often.

deleted 11y ago
[deleted]

arielby 11y ago

1.2 is much less ICE-ey than 1.0 (the annoying "capacity overflow" macro ICE is no longer an ICE - it still prints "internal compiler error: unprintable span" but doesn't crash).

kibwen 11y ago

It's definitely something to work on, but note that the Rust compiler tries hard to eagerly crash rather than possibly generate broken code. I'm very pleased at how few codegen-related bugs have been found since 1.0.

Jenny1975 11y ago

I've seen this complaint about the Rust compiler a number of times now, here and at other sites. Isn't one of the main selling points of Rust that it's supposed to make it much harder to write code that crashes? It is my understanding that the Rust compiler is mostly written in Rust. While maybe these ICEs aren't traditional segfaults that can be exploited, they're still unexpected crashes none the less! The software stops working without warning. If the best Rust experts around have so much trouble avoiding those kinds of crashes, then how is an average Rust user, or even a complete beginner like me, supposed to write Rust code that's any less susceptible to crashing?

steveklabnik 11y ago
TL;DR: don't underestimate the power of technical debt. Longer answer: The Rust compiler was written in Rust before the Rust language was even what it was today. As one particular example, the AST used to be garbage collected! And when you have a codebase that's 320,000 lines long, you don't update the entire codebase to the latest idiom, because if you did, you'd never actually ship the language. Basically no other Rust program will ever have to contend with this kind of situation. As such, while I can sympathize with this line of argument, I don't think it's representative. EDIT: I previously had 750,000 but it's actually 323,326 LOC as of right now. Whoops!
- Jenny1975 11y ago
  Legacy code and inexperience with new technologies are not problems that are unique to Rust and the Rust compiler. And presumably Rust will continue to evolve, will it not? If my team starts a large, multi-year project using Rust 1.1 today, does Rust offer anything that will help us avoid the sorts of crashes that the Rust compiler suffers from?
  - steveklabnik 11y ago
    Your language changing literally every other day is a problem unique to a pre-1.0 language. You're right that technical debt in general is not. > And presumably Rust will continue to evolve, will it not? Right, but it will evolve in a backwards-compatible way, rather than in a "the fundamental semantics of the language have changed Yet Again" kind of way.

Aatch 11y ago

Just to note that by far and away, the most common cause of an ICE is a missing error message. Others are related to unstable features, which isn't particularly fair, since they're unstable for a reason. The remainder tend to be caused by odd combinations of features we didn't think of (which more often than not tend to be constructions with simple, working equivalents), often they become a question of "do we want to support this or not". Trust me, there are far worse things lurking in the compiler than a few improperly-handled error cases.