bors [Thu, 30 Oct 2014 09:12:05 +0000 (09:12 +0000)]
auto merge of #18279 : bgamari/rust/check-static-recursion, r=alexcrichton
I just found this patch which at some point solved a problem I encountered. Unfortunately I apparently dropped it before I managed to write a test case. I'll try to dig up the code that triggered the issue.
bors [Thu, 30 Oct 2014 04:32:08 +0000 (04:32 +0000)]
auto merge of #18448 : brson/rust/clean-llvm, r=alexcrichton
When building for multiple targets, the initial 'make' invocation
always fails. The missing build stamp causes clean-llvm to be
invoked, but clean-llvm cleans *all* llvm builds. So what happens
is that 1) all llvm's are cleaned (a no-op), 2) llvm-${target1}
builds, 3) all llvm's are cleaned (deleting llvm-${target1}),
4) llvm-${target2} is built, 5) the remaining build for ${target1}
fails because llvm does not exist.
This makes the clean operation only clean the correct llvm build.
Should greatly reduce bot failures.
Brian Anderson [Thu, 30 Oct 2014 02:54:52 +0000 (19:54 -0700)]
mk: Clean just one llvm build at a time. Closes #17852
When building for multiple targets, the initial 'make' invocation
always fails. The missing build stamp causes clean-llvm to be
invoked, but clean-llvm cleans *all* llvm builds. So what happens
is that 1) all llvm's are cleaned (a no-op), 2) llvm-${target1}
builds, 3) all llvm's are cleaned (deleting llvm-${target1}),
4) llvm-${target2} is built, 5) the remaining build for ${target1}
fails because llvm does not exist.
This makes the clean operation only clean the correct llvm build.
Should greatly reduce bot failures.
Nick Cameron [Wed, 1 Oct 2014 03:43:39 +0000 (16:43 +1300)]
Enforce object safety
closes #17670
[breaking-change]
Traits must be object-safe if they are to be used in trait objects. This might require splitting a trait into object-safe and non-object-safe parts.
Some standard library traits in std::io have been split - Reader has new traits BytesReader (for the bytes method) and AsRefReader (for by_ref), Writer has new trait AsRefWriter (for by_ref). All these new traits have blanket impls, so any type which implements Reader or Writer (respectively) will have an implmentation of the new traits. To fix your code, you just need to `use` the new trait.
bors [Wed, 29 Oct 2014 20:16:57 +0000 (20:16 +0000)]
auto merge of #17894 : steveklabnik/rust/fail_to_panic, r=aturon
This in-progress PR implements https://github.com/rust-lang/rust/issues/17489.
I made the code changes in this commit, next is to go through alllllllll the documentation and fix various things.
- Rename column headings as appropriate, `# Panics` for panic conditions and `# Errors` for `Result`s.
- clean up usage of words like 'fail' in error messages
Anything else to add to the list, @aturon ? I think I should leave the actual functions with names like `slice_or_fail` alone, since you'll get to those in your conventions work?
I'm submitting just the code bits now so that we can see it separately, and I also don't want to have to keep re-building rust over and over again if I don't have to :wink:
Related, lesser-implemented language items `fail` and
`fail_bounds_check` have become `panic` and `panic_bounds_check`, as
well. These are implemented by `libcore`, so it is unlikely (though
possible!) that these two renamings will affect you.
Steve Klabnik [Thu, 9 Oct 2014 19:17:22 +0000 (15:17 -0400)]
Rename fail! to panic!
https://github.com/rust-lang/rfcs/pull/221
The current terminology of "task failure" often causes problems when
writing or speaking about code. You often want to talk about the
possibility of an operation that returns a Result "failing", but cannot
because of the ambiguity with task failure. Instead, you have to speak
of "the failing case" or "when the operation does not succeed" or other
circumlocutions.
Likewise, we use a "Failure" header in rustdoc to describe when
operations may fail the task, but it would often be helpful to separate
out a section describing the "Err-producing" case.
We have been steadily moving away from task failure and toward Result as
an error-handling mechanism, so we should optimize our terminology
accordingly: Result-producing functions should be easy to describe.
To update your code, rename any call to `fail!` to `panic!` instead.
Assuming you have not created your own macro named `panic!`, this
will work on UNIX based systems:
bors [Wed, 29 Oct 2014 06:36:57 +0000 (06:36 +0000)]
auto merge of #18340 : chastell/rust/guide_closures_fixes, r=steveklabnik
Some minor wording fixes to the Closures chapter; my brain tripped a few times when reading it, so I tried to come up with something a bit smoother. I’m not a native speaker, so please do review this critically.
bors [Tue, 28 Oct 2014 19:56:56 +0000 (19:56 +0000)]
auto merge of #18291 : japaric/rust/dstify, r=aturon
This PR changes the signature of several methods from `foo(self, ...)` to `foo(&self, ...)`/`foo(&mut self, ...)`, but there is no breakage of the usage of these methods due to the autoref nature of `method.call()`s. This PR also removes the lifetime parameter from some traits (`Trait<'a>` -> `Trait`). These changes break any use of the extension traits for generic programming, but those traits are not meant to be used for generic programming in the first place. In the whole rust distribution there was only one misuse of a extension trait as a bound, which got corrected (the bound was unnecessary and got removed) as part of this PR.
I've kept the commits as small and self-contained as possible for reviewing sake, but I can squash them when the review is over.
See this [table] to get an idea of what's left to be done. I've already DSTified [`Show`][show] and I'm working on `Hash`, but bootstrapping those changes seem to require a more recent snapshot (#18259 does the trick)
Vladimir Smola [Mon, 27 Oct 2014 02:28:24 +0000 (09:28 +0700)]
Fix the output of negative duration
Technically speaking, negative duration is not valid ISO 8601, but we need to
print it anyway. If `d` is a positive duration with the output `xxxxxxx`, then
the expected output of negative `-d` value is `-xxxxxxx`. I.e. the idea is to
print negative durations as positive with a leading minus sign.
bors [Tue, 28 Oct 2014 12:26:50 +0000 (12:26 +0000)]
auto merge of #18386 : nikomatsakis/rust/issue-18208, r=pnkfelix
Avoid O(n^2) performance by reconsidering the full set of obligations only when we are about to report an error (#18208). I found it is still important to consider the full set in order to make tests like `let x: Vec<_> = obligations.iter().collect()` work.
I think we lack the infrastructure to write a regression test for this, but when I did manual testing I found a massive reduction in type-checking time for extreme examples like those found in #18208 vs stage0.
Niko Matsakis [Tue, 28 Oct 2014 11:13:15 +0000 (07:13 -0400)]
Avoid O(n^2) performance by reconsidering the full set of obligations only when we are about to report an error (#18208). I found it is still important to consider the full set in order to make tests like `let x: Vec<_> = obligations.iter().collect()` work.
bors [Tue, 28 Oct 2014 08:01:52 +0000 (08:01 +0000)]
auto merge of #18127 : alexcrichton/rust/deriving-arc, r=aturon
This adds impls of Eq/Ord/PartialEq/PartialOrd/Show/Default to Arc<T>, and it
also removes the `Send + Sync` bound on the `Clone` impl of Arc to make it more
deriving-friendly. The `Send + Sync` requirement is still enforce on
construction, of course!
Alex Crichton [Fri, 17 Oct 2014 18:00:02 +0000 (11:00 -0700)]
alloc: Make deriving more friendly with Arc
This adds impls of Eq/Ord/PartialEq/PartialOrd/Show/Default to Arc<T>, and it
also removes the `Send + Sync` bound on the `Clone` impl of Arc to make it more
deriving-friendly. The `Send + Sync` requirement is still enforce on
construction, of course!
bors [Tue, 28 Oct 2014 03:26:52 +0000 (03:26 +0000)]
auto merge of #18144 : bkoropoff/rust/mighty-monomorphizin-unboxed-closures, r=nikomatsakis
This allows unboxed closures that reference free type/region parameters to be monomorphized correctly in trans.
It was necessary to make `ty_unboxed_closure` carry around a `Substs` to accomplish this. Plumbing this through typeck revealed several areas where type/region parameters in unboxed closure types are possibly not being handled correctly. Since my goal was just to fix trans, I decided to leave FIXME comments on areas that still need attention and seek feedback on the best way to clean them up, possibly as a follow-up PR.
Brian Koropoff [Sat, 18 Oct 2014 17:46:57 +0000 (10:46 -0700)]
Fix monomorphization of unboxed closures
This adds a `Substs` field to `ty_unboxed_closure` and plumbs basic
handling of it throughout the compiler. trans now correctly
monomorphizes captured free variables and llvm function defs. This
fixes uses of unboxed closures which reference a free type or region
parameter from their environment in either their signature or free
variables. Closes #16791
Jorge Aparicio [Thu, 23 Oct 2014 15:43:18 +0000 (10:43 -0500)]
DSTify [T]/str extension traits
This PR changes the signature of several methods from `foo(self, ...)` to
`foo(&self, ...)`/`foo(&mut self, ...)`, but there is no breakage of the usage
of these methods due to the autoref nature of `method.call()`s. This PR also
removes the lifetime parameter from some traits (`Trait<'a>` -> `Trait`). These
changes break any use of the extension traits for generic programming, but
those traits are not meant to be used for generic programming in the first
place. In the whole rust distribution there was only one misuse of a extension
trait as a bound, which got corrected (the bound was unnecessary and got
removed) as part of this PR.
projects / rust.git / log