auto merge of #17349 : aturon/rust/rt-experimental, r=alexcrichton
The `std::rt` module was marked `unstable` [a while back](https://github.com/rust-lang/rust/commit/b6d4d117f4c2770649c7ddc2ad9ad4ce4c3b13b1), and this change was not reverted when we moved to an `experimental` baseline for `std`.
auto merge of #16377 : pcwalton/rust/associated-items, r=nikomatsakis
This is waiting on an RFC, but this basic functionality should be
straightforward. The implementation essentially desugars during type
collection and AST type conversion time into the parameter scheme we
have now.
Patrick Walton [Wed, 6 Aug 2014 02:44:21 +0000 (19:44 -0700)]
librustc: Implement associated types behind a feature gate.
The implementation essentially desugars during type collection and AST
type conversion time into the parameter scheme we have now. Only fully
qualified names--e.g. `<T as Foo>::Bar`--are supported.
auto merge of #17331 : kballard/rust/rust_log_pattern_inverted, r=alexcrichton
RUST_LOG supports regex filtering of log messages with a syntax like
`RUST_LOG=main/foo` to use the regex filter 'foo'. Unfortunately, the
filter was inverted, so `RUST_LOG=main/foo` would actually show all
messages except the ones containing 'foo'.
Kevin Ballard [Wed, 17 Sep 2014 01:16:19 +0000 (18:16 -0700)]
Fix the inverted RUST_LOG filter
RUST_LOG supports regex filtering of log messages with a syntax like
`RUST_LOG=main/foo` to use the regex filter 'foo'. Unfortunately, the
filter was inverted, so `RUST_LOG=main/foo` would actually show all
messages except the ones containing 'foo'.
The `std::rt` module was marked `unstable` [a while
back](https://github.com/rust-lang/rust/commit/b6d4d117f4c2770649c7ddc2ad9ad4ce4c3b13b1),
and this change was not reverted when we moved to an `experimental`
baseline for `std`.
auto merge of #17264 : bkoropoff/rust/issue-17252, r=nick29581
Recursive items are currently detected in the `check_const` pass which runs after type checking. This means a recursive static item used as an array length will cause type checking to blow the stack. This PR separates the recursion check out into a separate pass which is run before type checking.
auto merge of #17268 : aturon/rust/mut-conventions, r=alexcrichton
As per [RFC 52](https://github.com/rust-lang/rfcs/blob/master/active/0052-ownership-variants.md), use `_mut` suffixes to mark mutable variants, and `into_iter` for moving iterators. Additional details and motivation in the RFC.
Note that the iterator *type* names are not changed by this RFC; those are awaiting a separate RFC for standardization.
As per [RFC
52](https://github.com/rust-lang/rfcs/blob/master/active/0052-ownership-variants.md),
use `_mut` suffixes to mark mutable variants, and `into_iter` for moving
iterators.
Niko Matsakis [Thu, 14 Aug 2014 22:05:27 +0000 (18:05 -0400)]
Generalize lifetime bounds on type parameters to support multiple
lifetime bounds. This doesn't really cause any difficulties, because
we already had to accommodate the fact that multiple implicit bounds
could accumulate. Object types still require precisely one lifetime
bound. This is a pre-step towards generalized where clauses (once you
have lifetime bounds in where clauses, it is harder to restrict them
to exactly one).
auto merge of #17197 : nikomatsakis/rust/issue-5527-trait-reform-revisited, r=pcwalton
This patch does not make many functional changes, but does a lot of restructuring towards the goals of #5527. This is the biggest patch, basically, that should enable most of the other patches in a relatively straightforward way.
Major changes:
- Do not track impls through trans, instead recompute as needed.
- Isolate trait matching code into its own module, carefully structure to distinguish various phases (selection vs confirmation vs fulfillment)
- Consider where clauses in their more general form
- Integrate checking of builtin bounds into the trait matching process, rather than doing it separately in kind.rs (important for opt-in builtin bounds)
What is not included:
- Where clauses are still not generalized. This should be a straightforward follow-up patch.
- Caching. I did not include much caching. I have plans for various kinds of caching we can do. Should be straightforward. Preliminary perf measurements suggested that this branch keeps compilation times roughly what they are.
- Method resolution. The initial algorithm I proposed for #5527 does not work as well as I hoped. I have a revised plan which is much more similar to what we do today.
- Deref vs deref-mut. The initial fix I had worked great for autoderef, but not for explicit deref.
- Permitting blanket impls to overlap with specific impls. Initial plan to consider all nested obligations before considering an impl to match caused many compilation errors. We have a revised plan but it is not implemented here, should be a relatively straightforward extension.
auto merge of #17232 : untitaker/rust/patch-1, r=alexcrichton
The wording is correct if you consider that two of these lines were extracted from the original example. It still tripped me up while reading, so i just removed any reference to the linecount.
This closes #17260. The guide references the old install location for
the windows rust install before it was split into 64bit and 32bit
installers. This adds a link to each binary.
auto merge of #17288 : alexcrichton/rust/change-snap, r=brson
I'm rotating in some CentOS 5.10 bots so we *actually* build on Linux 2.6.18
like we advertise doing so. Currently the snapshots are incompatible with CentOS
5.10 due to snapshots requiring glibc 2.6 and CentOS 5.10 having glibc 2.5.
It turns out that rustc only requires *one* symbol from glibc 2.6, which is
`futimens`. The rust distribution itself does not use this symbol, but LLVM
conditionally detects it and then uses it. This symbol isn't even called as part
of the compilation process, so we don't even need it!
The new snapshot was generated following these instructions [1]:
1. Download the current x86_64 linux snapshot and unpack it.
2. Open the rustc binary in a hex editor.
3. Change the linkage against glibc 2.6 from strong to *weak*
4. Write changes and re-run src/etc/make-snapshot.py
5. Upload new tarball to S3
On CentOS 5.10 a warning is printed each time the snapshot runs that the symbol
cannot be found (anyone with glibc 2.6+ does not have this warning printed). The
key part is that we can *bootstrap* on CentOS 5.10 at this point. The next
snapshot will be naturally compatible with glibc 2.3 (even older!) and will not
need to be manually edited.
Alex Crichton [Mon, 15 Sep 2014 18:17:00 +0000 (11:17 -0700)]
Change the last linux 64-bit snapshot
I'm rotating in some CentOS 5.10 bots so we *actually* build on Linux 2.6.18
like we advertise doing so. Currently the snapshots are incompatible with CentOS
5.10 due to snapshots requiring glibc 2.6 and CentOS 5.10 having glibc 2.5.
It turns out that rustc only requires *one* symbol from glibc 2.6, which is
`futimens`. The rust distribution itself does not use this symbol, but LLVM
conditionally detects it and then uses it. This symbol isn't even called as part
of the compilation process, so we don't even need it!
The new snapshot was generated following these instructions [1]:
1. Download the current x86_64 linux snapshot and unpack it.
2. Open the rustc binary in a hex editor.
3. Change the linkage against glibc 2.6 from strong to *weak*
4. Write changes and re-run src/etc/make-snapshot.py
5. Upload new tarball to S3
On CentOS 5.10 a warning is printed each time the snapshot runs that the symbol
cannot be found (anyone with glibc 2.6+ does not have this warning printed). The
key part is that we can *bootstrap* on CentOS 5.10 at this point. The next
snapshot will be naturally compatible with glibc 2.3 (even older!) and will not
need to be manually edited.
Brian Anderson [Mon, 15 Sep 2014 20:40:30 +0000 (13:40 -0700)]
mk: Update how the build deals with version labels. #16677
Adds a new configure flag, --release-channel, which determines how the version
number should be augmented with a release label, as well as how the distribution
artifacts will be named. This is entirely for use by the build automation.
--release-channel can be either 'source', 'nightly', 'beta', or 'stable'.
Here's a summary of the affect of these values on version number and
artifact naming, respectively:
auto merge of #17221 : bkoropoff/rust/strinterner-unsafe, r=sfackler
The `StrInterner::clear()` method takes self immutably but can invalidate references returned by `StrInterner::get_ref`. Since `get_ref` is unused, just remove it.
Daniel Micay [Mon, 15 Sep 2014 19:37:01 +0000 (15:37 -0400)]
heap: optimize EMPTY to avoid relocations
Sized deallocation makes it pointless to provide an address that never
overlaps with pointers returned by an allocator. Code can branch on the
capacity of the allocation instead of a comparison with this sentinel.
This improves the situation in #8859, and the remaining issues are only
from the logging API, which should be disabled by default in optimized
release builds anyway along with debug assertions. The remaining issues
are part of #17081.
Niko Matsakis [Fri, 12 Sep 2014 15:47:33 +0000 (11:47 -0400)]
typeck/kind -- stop using old trait framework.
- Unify the "well-formedness" checking that typeck was already doing with what
was taking place in kind.
- Move requirements that things be sized into typeck.
- I left the checking on upvars in kind, though I think it should eventually be
refactored into regionck (which would perhaps be renamed).
This reflects a general plan to convert typeck so that it registers
obligations or other pending things for conditions it cannot check
eventually. This makes it easier to identify all the conditions that
apply to an AST expression, but can also influence inference in somec
cases (e.g., `Send` implies `'static`, so I already had to promote a lot
of the checking that `kind.rs` was doing into typeck, this branch just
continues the process).
projects / rust.git / log