bors [Tue, 18 Aug 2015 04:23:25 +0000 (04:23 +0000)]
Auto merge of #27823 - eefriedman:float-dep-core, r=alexcrichton
There wasn't any particular reason the functions needed to be there
anyway, so just get rid of them, and adjust libstd to compensate.
With this change, libcore depends on exactly two floating-point functions:
fmod and fmodf. They are implicitly referenced because they are used to
implement "%".
bors [Tue, 18 Aug 2015 02:02:57 +0000 (02:02 +0000)]
Auto merge of #27474 - bluss:twoway-reverse, r=brson
StrSearcher: Implement the complete reverse case for the two way algorithm
Fix quadratic behavior in StrSearcher in reverse search with periodic
needles.
This commit adds the missing pieces for the "short period" case in
reverse search. The short case will show up when the needle is literally
periodic, for example "abababab".
Two way uses a "critical factorization" of the needle: x = u v.
Searching matches v first, if mismatch at character k, skip k forward.
Matching u, if mismatch, skip period(x) forward.
To avoid O(mn) behavior after mismatch in u, memorize the already
matched prefix.
The short period case requires that |u| < period(x).
For the reverse search we need to compute a different critical
factorization x = u' v' where |v'| < period(x), because we are searching
for the reversed needle. A short v' also benefits the algorithm in
general.
The reverse critical factorization is computed quickly by using the same
maximal suffix algorithm, but terminating as soon as we have a location
with local period equal to period(x).
This adds extra fields crit_pos_back and memory_back for the reverse
case. The new overhead for TwoWaySearcher::new is low, and additionally
I think the "short period" case is uncommon in many applications of
string search.
The maximal_suffix methods were updated in documentation and the
algorithms updated to not use !0 and wrapping add, variable left is now
1 larger, offset 1 smaller.
Use periodicity when computing byteset: in the periodic case, just
iterate over one period instead of the whole needle.
Example before (rfind) after (twoway_rfind) benchmark shows the removal
of quadratic behavior.
bors [Mon, 17 Aug 2015 23:41:36 +0000 (23:41 +0000)]
Auto merge of #27169 - huonw:simd, r=alexcrichton
This implements https://github.com/rust-lang/rfcs/pull/1199 (except for doing all the platform intrinsics).
Things remaining for SIMD (not necessarily in this PR):
- [x] I (@huonw) am signed up to ensure the compiler matches the RFC, when it lands
- [x] the platform specific intrinsics aren't properly type checked at the moment (LLVM will throw a "random" assertion)
- [ ] there's a lot of useful intrinsics that are missing, including whole platforms (mips, powerpc)
- [ ] the target-feature `cfg` detection/adding is not so great at the moment
- [x] I think the platform specific intrinsics should go in their own `extern` ABI (i.e. not `"rust-intrinsic"`)
(I'm adjusting the RFC to reflect the latter.)
I think it would be very nice for this to land without requiring the RFC to land first, because of the first point, and because this is the only way for any further work to happen/be experimented with, without requiring people to build/install/multirust a compiler from a custom branch.
Huon Wilson [Thu, 6 Aug 2015 18:11:26 +0000 (11:11 -0700)]
Create "platform-intrinsic" ABI for SIMD/platform intrinsics.
This is purposely separate to the "rust-intrinsic" ABI, because these
intrinsics are theoretically going to become stable, and should be fine
to be independent of the compiler/language internals since they're
intimately to the platform.
Huon Wilson [Tue, 14 Jul 2015 00:10:44 +0000 (17:10 -0700)]
feature gate `cfg(target_feature)`.
This is theoretically a breaking change, but GitHub search turns up no
uses of it, and most non-built-in cfg's are passed via cargo features,
which look like `feature = "..."`, and hence can't overlap.
Eli Friedman [Sun, 16 Aug 2015 07:42:53 +0000 (00:42 -0700)]
Remove dependencies on libm functions from libcore.
There wasn't any particular reason the functions needed to be there
anyway, so just get rid of them, and adjust libstd to compensate.
With this change, libcore depends on exactly two floating-point functions:
fmod and fmodf. They are implicitly referenced because they are
used to implement "%".
bors [Sun, 16 Aug 2015 14:50:52 +0000 (14:50 +0000)]
Auto merge of #27689 - dotdash:die_odr, r=michaelwoerister
When using a generic enum type that was defined in an external crate,
our debuginfo currently claims that the concrete type (e.g. Option<i32>)
was defined in the current crate, where it was first used.
This means that if there are multiple crates that all use, for example,
Option<i32> values, they'll have conflicting debuginfo, each crate
claiming to have defined that type. This doesn't cause problems in
regular builds, but with LTO enabled, LLVM complains because it tries to
merge the debuginfo for those types and sees the ODR violations.
Since I couldn't find a way to get the file info for the external crate
that actually defined the enum, I'm working around the issue by using
"<unknown>" as the file for enum types. We'll want to re-visit and fix
this later, but this at least this fixes the ICE. And with the file
being unknown instead of wrong, the debuginfo isn't really worse than
before either.
bors [Sun, 16 Aug 2015 05:10:23 +0000 (05:10 +0000)]
Auto merge of #27818 - alexcrichton:tag-all-the-issues, r=aturon
This commit turns `#[unstable]` attributes missing an `issue` annotation into a hard error. This will require the libs team to ensure that there's a tracking issue for all unstable features in the standard library.
All existing unstable features have had issues created and they've all been updated. Yay!
bors [Sun, 16 Aug 2015 02:25:36 +0000 (02:25 +0000)]
Auto merge of #27851 - nikomatsakis:cleanup-ty-decoder, r=eddyb
Just a little code cleanup I was doing as part of another refactoring (which may turn out not to be needed). The main thrust of this is to cleanup the interface to `tydecode.rs` to be less ridiculously repetitive. I also purged the generic "def-id conversion" parameter in favor of a trait object, just to reduce code duplication a bit and make the signatures a bit less messy. I measured the bootstrapping time to build stage2 with these changes, it was identical. (But it'd be easy enough to restore the unboxed closure if we wanted it.)
Alex Crichton [Thu, 13 Aug 2015 00:23:17 +0000 (17:23 -0700)]
syntax: Require issues for unstable features
This turns an `#[unstable]` tag without an `issue` annotation into a hard error
to ensure that we've always got a tracking issue for unstable features in the
standard library.
bors [Sat, 15 Aug 2015 19:10:40 +0000 (19:10 +0000)]
Auto merge of #27845 - dylanmckay:abstract-pointer-size-away, r=alexcrichton
This patch rewrites code in several places which assume that the current target has either 32-bit or 64-bit pointers so that it can support arbitrary-width pointers.
It does not completely remove all assumptions of pointer width, but it does reduce them significantly. There is a discussion [here](https://internals.rust-lang.org/t/adding-16-bit-pointer-support/2484/10) about the change.
Dylan McKay [Sat, 15 Aug 2015 09:06:06 +0000 (21:06 +1200)]
Improve 'unknown instrinsic' error message
If you had previously tried to get the ValueRef associated with an
intrinsic that hadn't been described in
`trans::context::declare_intrinsic()`, the compile would panic with
an empty message.
Now we print out details about the error in the panic message.
bors [Fri, 14 Aug 2015 22:52:11 +0000 (22:52 +0000)]
Auto merge of #27400 - alexcrichton:less-jemalloc, r=brson
This commit is an implementation of [RFC 1183][rfc] which allows swapping out
the default allocator on nightly Rust. No new stable surface area should be
added as a part of this commit.
Two new attributes have been added to the compiler:
* `#![needs_allocator]` - this is used by liballoc (and likely only liballoc) to
indicate that it requires an allocator crate to be in scope.
* `#![allocator]` - this is a indicator that the crate is an allocator which can
satisfy the `needs_allocator` attribute above.
The ABI of the allocator crate is defined to be a set of symbols that implement
the standard Rust allocation/deallocation functions. The symbols are not
currently checked for exhaustiveness or typechecked. There are also a number of
restrictions on these crates:
* An allocator crate cannot transitively depend on a crate that is flagged as
needing an allocator (e.g. allocator crates can't depend on liballoc).
* There can only be one explicitly linked allocator in a final image.
* If no allocator is explicitly requested one will be injected on behalf of the
compiler. Binaries and Rust dylibs will use jemalloc by default where
available and staticlibs/other dylibs will use the system allocator by
default.
Two allocators are provided by the distribution by default, `alloc_system` and
`alloc_jemalloc` which operate as advertised.
Alex Crichton [Thu, 25 Jun 2015 17:07:01 +0000 (10:07 -0700)]
rustc: Allow changing the default allocator
This commit is an implementation of [RFC 1183][rfc] which allows swapping out
the default allocator on nightly Rust. No new stable surface area should be
added as a part of this commit.
Two new attributes have been added to the compiler:
* `#![needs_allocator]` - this is used by liballoc (and likely only liballoc) to
indicate that it requires an allocator crate to be in scope.
* `#![allocator]` - this is a indicator that the crate is an allocator which can
satisfy the `needs_allocator` attribute above.
The ABI of the allocator crate is defined to be a set of symbols that implement
the standard Rust allocation/deallocation functions. The symbols are not
currently checked for exhaustiveness or typechecked. There are also a number of
restrictions on these crates:
* An allocator crate cannot transitively depend on a crate that is flagged as
needing an allocator (e.g. allocator crates can't depend on liballoc).
* There can only be one explicitly linked allocator in a final image.
* If no allocator is explicitly requested one will be injected on behalf of the
compiler. Binaries and Rust dylibs will use jemalloc by default where
available and staticlibs/other dylibs will use the system allocator by
default.
Two allocators are provided by the distribution by default, `alloc_system` and
`alloc_jemalloc` which operate as advertised.
bors [Fri, 14 Aug 2015 15:26:09 +0000 (15:26 +0000)]
Auto merge of #27641 - nikomatsakis:soundness-rfc-1214, r=nrc
This PR implements the majority of RFC 1214. In particular, it implements:
- the new outlives relation
- comprehensive WF checking
For the most part, new code receives warnings, not errors, though 3 regressions were found via a crater run.
There are some deviations from RFC 1214. Most notably:
- we still consider implied bounds from fn ret; this intersects other soundness issues that I intend to address in detail in a follow-up RFC. Fixing this without breaking a lot of code probably requires rewriting compare-method somewhat (which is probably a good thing).
- object types do not check trait bounds for fear of encountering `Self`; this was left as an unresolved question in RFC 1214, but ultimately feels inconsistent.
Both of those two issues are highlighted in the tracking issue, https://github.com/rust-lang/rust/issues/27579. #27579 also includes a testing matrix with new tests that I wrote -- these probably duplicate some existing tests, I tried to check but wasn't quite sure what to look for. I tried to be thorough in testing the WF relation, at least, but would welcome suggestions for missing tests.
projects / rust.git / log