The way we deal with unreachable expressions in trans is pretty ad hoc,
but this at least doesn't make it worse, and eliminates the LLVM
assertion failure reported in #5741.
This adds a lint mode for detecting unnecessary allocations on the heap. This isn't super fancy, currently it only has two rules
1. For a function's arguments, if you allocate a `[~|@]str` literal, when the type of the argument is a `&str`, emit a warning.
2. For the same case, emit warnings for boxed vectors when slices are required.
After adding the lint, I rampaged through the libraries and removed all the unnecessary allocations I could find.
Currently, trait_info is a hashmap that allows a quick lookup of all
methods contained in a given trait, but we actually only use it to
lookup traits that contain a given method. Adjusting the map to support
the lookup we actually need gives a nice speed boost, reducing the time
required for the resolution step for librustc from ~2.6s to ~1.0s on my
box.
With this, the build is almost 100% warning free.
One more can be fixed after the next snapshot, and there's one other that I filed an issue about already.
r? @nikomatsakis Impls can implement either zero or one traits; this has been true
more or less since we removed classes. So I got rid of the comments
saying "we should support multiple traits" and changed the code to
make it clear that we don't. This is just cleanup, and doesn't break
any existing tests.
Impls can implement either zero or one traits; this has been true
more or less since we removed classes. So I got rid of the comments
saying "we should support multiple traits" and changed the code to
make it clear that we don't. This is just cleanup, and doesn't break
any existing tests.
`str::from_slice` and `vec::from_slice` are changed to `str::to_owned` and `vec::to_owned`. (#6389)
Replace `at_vec::from_owned` and `at_vec::from_slice` with `at_vec::to_managed_consume` and `at_vec::to_managed`.
Replace all instances of #[auto_*code] with the appropriate #[deriving] attribute
and remove the majority of the actual auto_* code, leaving stubs to refer the user to
the new syntax.
Also, moves the useful contents of auto_encode.rs to more appropriate spots: tests and comments to deriving/encodable.rs, and the ExtCtxtMethods trait to build.rs (unused so far, but the method syntax might be nicer than using the mk_* fns in many instances).
Replace all instances of #[auto_*code] with the appropriate #[deriving] attribute
and remove the majority of the actual code, leaving stubs to refer the user to
the new syntax.
fail!() used to require owned strings but can handle static strings
now. Also, it can pass its arguments to fmt!() on its own, no need for
the caller to call fmt!() itself.
When trying to import nonexistent items from existing modules, specify that
that is what happened, rather than just reporting "unresolved name".
Ideally the error would be reported on the span of the import... but I do not see a way to get a span there. Help appreciated 😄
This pull request adds 4 atomic intrinsics to the compiler, in preparation for #5042.
* `atomic_load(src: &int) -> int` performs an atomic sequentially consistent load.
* `atomic_load_acq(src: &int) -> int` performs an atomic acquiring load.
* `atomic_store(dst: &mut int, val: int)` performs an atomic sequentially consistent store.
* `atomic_store_rel(dst: &mut int, val: int)` performs an atomic releasing store.
For more information about the whole acquire/release thing: http://llvm.org/docs/Atomics.html
r?
Every unresolved import is reported. An additional error message isn't useful
and obscures (imo) the real errors: I need to take it into account when
looking at the error count.
The default versions (atomic_load and atomic_store) are sequentially consistent.
The atomic_load_acq intrinsic acquires as described in [1].
The atomic_store_rel intrinsic releases as described in [1].
[1]: http://llvm.org/docs/Atomics.html
r? @nikomatsakis 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.
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.
**Caveat**: With the current commit, this check only works for `match`s, the checks (incorrectly) do not run for patterns in `let`s, and invalid/unsafe code compiles.
I don't know how to fix this, I experimented with some things to try to make let patterns and match patterns run on the same code (since this would presumably fix many of the other unsoundness issues of let-patterns, e.g. #6225), but I don't understand enough of the code. (I think I heard someone talking about a fix for `let` being in progress?)
Fixes#6344 and #6341.
Closes#6183.
The first commit changes the compiler's method of treating a `for` loop, and all the remaining commits are just dealing with the fallout.
The biggest fallout was the `IterBytes` trait, although it's really a whole lot nicer now because all of the `iter_bytes_XX` methods are just and-ed together. Sadly there was a huge amount of stuff that's `cfg(stage0)` gated, but whoever lands the next snapshot is going to have a lot of fun deleting all this code!
&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.
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.
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
At the moment this only includes type checking and there is no code generation support yet. I wanted to get the design reviewed first.
From discussion with @graydon at #5841, re-implemented as `#[simd]` attribute on structs.
Progressing towards #3499.
r? @ILyoan
This pulls all the logic for discovering the crate entry point into a new pass (out of resolve and typeck), then changes it so that main is only looked for at the crate level (`#[main]` can still be used anywhere).
I don't understand the special android logic here and worry that I may have broken it.
Also fixed the docstring on `TC_ONCE_CLOSURE` (was accidentally the same as `TC_MUTABLE`) and shifted the `TC_EMPTY_ENUM` bit left by one since whatever previously used that bit has been removed.
I just had `git apply` fix most of them and then did a quick skim over the diff to fix a few cases where it did the wrong thing (mostly replacing tabs with 4 spaces, when someone's editor had them at 8 spaces).
r? @pcwalton
Sorry this is so big, and sorry the first commit is just titled 'wip'.
Some interesting bits
* [LocalServices](f9069baa70) - This is the set of runtime capabilities that *all* Rust code should expect access to, including the local heap, GC, logging, unwinding.
* [impl Reader, etc. for Option](5fbb0949a5) - Constructors like `File::open` return Option<FileStream>. This lets you write I/O code without ever unwrapping an option.
This series adds a lot of [documentation](https://github.com/brson/rust/blob/io/src/libcore/rt/io/mod.rs#L11) to `core::rt::io`.
Recent demoding makes the visitor glue leak. It hasn't shown up in tests
because the box annihilator deletes the leaked boxes. This affects the
new scheduler though which does not yet have a box annihilator.
I don't think there's any great way to test this besides setting up
a task that doesn't run the box annihilator and I don't know that that's
a capability we want tasks to have.
I don't know how one would write a separate test for this sort of thing. Building the compiler, and `make check` worked, which should mean I didn't screw anything.
I've added trt_field_vtable, trt_field_box, and trt_field_tydesc, and
inserted them in place of the "magic numbers" used to access trait
object fields through GEPi().
The drop block has been deprecated for quite some time. This patch series removes support for parsing it and all the related machinery that made drop work.
As a side feature of all this, I also added the ability to annote fields in structs. This allows comments to be properly associated with an individual field. However, I didn't update `rustdoc` to integrate these comment blocks into the documentation it generates.
