The compiler guarantees that there are no other references to a unique pointer when it's passed by-value to a function.
The existence of the header and annihilator don't matter since it's not relevant to the call:
> For a call to the parent function, dependencies between memory references from before or after the call and from those during the call are “irrelevant” to the noalias keyword for the arguments and return value used in that call.
@graydon's tracing garbage collector stores the metadata outside of the boxes, so that won't be a problem. I'm unsure if updating the header while inside a function where it's marked as `noalias` would be a problem anyway since you never actually read or write to the header.
@nikomatsakis: r?
mentioned in #2625.
This change makes the module more oriented around
Process values instead of having to deal with process ids
directly.
Apart from issues mentioned in #2625, other changes include:
- Changing the naming to be more consistent - Process/process
is now used instead of a mixture of Program/program and
Process/process.
- More docs/tests.
Some io/scheduler related issues remain (mentioned in #2625).
Simple patch series to fix up all the warnings a rustc compile is giving at the moment. It also fixes a NOTE in `to_bytes.rs` to remove the `to_bytes::iter_bytes_<N>` functions.
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.
Fixes https://github.com/mozilla/rust/issues/6578 by merging the 3 different ways to build an AST into a single `AstBuilder` trait, creating a more uniform and briefer interface.
Also, converts the `ext_ctxt` trait-object to be a plain struct, as well as renaming it to `ExtCtxt`.
Seems to make expansion slightly faster for the normal case (e.g. `libcore` and `libstd`), but slower for `librustc` (slightly) and `libsyntax` (0.3s -> 0.8s! I'm investigating this, but I'd prefer this patch to land relatively quickly.).
`git blame` suggests maybe @graydon or @erickt are familiar with this area of the code. r?
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.
It uses the private field of TCB head to store stack limit. I tested on my Raspberry PI. A simple hello world program ran without any problem. However, for a more complex program, it segfaulted as #6231.
Closes#2647
This way it's much easier to add lints throughout compilation correctly, and
functions on impls can alter the way lints are emitted. This involved pretty much rewriting how lints are emitted. Beforehand, only items could alter the lint settings, so whenever a lint was added it had to be associated with whatever item id it was coming from. I removed this (possibly questionably) in favor of just specifying a span and a message when adding a lint. When lint checking comes around, it looks at all the lints and sees which node with attributes best encloses it and uses that level of linting. This means that all consumer code doesn't have to deal with what item things came from (especially because functions on impls aren't items). More details of this can be found in the code (and comments).
As a bonus, I managed to greatly simplify emission of lints in resolve.rs about unused imports. Now instead of it manually tracking what the lint level is, it's all moved over into the lint module (as is to be expected).
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.
Fixes#6378
Don't pass the binary name to the LLVMRustExecuteJIT closure, otherwise it will leak memory; the binary name doesn't seem to be needed, anyhow.
**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.
This allows macros to create tests and benchmarks.
This is possibly unsound (I've got no idea, but it seemed to work), and being able to programmatically generate benchmarks to compare several implementations of similar algorithms is nice.
This fixes the issue described in #4202.
From what I understood of the code, when we reexport a trait in a submodule using e.g. "pub use foo::SomeTrait", we were not previously making an effort to reexport the static methods on that trait.
I'm new to the Rust code base (and the Rust language itself) so my approach may not be kosher, but this patch works by changing the encoder to include the static methods associated with traits.
I couldn't see any tests for this area of the code, so I didn't really have any examples to go by. If tests are needed, I'm happy to work through that if I can get some assistance to do so.
There may be a more efficient implementation of `core::util::swap_ptr`. The issue mentioned using `move_val_init`, but I couldn't figure out what that did, so I just used `copy_memory` a few times instead.
I'm not exactly the best at reading LLVM generated by rust, but this does appear to be optimized away just as expected (when possible).
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).
In rustpkg, pass around sysroot; in rustpkg tests, set the sysroot
manually so that tests can find libcore and such.
With bonus metadata::filesearch refactoring to avoid copies.
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.
Lots of linking arguments need to be passed as -Wl,--foo so giving the
comma meaning at the rustc layer makes those flags impossible to pass.
Multiple arguments can now be passed from a shell by quoting the
argument: --link-args='-lfoo -Wl,--as-needed'.
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.
Lots of linking arguments need to be passed as -Wl,--foo so giving the
comma meaning at the rustc layer makes those flags impossible to pass.
Multiple arguments can now be passed from a shell by quoting the
argument: --link-args='-lfoo -Wl,--as-needed'.
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.
After much discussion on IRC and #4819, we have decided to revert to the old naming of the `/` operator. This does not change its behavior. In making this change, we also have had to rename some of the methods in the `Integer` trait. Here is a list of the methods that have changed:
- `Quot::quot` -> `Div::div`
- `Rem::rem` - stays the same
- `Integer::quot_rem` -> `Integer::div_rem`
- `Integer::div` -> `Integer::div_floor`
- `Integer::modulo` -> `Integer::mod_floor`
- `Integer::div_mod` -> `Integer::div_mod_floor`
Adds two extra flags: `--linker` which takes extra flags to pass to the linker, can be used multiple times and `--print-link-args` which prints out linker arguments. Currently `--print-link-args` needs execution to get past translation to get the `LinkMeta` data.
I haven't done tests or updated any extra documentation yet, so this pull request is currently here for review.
Cases like `Either<@int,()>` have a null case with at most one value but
a nonzero number of fields; if we misreport this, then bad things can
happen inside of, for example, pattern matching.
Closes#6117.
r? @pcwalton
A month's worth of parser cleanup here. Much of this is new comments and renaming. A number of these commits also remove unneeded code. Probably the biggest refactor here is splitting "parse_item_or_view_item" into two functions; it turns out that the only overlap between items in foreign modules and items in regular modules was macros, so this refactor should make things substantially easier for future maintenance.
I didn't know how to use "use" initially, and an error message like this would
have solved quite a bit of frustration. I think this properly handles cases
where it's not appropriate but I'm not sure.
Closes#3083.
This takes a similar approach to #5797 where a set is present on the `tcx` of used mutable definitions. Everything is by default warned about, and analyses must explicitly add mutable definitions to this set so they're not warned about.
Most of this was pretty straightforward, although there was one caveat that I ran into when implementing it. Apparently when the old modes are used (or maybe `legacy_modes`, I'm not sure) some different code paths are taken to cause spurious warnings to be issued which shouldn't be issued. I'm not really sure how modes even worked, so I was having a lot of trouble tracking this down. I figured that because they're a legacy thing that I'd just de-mode the compiler so that the warnings wouldn't be a problem anymore (or at least for the compiler).
Other than that, the entire compiler compiles without warnings of unused mutable variables. To prevent bad warnings, #5965 should be landed (which in turn is waiting on #5963) before landing this. I figured I'd stick it out for review anyway though.
As the name suggests this replaces many instances of cast::reinterpret_cast by cast::transmute. It's essentially the boring part of fixing #5163, the remaining reinterpret_casts should be more tricky to remove (unless I missed a boring case).
r? @catamorphism
This adds debugging symbol generation for boxes, bare functions, vectors, and strings, along with a tests for boxes and vectors.
Note that gdb will see them as their actual compiled representation with the refcount, tydesc, etc. fields, so if `b` refers to box, `b->boxed` will refer to its value. Also, since you seem to use the [C struct hack](http://c-faq.com/struct/structhack.html) for dynamic vectors, you won't be able to print out the whole vector at once, only one element at a time by indexing specific elements.
r? @nikomatsakis
This doesn't completely fix the x86 ABI for structs, but it does fix some cases. On linux, structs appear to be returned correctly now. On windows, structs are only returned by pointer when they are greater than 8 bytes. That scenario works now.
In the case where the struct is less than 8 bytes our generated code looks peculiar. When returning a pair of u16, C packs both variables into %eax to return them. Our generated code though expects to find one of the pair in %ax and the other in %dx. Similar for u8. I haven't looked into it yet.
There appears to also be struct passing problems on linux, where my `extern-pass-TwoU8s` and `extern-pass-TwoU16s` tests are failing.
This Adds a bunch of tests for passing and returning structs
of various sizes to C. It fixes the struct return rules on unix,
and on windows for structs of size > 8 bytes. Struct passing
on unix for structs under a certain size appears to still be broken.
This will help not to meet confusing errors.
In issue #5873, the error was "expected constant expr for vector length: Can't cast str to int".
It was originally "expected constant expr for vector length: Non-constant path in constant expr" (though still invalid error).
This patch make the original error to be printed.
This patch is a sledge hammer that moves all tests into `#[cfg(test)] mod test { .. }`, and makes them private, there were several instances of `pub mod tests { #[test] pub fn ... } `.
(The reason for this is I was playing with using `syntax` to index code ([result so far](http://www.ug.it.usyd.edu.au/~hwil7821/rust-api/)) and it was getting some junk from the tests.)
The rustdoc commit is particularly brutal, so it's fine if that one isn't landed.
Closes#5487, #1913, and #4568
I tracked this by adding all used unsafe blocks/functions to a set on the `tcx` passed around, and then when the lint pass comes around if an unsafe block/function isn't listed in that set, it's unused.
I also removed everything from the compiler that was unused, and up to stage2 is now compiling without any known unused unsafe blocks.
I chose `unused_unsafe` as the name of the lint attribute, but there may be a better name...
This will help not to meet confusing errors.
In issue #5873, the error was "expected constant expr for vector length: Can't cast str to int".
It was originally "expected constant expr for vector length: Non-constant path in constant expr"
This patch make the original error to be printed.
This takes care of one of the last remnants of assumptions about enum layout. A type visitor is now passed a function to read a value's discriminant, then accesses fields by being passed a byte offset for each one. The latter may not be fully general, despite the constraints imposed on representations by borrowed pointers, but works for any representations currently planned and is relatively simple.
Closes#5652.
This implements #5158. Currently it takes the command line args and the crate map. Since it doesn't take a `main` function pointer, you can't actually start the runtime easily, but that seems to be a shim to allow the current `rust_start` function to call into main.
However, you can do an end-run round the io library and do this:
```rust
use core::libc::{write, c_int, c_void, size_t, STDOUT_FILENO};
#[start]
fn my_start(_argc:int, _argv: **u8, _crate_map: *u8) -> int {
do str::as_buf("Hello World!\n") |s,len| {
unsafe {
write(STDOUT_FILENO, s as *c_void, len as size_t);
}
}
return 0;
}
```
Which is the most basic "Hello World" you can do in rust without starting up the runtime (though that has quite a lot to do with the fact that `core::io` uses `@` everywhere...)
Good morning,
This first patch series adds support for `#[deriving(Decodable, Encodable)]`, but does not yet remove `#[auto_encode]` and `#[auto_decode]`. I need a snapshot to remove the old code. Along the way it also extends support for tuple structs and struct enum variants.
Also, it includes a minor fix to the pretty printer. We decided a while ago to use 4 spaces to indent a match arm instead of 2. This updates the pretty printer to reflect that.
