![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
TMI: Yak-shaving
Aug. 13th, 2012 07:17 pmI worked on purging match checks (non-exhaustive matches) from the compiler, but I ended up on what turned out to be a pretty involved tangent. Perhaps I should have resisted the temptation to refactor code and should have instead just added lots of _ => fail; cases. But it pains me to see places where the AST data type could easily ("easily") be changed to not make junk representable.
The refactor in this case is that there were expr_loop_body (representing the body of a Rust for loop) and expr_do_body (representing the body of a Rust do expression, which, by the way, is nothing like a Haskell do expression) variants in the AST where the contents were (according to its type) expr in both cases, but there was an unstated invariant that the contained expr had to be built with the expr_fn_block variant. Obviously, the Right Thing was to replace those three variants with a single expr_fn_block variant, one of whose components is a flag saying whether it appears inside a for, inside a do or neither. (Of course, now that I've said that, one of my colleagues will tell me that there was a good reason for the original type definition ;-)
But, as these things always seem to go, I broke something in a very obscure way (possibly by causing trans to treat a do body like a regular function block, or something) and that manifested itself as wrong code being generated, and thus, assertion failures tripping. (Wrong-code is my least favorite compiler failure mode.)
Meanwhile, I also worked on a FIXME bug that I started last week while looking at references to FIXMEs that had been closed in the meantime. I tried changing the standard library num trait to make its from_int method static (sensibly enough), which tripped a bug in the compiler related to typechecking traits. I fixed that, but needed a new snapshot to make any changes, and then the makefile infrastructure that allows building with a local snapshot seemed not to work, and I can't build a real snapshot since the build is currently broken for other reasons... and so it goes. But at least I checked in something
The refactor in this case is that there were expr_loop_body (representing the body of a Rust for loop) and expr_do_body (representing the body of a Rust do expression, which, by the way, is nothing like a Haskell do expression) variants in the AST where the contents were (according to its type) expr in both cases, but there was an unstated invariant that the contained expr had to be built with the expr_fn_block variant. Obviously, the Right Thing was to replace those three variants with a single expr_fn_block variant, one of whose components is a flag saying whether it appears inside a for, inside a do or neither. (Of course, now that I've said that, one of my colleagues will tell me that there was a good reason for the original type definition ;-)
But, as these things always seem to go, I broke something in a very obscure way (possibly by causing trans to treat a do body like a regular function block, or something) and that manifested itself as wrong code being generated, and thus, assertion failures tripping. (Wrong-code is my least favorite compiler failure mode.)
Meanwhile, I also worked on a FIXME bug that I started last week while looking at references to FIXMEs that had been closed in the meantime. I tried changing the standard library num trait to make its from_int method static (sensibly enough), which tripped a bug in the compiler related to typechecking traits. I fixed that, but needed a new snapshot to make any changes, and then the makefile infrastructure that allows building with a local snapshot seemed not to work, and I can't build a real snapshot since the build is currently broken for other reasons... and so it goes. But at least I checked in something