![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
TMI: Starting to write again
Oct. 5th, 2012 08:53 pmI haven't been writing daily research posts in a while, partly because we've been working on getting the Rust 0.4 release ready for quite a while (and it's still not going to be done until early next week at the earliest), and that has involved quite a lot of mind-numbingly routine tasks. The kind of mind-numbing work that's occasionally interspersed with finding some bug that makes you wonder whether the space-time continuum around your desk is flawed. In other words, the usual for working on compilers. My lack of writing is also because of this stuff going on at work, as well as my having spent lots and lots of time working on some loosely related pieces of writing, and thus not having a lot of energy left for writing about work.
I'd like to start writing regularly again, but I also don't want to leave any kind of impression that I'm committing to doing it every day again.
We've got one open bug left for the release. I'm working on that one, or actually, doing nothing at all on it right now while I wait for a snapshot to build. In the meantime, I looked at a typechecking bug that user BigEndian on IRC just reported. The bug is a good reminder that we're still at a point in developing the Rust compiler where some fairly obvious bugs can get found by users who are just experimenting, not trying to test the compiler. In this case, referring to variables such as the self variable, or function arguments, inside of a constant item nested inside a function, causes an internal compiler error in the typechecker. There is a separate pass from the typechecker that checks constants for constant-ness: it would reject this code, since a constant can't refer to non-constant things. But for reasons unknown and undocumented, that pass happens after typechecking. In the meantime, the typechecker assumes that constants are sensible, resulting in an assertion failure when they aren't.
I'm actually not sure what to do here. Typechecking nested constants properly would require some refactoring in the typechecker, and it seems like too much effort to go to in order to typecheck programs we know will fail in the next phase anyway! OTOH, there's probably a good reason why constant checking is after typechecking.
I'd like to start writing regularly again, but I also don't want to leave any kind of impression that I'm committing to doing it every day again.
We've got one open bug left for the release. I'm working on that one, or actually, doing nothing at all on it right now while I wait for a snapshot to build. In the meantime, I looked at a typechecking bug that user BigEndian on IRC just reported. The bug is a good reminder that we're still at a point in developing the Rust compiler where some fairly obvious bugs can get found by users who are just experimenting, not trying to test the compiler. In this case, referring to variables such as the self variable, or function arguments, inside of a constant item nested inside a function, causes an internal compiler error in the typechecker. There is a separate pass from the typechecker that checks constants for constant-ness: it would reject this code, since a constant can't refer to non-constant things. But for reasons unknown and undocumented, that pass happens after typechecking. In the meantime, the typechecker assumes that constants are sensible, resulting in an assertion failure when they aren't.
I'm actually not sure what to do here. Typechecking nested constants properly would require some refactoring in the typechecker, and it seems like too much effort to go to in order to typecheck programs we know will fail in the next phase anyway! OTOH, there's probably a good reason why constant checking is after typechecking.