https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.3.0 2015-01-31T16:40:40+00:00 2015-01-31T16:40:40+00:00 Tobias Bucher tobiasbucher5991@gmail.com 2015-01-31T16:23:42+00:00 urn:sha1:b4a43f3864e394959a7d3c3efae6da85bdc59c71 2015-01-13T12:46:29+00:00 Felix S. Klock II pnkfelix@pnkfx.org 2015-01-13T12:46:29+00:00 urn:sha1:f0d7871ab7560694fd6767c1b5e38543b20a82f8 This makes the tests much easier to maintain; the particular details of the labels attached to exiting scopes is not worth the effort required to keep it up to date as things change in the compiler internals. 2015-01-06T21:48:33+00:00 Corey Richardson corey@octayn.net 2014-12-06T02:12:25+00:00 urn:sha1:5a4ca319185a3f399986bc5e5a2d0a96fac583ae 2014-08-28T01:46:52+00:00 Niko Matsakis niko@alum.mit.edu 2014-08-28T01:46:52+00:00 urn:sha1:1b487a890695e7d6dfbfe5dcd7d4fa0e8ca8003f 2014-08-26T04:07:32+00:00 Nick Cameron ncameron@mozilla.com 2014-08-06T09:59:40+00:00 urn:sha1:52ef46251ede1ff51e5d5621d5fe2614e950f963 2014-08-26T00:38:51+00:00 Nick Cameron ncameron@mozilla.com 2014-08-04T12:20:11+00:00 urn:sha1:3e626375d8d2226a203bf6ea6e98dab14774c59f [breaking-change] 1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code. 2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible. 3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string. 2014-06-29T18:47:58+00:00 Patrick Walton pcwalton@mimiga.net 2014-06-27T19:30:25+00:00 urn:sha1:a5bb0a3a4574af88add700ace7aefc37172fa7a5 floating point numbers for real. This will break code that looks like: let mut x = 0; while ... { x += 1; } println!("{}", x); Change that code to: let mut x = 0i; while ... { x += 1; } println!("{}", x); Closes #15201. [breaking-change] 2014-05-15T20:50:42+00:00 Felix S. Klock II pnkfelix@pnkfx.org 2014-05-05T15:00:14+00:00 urn:sha1:3aad0e249cebaf2123cd875b737c088ae2c48728 Each test works by rendering the flowgraph for the last identified block we see in expanded pretty-printed output, and comparing it (via `diff`) against a checked in "foo.dot-expected.dot" file. Each test post-processes the output to remove NodeIds ` (id=NUM)` so that the expected output is somewhat stable (or at least independent of how we assign NodeIds) and easier for a human to interpret when looking at the expected output file itself. ---- Test writing style notes: I usually tried to write the tests in a way that would avoid duplicate labels in the output rendered flow graph, when possible. The tests that have string literals "unreachable" in the program text are deliberately written that way to remind the reader that the unreachable nodes in the resulting graph are not an error in the control flow computation, but rather a natural consequence of its construction.