In #6319, several people mentioned they ran into a "computing
fictitious type" ICE in trans. This turns out to be because some
of my recent changes to typeck::check::_match resulted in type errors
getting reported with ty_err as the expected type, which meant the errors
were suppressed, and typechecking incorrectly succeeded (since the errors
weren't recorded).
Changed the error messages in these cases not to use an expected type at all,
rather, printing out a string describing the type that was expected (which is
what the code originally did). The result is a bit repetitive and the
proliferation of error-reporting functions in typeck::infer is a bit annoying,
but I thought it was important to fix this now; more cleanup can happen later.
I changed ```RED_ZONE_SIZE``` to ```RZ_MAC_32``` because of stack canary failure.
Here is a LLVM patch for MIPS segmented stacks.
http://people.cs.nctu.edu.tw/~jyyou/rust/mips-segstk.patch
Current test results
```
failures:
rand::tests::test_rng_seeded_custom_seed2
run::tests::test_forced_destroy_actually_kills
run::tests::test_unforced_destroy_actually_kills
time::tests::run_tests
uv_ll::test::test_uv_ll_struct_size_addrinfo
uv_ll::test::test_uv_ll_struct_size_uv_timer_t
segfaults:
rt::io::option::test::test_option_writer_error
rt::local_services::test::unwind
rt::sched::test_swap_tasks_then
stackwalk::test_simple
stackwalk::test_simple_deep
```
&str can be turned into @~str on demand, using to_owned(), so for
strings, we can create a specialized interner that accepts &str for
intern() and find() but stores and returns @~str.
This improves error reporting for the following class of imports:
```rust
use foo::bar;
```
Where foo, the topmost module, is unresolved. It now results in:
```text
/tmp/foo.rs:1:4: 1:7 error: unresolved import. perhapsyou forgot an 'extern mod foo'?
/tmp/foo.rs:1 use foo::bar;
^~~
/tmp/foo.rs:1:4: 1:12 error: failed to resolve import: foo::bar
/tmp/foo.rs:1 use foo::bar;
^~~~~~~~
error: failed to resolve imports
error: aborting due to 3 previous errors
```
This is the first of a series of changes I plan on making to unresolved name error messages.
As noted by @jwise [here](52445129fd (commitcomment-3172192)), it's probably a good idea to keep these unsafe.
The lint check won't warn about these because it ignore `unsafe fn` declarations.
Use a bitset to represent built-in bounds. There are several places in the language where only builtin bounds (aka kinds) will be accepted, e.g. on closures, destructor type parameters perhaps, and on trait types.
r? @brson
Fix#6355 and #6272---we were not giving the correct index to the derefs that occur as part of the rooting process, resulting in extra copies and generally bogus behavior. Haven't quite produced the right test for this, but I thought I'd push the fix in the meantime. Test will follow shortly.
r? @graydon
Adds an `uninit` intrinsic.
It's just an empty function, so llvm optimizes it down to nothing.
I changed all of the `init` intrinsic usages to `uninit` where it seemed appropriate to.
I removed some of the copies, but most are just made explicit. The usage in `libcore` was already fixed, but the attribute was only set to warn (not removed).
its own type. Use a bitset to represent built-in bounds. There
are several places in the language where only builtin bounds (aka kinds)
will be accepted, e.g. on closures, destructor type parameters perhaps,
and on trait types.
&str can be turned into @~str on demand, using to_owned(), so for
strings, we can create a specialized interner that accepts &str for
intern() and find() but stores and returns @~str.
Hi there,
Really enjoying Rust. Noticed a few typos so I searched around for a few more--here's some fixes.
Ran `make check` and got `summary of 24 test runs: 4868 passed; 0 failed; 330 ignored`.
Thanks!
Sean
