bors [Sun, 28 Dec 2014 03:11:48 +0000 (03:11 +0000)]
auto merge of #20136 : eddyb/rust/format-args, r=alexcrichton
We have the technology: no longer do you need to write closures to use `format_args!`.
This is a `[breaking-change]`, as it forces you to clean up old hacks - if you had code like this:
```rust
format_args!(fmt::format, "{} {} {}", a, b, c)
format_args!(|args| { w.write_fmt(args) }, "{} {} {}", x, y, z)
```
change it to this:
```rust
fmt::format(format_args!("{} {} {}", a, b, c))
w.write_fmt(format_args!("{} {} {}", x, y, z))
```
To allow them to be called with `format_args!(...)` directly, several functions were modified to
take `fmt::Arguments` by value instead of by reference. Also, `fmt::Arguments` derives `Copy`
now in order to preserve all usecases that were previously possible.
* Rename `to_ascii_{lower,upper}` to `to_ascii_{lower,upper}case`, per #14401
* Remove the `Ascii` type and associated traits: `AsciiCast`, `OwnedAsciiCast`, `AsciiStr`, `IntoBytes`, and `IntoString`.
* As a replacement, add `.is_ascii()` to `AsciiExt`, and implement `AsciiExt` for `u8` and `char`.
bors [Sat, 27 Dec 2014 15:28:36 +0000 (15:28 +0000)]
auto merge of #20244 : japaric/rust/bc-no-move, r=nikomatsakis
closes #19141
closes #20193
closes #20228
---
Currently whenever we encounter `let f = || {/* */}`, we *always* type check the RHS as a *boxed* closure. This is wrong when the RHS is `move || {/* */}` (because boxed closures can't capture by value) and generates all sort of badness during trans (see issues above). What we *should* do is always type check `move || {/* */}` as an *unboxed* closure, but ~~I *think* (haven't tried)~~ (2) this is not feasible right now because we have a limited form of kind (`Fn` vs `FnMut` vs `FnOnce`) inference that only works when there is an expected type (1).
In this PR, I've chosen to generate a type error whenever `let f = move || {/* */}` is encountered. The error asks the user to annotate the kind of the unboxed closure (e.g. `move |:| {/* */}`). Once annotated, the compiler will type check the RHS as an unboxed closure which is what the user wants.
r? @nikomatsakis
(1) AIUI it only triggers in this scenario:
``` rust
fn is_uc<F>(_: F) where F: FnOnce() {}
fn main() {
is_uc(|| {}); // type checked as unboxed closure with kind `FnOnce`
}
```
(2) I checked, and it's not possible because `check_unboxed_closure` expects a `kind` argument, but we can't supply that argument in this case (i.e. `let f = || {}`, what's the kind?). We could force the `FnOnce` kind in that case, but that's ad hoc. We should try to infer the kind depending on how the closure is used afterwards, but there is no inference mechanism to do that (at least, not right now).
bors [Sat, 27 Dec 2014 13:11:48 +0000 (13:11 +0000)]
auto merge of #20119 : FlaPer87/rust/oibit-send-and-friends, r=nikomatsakis
More work on opt-in built in traits. `Send` and `Sync` are not opt-in, `OwnedPtr` renamed to `UniquePtr` and the `Send` and `Sync` traits are now unsafe.
NOTE: This likely needs to be rebased on top of the yet-to-land snapshot.
bors [Sat, 27 Dec 2014 06:58:35 +0000 (06:58 +0000)]
auto merge of #20158 : nikomatsakis/rust/fn-inference-refactor, r=eddyb
Various refactorings simplifying the mem-categorization and regionck interface. This is working towards an improvement for closure-and-upvar-mode inference.
Nick Cameron [Sun, 23 Nov 2014 09:29:41 +0000 (22:29 +1300)]
save-analysis: emit names of items that a glob import actually imports.
There is also some work here to make resolve a bit more stable - it no longer overwrites a specific import with a glob import.
[breaking-change]
Import shadowing of single/list imports by globs is now forbidden. An interesting case is where a glob import imports a re-export (`pub use`) of a single import. This still counts as a single import for the purposes of shadowing .You can usually fix any bustage by re-ordering such imports. A single import may still shadow (override) a glob import or the prelude.
bors [Fri, 26 Dec 2014 06:31:47 +0000 (06:31 +0000)]
auto merge of #20218 : alexcrichton/rust/jemalloc-sections, r=luqmana
It's quite possible that small programs don't use all of jemalloc, and building
with -ffunction-sections and -fdata-sections allows the linker (via
--gc-sections) to strip out all unused code at link time. This decreases the
size of a "hello world" executable for me from 716K to 482K with no measurable
impact on link time. After this patch jemalloc is still the largest portion of
our hello world executables, but this helps cut down on the size at least
somewhat!
bors [Thu, 25 Dec 2014 18:01:36 +0000 (18:01 +0000)]
auto merge of #20180 : jroesch/rust/clean-where-predicate, r=alexcrichton
Add support for all variants of ast::WherePredicate in clean/mod.rs. Fixes #20048, but will need modification when EqualityPredicates are fully implemented in #20041.
bors [Thu, 25 Dec 2014 14:21:47 +0000 (14:21 +0000)]
auto merge of #20167 : michaelwoerister/rust/for-loop-var, r=alexcrichton
... really this time `:)`
I went for the simpler fix after all since it turned out to become a bit too complicated to extract the current iteration value from its containing `Option` with the different memory layouts it can have. It's also what we already do for match bindings.
I also extended the new test case to include the "simple identifier" case.
Alex Crichton [Thu, 25 Dec 2014 04:20:01 +0000 (20:20 -0800)]
mk: Build jemalloc with -ffunction-sections
It's quite possible that small programs don't use all of jemalloc, and building
with -ffunction-sections and -fdata-sections allows the linker (via
--gc-sections) to strip out all unused code at link time. This decreases the
size of a "hello world" executable for me from 716K to 482K with no measurable
impact on link time. After this patch jemalloc is still the largest portion of
our hello world executables, but this helps cut down on the size at least
somewhat!
bors [Thu, 25 Dec 2014 01:01:42 +0000 (01:01 +0000)]
auto merge of #19934 : tomjakubowski/rust/rustdoc-unboxed-closures-redux, r=alexcrichton
We render HRTB and the unboxed closure trait sugar (the so-called
"parenthesized" notation) where appropriate. Also address the new
`for` syntax on the old closures.
bors [Wed, 24 Dec 2014 20:47:12 +0000 (20:47 +0000)]
auto merge of #20117 : lfairy/rust/rename-include-bin, r=alexcrichton
According to [RFC 344][], methods that return `&[u8]` should have names ending in `bytes`. Though `include_bin!` is a macro not a method, it seems reasonable to follow the convention anyway.
We keep the old name around for now, but trigger a deprecation warning when it is used.
bors [Wed, 24 Dec 2014 18:37:07 +0000 (18:37 +0000)]
auto merge of #19813 : barosl/rust/autoderef-type-inference-ice, r=pnkfelix
`check::autoderef()` returns a `ty_err` when it fails to infer the type. `probe::probe()` should respect this failure and fail together to prevent further corruption.
bors [Wed, 24 Dec 2014 16:21:23 +0000 (16:21 +0000)]
auto merge of #20060 : Aatch/rust/enum-repr, r=alexcrichton
The previous behaviour of using the smallest type possible caused LLVM
to treat padding too conservatively, causing poor codegen. This commit
changes the behaviour to use an alignment-sized integer as the
discriminant. This keeps types the same size, but helps LLVM understand
the data structure a little better, resulting in better codegen.
Jared Roesch [Tue, 23 Dec 2014 09:08:00 +0000 (01:08 -0800)]
Support all variants of WherePredicate
Adds support for all variants of ast::WherePredicate in clean/mod.rs. Fixes #20048, but will need modification when EqualityPredicates are fully implemented in #20041.
Chris Wong [Sun, 21 Dec 2014 21:57:09 +0000 (10:57 +1300)]
Rename include_bin! to include_bytes!
According to [RFC 344][], methods that return `&[u8]` should have names
ending in `bytes`. Though `include_bin!` is a macro not a method, it
seems reasonable to follow the convention anyway.
We keep the old name around for now, but trigger a deprecation warning
when it is used.
James Miller [Sat, 20 Dec 2014 05:53:37 +0000 (18:53 +1300)]
Use type-alignment-sized integer for discriminant types
The previous behaviour of using the smallest type possible caused LLVM
to treat padding too conservatively, causing poor codegen. This commit
changes the behaviour to use an type-alignment-sized integer as the
discriminant. This keeps types the same size, but helps LLVM understand
the data structure a little better, resulting in better codegen.