Currently, cleanup blocks are only reused when there are nested scopes, the
child scope's cleanup block will terminate with a jump to the parent
scope's cleanup block. But within a single scope, adding or revoking
any cleanup will force a fresh cleanup block. This means quadratic
growth with the number of allocations in a scope, because each
allocation needs a landing pad.
Instead of forcing a fresh cleanup block, we can keep a list chained
cleanup blocks that form a prefix of the currently required cleanups.
That way, the next cleanup block only has to handle newly added
cleanups. And by keeping the whole list instead of just the latest
block, we can also handle revocations more efficiently, by only
dropping those blocks that are no longer required, instead of all of
them.
Reduces the size of librustc by about 5% and the time required to build
it by about 10%.
Currently, cleanup blocks are only reused when there are nested scopes, the
child scope's cleanup block will terminate with a jump to the parent
scope's cleanup block. But within a single scope, adding or revoking
any cleanup will force a fresh cleanup block. This means quadratic
growth with the number of allocations in a scope, because each
allocation needs a landing pad.
Instead of forcing a fresh cleanup block, we can keep a list chained
cleanup blocks that form a prefix of the currently required cleanups.
That way, the next cleanup block only has to handle newly added
cleanups. And by keeping the whole list instead of just the latest
block, we can also handle revocations more efficiently, by only
dropping those blocks that are no longer required, instead of all of
them.
Reduces the size of librustc by about 5% and the time required to build
it by about 10%.
Moves all the remaining functions that could reasonably be methods to be methods, except for some FFI ones (which I believe @erickt is working on, possibly) and `each_split_within`, since I'm not really sure the details of it (I believe @kimundi wrote the current implementation, so maybe he could convert it to an external iterator method on `StrSlice`, e.g. `word_wrap_iter(&self) -> WordWrapIterator<'self>`, where `WordWrapIterator` impls `Iterator<&'self str>`. It probably won't be too hard, since it's already a state machine.)
This also cleans up the comparison impls for the string types, except I'm not sure how the lang items `eq_str` and `eq_str_uniq` need to be handled, so they (`eq_slice` and `eq`) remain stand-alone functions.
Remove all the explicit @mut-fields from CrateContext, though many
fields are still @-ptrs.
This required changing every single function call that explicitly
took a @CrateContext, so I took advantage and changed as many as I
could get away with to &-ptrs or &mut ptrs.
Currently, when calling glue functions, we cast the function to match
the argument type. This interacts very badly with LLVM and breaks
inlining of the glue code.
It's more efficient to use a unified function type for the glue
functions and always cast the function argument instead of the function.
The resulting code for rustc is about 13% faster (measured up to and
including the "trans" pass) and the resulting librustc is about 5%
smaller.
This un-reverts the reverts of the rusti commits made awhile back. These were reverted for an LLVM failure in rustpkg. I believe that this is not a problem with these commits, but rather that rustc is being used in parallel for rustpkg tests (in-process). This is not working yet (almost! see #7011), so I serialized all the tests to run one after another.
@brson, I'm mainly just guessing as to the cause of the LLVM failures in rustpkg tests. I'm confident that running tests in parallel is more likely to be the problem than those commits I made.
Additionally, this fixes two recently reported issues with rusti.
The lookups for these items in external crates currently cause repeated
decoding of the EBML metadata, which is pretty slow. Adding caches to
avoid the repeated decoding reduces the time required for the type
checking of librustc by about 25%.
This fixes the strange random crashes in compile-fail tests.
This reverts commit 96cd61ad03.
Conflicts:
src/librustc/driver/driver.rs
src/libstd/str.rs
src/libsyntax/ext/quote.rs
This almost removes the StringRef wrapper, since all strings are
Equiv-alent now. Removes a lot of `/* bad */ copy *`'s, and converts
several things to be &'static str (the lint table and the intrinsics
table).
There are many instances of .to_managed(), unfortunately.
There are now only half-a-dozen or so functions left `std::str` that should be methods.
Highlights:
- `.substr` was removed, since most of the uses of it in the code base were actually incorrect (it had a weird mixing of a byte index and a unicode character count), adding `.slice_chars` if one wants to handle characters, and the normal `.slice` method to handle bytes.
- Code duplication between the two impls for `connect` and `concat` was removed via a new `Str` trait, that is purely designed to allow an explicit -> `&str` conversion (`.as_slice()`)
- Deconfuse the 5 different functions for converting to `[u8]` (3 of which had actually incorrect documentation: implying that they didn't have the null terminator), into 3: `as_bytes` (all strings), `as_bytes_with_null` (`&'static str`, `@str` and `~str`) and `as_bytes_with_null_consume` (`~str`). None of these allocate, unlike the old versions.
(cc @thestinger)
The confusing mixture of byte index and character count meant that every
use of .substr was incorrect; replaced by slice_chars which only uses
character indices. The old behaviour of `.substr(start, n)` can be emulated
via `.slice_from(start).slice_chars(0, n)`.
This was a lot more painful than just changing `x.each` to `x.iter().advance` . I ran into my old friend #5898 and had to add underscores to some method names as a temporary workaround.
The borrow checker also had other ideas because rvalues aren't handled very well yet so temporary variables had to be added. However, storing the temporary in a variable led to dynamic `@mut` failures, so those had to be wrapped in blocks except where the scope ends immediately.
Anyway, the ugliness will be fixed as the compiler issues are fixed and this change will amount to `for x.each |x|` becoming `for x.iter |x|` and making all the iterator adaptors available.
I dropped the run-pass tests for `old_iter` because there's not much point in fixing a module that's on the way out in the next week or so.
For types that are passed by value, we can't just cast the value to a
pointer, but have to use an alloca and copy the value there. This
handling is already present for all other arguments, but was missing
for "self".
Fixes#6682, #4850 and #4878
The `callee_id` in `ast::expr` in only used in a couple expression variants. This moves the `callee_id` into those branches to make it more clear when its should be used.
Also, it fixes a bug in a std::run test when there is a symlink in the path rust where was checked out.
Fix a laundry list of warnings involving unused imports that glutted
up compilation output. There are more, but there seems to be some
false positives (where 'remedy' appears to break the build), but this
particular set of fixes seems safe.
Fix a laundry list of warnings involving unused imports that glutted
up compilation output. There are more, but there seems to be some
false positives (where 'remedy' appears to break the build), but this
particular set of fixes seems safe.
Fix for #6575. In the trans phase, rustc emits code for a function parameter that goes completely unused in the event the return type of the function in question happens to be an immediate.
This patch modifies rustc & parts of rustrt to ensure that the vestigial parameter is no longer present in compiled code.
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?
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.
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.
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.
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.
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?
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
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.
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.
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).
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.
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.
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.
