bors [Mon, 21 Dec 2015 23:31:06 +0000 (23:31 +0000)]
Auto merge of #30434 - alexcrichton:update-jemalloc, r=alexcrichton
It's been awhile since we last updated jemalloc, and there's likely some bugs
that have been fixed since the last version we're using, so let's try to update
again.
Alex Crichton [Thu, 17 Dec 2015 07:06:00 +0000 (23:06 -0800)]
std: Update jemalloc version
It's been awhile since we last updated jemalloc, and there's likely some bugs
that have been fixed since the last version we're using, so let's try to update
again.
bors [Mon, 21 Dec 2015 07:49:05 +0000 (07:49 +0000)]
Auto merge of #30413 - pnkfelix:fsk-span_note, r=Manishearth
Add note when item accessed from module via `m.i` rather than `m::i`.
(I tried to make this somewhat future-proofed, in that the `UnresolvedNameContext` could be expanded in the future with other cases besides paths that are known to be modules.)
This supersedes PR #30356 ; since I'm responsible for a bunch of new code here, someone else should review it. :)
bors [Mon, 21 Dec 2015 04:15:28 +0000 (04:15 +0000)]
Auto merge of #30493 - semarie:openbsd-cc, r=alexcrichton
this PR reverts previous ones, that tried to make `cc` to found `estdc++` in `/usr/local/lib`. It causes more trouble than it resolvs things: rustc become unbuildable if another version already exists in `/usr/local` (for example, `libstd-xxxx.so` is found in `/usr/local/lib` and in builddir).
so this PR tries another way to achieve build, but using the good linker for building. By default, rustc use `cc` for linking. But under OpenBSD, `cc` is gcc 4.2.1 from base, whereas we build with gcc 4.9 from ports. By linking using the compiler found at compile-time, we ensure that the compiler will found his own stdc++ library without trouble.
Sébastien Marie [Sat, 19 Dec 2015 17:00:23 +0000 (18:00 +0100)]
openbsd: use specific linker for building
By default, rustc use `cc` as linker. Under OpenBSD, `cc` is gcc version 4.2.1.
So use the compiler found at configure-time for linking: it will be gcc 4.9.
It permits to resolv problem of finding -lestdc++ or -lgcc. For base gcc (4.2), there are in not standard path, whereas for ports gcc (4.9) there are in standard path.
bors [Sat, 19 Dec 2015 23:21:12 +0000 (23:21 +0000)]
Auto merge of #30430 - mmcco:master, r=alexcrichton
Rust already supports Linux's getrandom(2), which is very similar and
was based on getentropy(2). This is a pretty clean, simple addition that
uses the same approach as the iOS randomness API support.
bors [Sat, 19 Dec 2015 02:45:15 +0000 (02:45 +0000)]
Auto merge of #30184 - petrochenkov:ascr, r=nikomatsakis
This PR is a rebase of the original PR by @eddyb https://github.com/rust-lang/rust/pull/21836 with some unrebasable parts manually reapplied, feature gate added + type equality restriction added as described below.
This implementation is partial because the type equality restriction is applied to all type ascription expressions and not only those in lvalue contexts. Thus, all difficulties with detection of these contexts and translation of coercions having effect in runtime are avoided.
So, you can't write things with coercions like `let slice = &[1, 2, 3]: &[u8];`. It obviously makes type ascription less useful than it should be, but it's still much more useful than not having type ascription at all.
In particular, things like `let v = something.iter().collect(): Vec<_>;` and `let u = t.into(): U;` work as expected and I'm pretty happy with these improvements alone.
Part of https://github.com/rust-lang/rust/issues/23416
Rust already supports Linux's getrandom(2), which is very similar and
was based on getentropy(2). This is a pretty clean, simple addition that
uses the same approach as the iOS randomness API support.
bors [Fri, 18 Dec 2015 18:54:52 +0000 (18:54 +0000)]
Auto merge of #29973 - petrochenkov:privinpub, r=nikomatsakis
Some notes:
This patch enforces the rules from [RFC 136](https://github.com/rust-lang/rfcs/blob/master/text/0136-no-privates-in-public.md) and makes "private in public" a module-level concept and not crate-level. Only `pub` annotations are used by the new algorithm, crate-level exported node set produced by `EmbargoVisitor` is not used. The error messages are tweaked accordingly and don't use the word "exported" to avoid confusing people (https://github.com/rust-lang/rust/issues/29668).
The old algorithm tried to be extra smart with impls, but it mostly led to unpredictable behavior and bugs like https://github.com/rust-lang/rust/issues/28325.
The new algorithm tries to be as simple as possible - an impl is considered public iff its type is public and its trait is public (if presents).
A type or trait is considered public if all its components are public, [complications](https://internals.rust-lang.org/t/limits-of-type-inference-smartness/2919) with private types leaking to other crates/modules through trait impls and type inference are deliberately ignored so far.
The new algorithm is not recursive and uses the nice new facility `Crate::visit_all_items`!
Obsolete pre-1.0 feature `visible_private_types` is removed.
This is a [breaking-change].
The two main vectors of breakage are type aliases (https://github.com/rust-lang/rust/issues/28450) and impls (https://github.com/rust-lang/rust/issues/28325).
I need some statistics from a crater run (cc @alexcrichton) to decide on the breakage mitigation strategy.
UPDATE: All the new errors are reported as warnings controlled by a lint `private_in_public` and lint group `future_incompatible`, but the intent is to make them hard errors eventually.
Rollup merge of #30452 - dotdash:24876_take_2, r=alexcrichton
LLVM doesn't really support reusing the same module to emit more than
one file. One bug this causes is that the IR is invalidated by the stack
coloring pass when emitting the first file, and then the IR verifier
complains by the time we try to emit the second file. Also, we get
different binaries with --emit=asm,link than with just --emit=link. In
some cases leading to segfaults.
Unfortunately, it seems that at this point in time, the most sensible
option to circumvent this problem is to just clone the whole llvm module
for the asm output if we need both, asm and obj file output.
bors [Fri, 18 Dec 2015 12:23:54 +0000 (12:23 +0000)]
Auto merge of #30286 - oli-obk:const_error_span, r=nikomatsakis
previously the error was erased and a `non-const path` error was emitted at the location of the field access instead of at the overflow location (as can be seen in the playground: http://is.gd/EuAF5F )
Rollup merge of #30406 - durka:patch-13, r=sanxiyn
The previous example had no chance of compiling in either form, due to the restrictive follow set for `ty`. This one has the desired behavior: http://is.gd/kYdw4g (well, I don't exactly desire this behavior at all, but it's true at least :p )
Rollup merge of #30286 - oli-obk:const_error_span, r=nikomatsakis
previously the error was erased and a `non-const path` error was emitted at the location of the field access instead of at the overflow location (as can be seen in the playground: http://is.gd/EuAF5F )
Björn Steinbrink [Fri, 18 Dec 2015 00:24:40 +0000 (01:24 +0100)]
Fix emitting asm and object file output at the same time
LLVM doesn't really support reusing the same module to emit more than
one file. One bug this causes is that the IR is invalidated by the stack
coloring pass when emitting the first file, and then the IR verifier
complains by the time we try to emit the second file. Also, we get
different binaries with --emit=asm,link than with just --emit=link. In
some cases leading to segfaults.
Unfortunately, it seems that at this point in time, the most sensible
option to circumvent this problem is to just clone the whole llvm module
for the asm output if we need both, asm and obj file output.
bors [Fri, 18 Dec 2015 03:05:02 +0000 (03:05 +0000)]
Auto merge of #30414 - alexcrichton:fix-cross-builds, r=brson
It looks like #27937 accidentally switched the llvmdeps file from the target to
the host by accident, so be sure to use the right llvmdeps file which is built
for the target when building rustc_llvm
Steve Klabnik [Thu, 17 Dec 2015 19:47:14 +0000 (14:47 -0500)]
Rollup merge of #30439 - swooster:swooster-nomicon-patch-1, r=steveklabnik
The Rustonomicon's Lifetimes chapter uses the idiom "big ask", which is obscure compared to "tall order" (check [Google ngrams](https://books.google.com/ngrams/graph?content=big+ask%2C+tall+order&year_start=1800)). Also, it's easily mistaken for a typo; either "a big task" or "a big thing to ask" could plausibly work there.
projects / rust.git / log