Commit Graph

13 Commits

Author SHA1 Message Date
Ariel Ben-Yehuda
b23648fe4a improve the printing of substs and trait-refs 2016-04-05 22:56:23 +03:00
Ariel Ben-Yehuda
8a461d940c suggest adding a where-clause when that can help
suggest adding a where-clause when there is an unmet trait-bound that
can be satisfied if some type can implement it.
2016-04-05 20:58:58 +03:00
Niko Matsakis
8403b82ddb Port over type inference to using the new type relation stuff 2015-03-31 09:51:18 -04:00
Alex Crichton
d6e939a2df Round 3 test fixes and conflicts 2015-02-18 16:34:04 -08:00
Niko Matsakis
872ce47955 Fallout: tests. As tests frequently elide things, lots of changes
here.  Some of this may have been poorly rebased, though I tried to be
careful and preserve the spirit of the test.
2015-02-18 10:25:28 -05:00
mdinger
7b82a93be3 Fix testsuite errors 2015-01-12 01:34:13 -05:00
Corey Richardson
5a4ca31918 test fallout from isize/usize 2015-01-06 16:48:33 -05:00
Nick Cameron
e0684e8769 Fallout 2015-01-06 14:20:48 +13:00
Nick Cameron
2e86929a4a Allow use of [_ ; n] syntax for fixed length and repeating arrays.
This does NOT break any existing programs because the `[_, ..n]` syntax is also supported.
2014-12-20 15:23:29 +13:00
P1start
f56c67ba86 Change rustc pretty-printing to print [T, ..n] instead of [T, .. n] 2014-10-03 20:39:56 +13:00
Niko Matsakis
b88f86782e Update error messages in compile-fail tests 2014-09-15 14:58:49 -04:00
Nick Cameron
52ef46251e Rebasing changes 2014-08-26 16:07:32 +12:00
Nick Cameron
3e626375d8 DST coercions and DST structs
[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-08-26 12:38:51 +12:00