- 29 9月, 2014 15 次提交
-
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
-
由 Tom Jakubowski 提交于
Fix #16546
-
由 bors 提交于
-
由 bors 提交于
Parser.parse_method now has a second argument, I assume ast::Inherited is the correct visibility in this case.
-
由 Vladimir Pouzanov 提交于
Parser.parse_method now has a second argument, I assume ast::Inherited is the correct visibility in this case.
-
由 bors 提交于
It's a rather useful syntax, and non-obvious. A friend of mine is learning Rust and was trying to find a way to easily do such an initialization — he couldn't find it in the guide and was pretty surprised when I showed him. Looks like something that should be mentioned. r? @steveklabnik
-
由 bors 提交于
Followup to RFC 57. Fixes #7607 Fixes #8767 Fixes #12729 Fixes #15060
-
由 bors 提交于
This PR makes rustc emit debug locations for *all* call and invoke statements in LLVM IR, if they are contained within a function that debuginfo is enabled for. This is important because LLVM does not handle the case where a function body containing debuginfo is inlined into another function with debuginfo, but the inlined call statement does not have a debug location. In this case, LLVM will not know where (in terms of source code coordinates) the function was inlined to and we end up with some statements still linked to the source locations in there original, non-inlined function without any indication that they are indeed an inline-copy. Later, when generating DWARF from the IR, LLVM will interpret this as corrupt IR and abort. Unfortunately, the undesirable case described above can still occur when using LTO. If there is a crate compiled without debuginfo calling into a crate compiled with debuginfo, we again end up with the conditions triggering the error. This is why some LTO tests still fail with the dreaded assertion, if the standard library was built with debuginfo enabled. That is, `RUSTFLAGS_STAGE2=-g make rustc-stage2` will succeed but `RUSTFLAGS_STAGE2=-g make check` will still fail after this PR has been merged. I will open a separate issue for this problem.
-
由 Andrew Poelstra 提交于
Followup to RFC 57. Fixes #7607 Fixes #8767 Fixes #12729 Fixes #15060
-
- 28 9月, 2014 7 次提交
-
-
由 bors 提交于
-
由 bors 提交于
We'll need a snapshot before we can convert the codebase over and turn on the deprecation warnings. cc #17490 This is sitting on top of #17506
-
由 Steven Fackler 提交于
This removes the ability to use `foo(bar)` style cfgs. Switch them to `foo_bar` or `foo="bar"` instead. [breaking-change]
-
由 bors 提交于
W3C HTML5 spec states that H1 must enclose "phrasing content" which doesn't include DIV. But SPAN is OK. http://www.w3.org/TR/html5/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements
-
由 bors 提交于
Everyone agreed. Fix #17078 #14248 seems completed, as every src/test/bench/shootout-*.rs are relicensed after acceptation of this PR except: - shootout-ackermann.rs: obsolete shootout bench - shootout-fibo.rs: obsolete shootout bench - shootout-k-nucleotide-pipes.rs: slower that shootout-k-nucleotide-pipes.rs (and not so interesting as a benchmark) - shootout-pfib.rs: does not seems related to the shootout @brson OK?
-
由 bors 提交于
Fixes #17500
-
由 bors 提交于
Replaces BTree with BTreeMap and BTreeSet, which are completely new implementations. BTreeMap's internal Node representation is particularly inefficient at the moment to make this first implementation easy to reason about and fairly safe. Both collections are also currently missing some of the tooling specific to sorted collections, which is planned as future work pending reform of these APIs. General implementation issues are discussed with TODOs internally [breaking-change] Still waiting on compilation/test/bench stuff locally, but the edit-distance on any errors should be very small at this point. This is ready to be reviewed.
-
- 27 9月, 2014 10 次提交
-
-
由 Alexis Beingessner 提交于
Replaces BTree with BTreeMap and BTreeSet, which are completely new implementations. BTreeMap's internal Node representation is particularly inefficient at the moment to make this first implementation easy to reason about and fairly safe. Both collections are also currently missing some of the tooling specific to sorted collections, which is planned as future work pending reform of these APIs. General implementation issues are discussed with TODOs internally Perf results on x86_64 Linux: test treemap::bench::find_rand_100 ... bench: 76 ns/iter (+/- 4) test treemap::bench::find_rand_10_000 ... bench: 163 ns/iter (+/- 6) test treemap::bench::find_seq_100 ... bench: 77 ns/iter (+/- 3) test treemap::bench::find_seq_10_000 ... bench: 115 ns/iter (+/- 1) test treemap::bench::insert_rand_100 ... bench: 111 ns/iter (+/- 1) test treemap::bench::insert_rand_10_000 ... bench: 996 ns/iter (+/- 18) test treemap::bench::insert_seq_100 ... bench: 486 ns/iter (+/- 20) test treemap::bench::insert_seq_10_000 ... bench: 800 ns/iter (+/- 15) test btree::map::bench::find_rand_100 ... bench: 74 ns/iter (+/- 4) test btree::map::bench::find_rand_10_000 ... bench: 153 ns/iter (+/- 5) test btree::map::bench::find_seq_100 ... bench: 82 ns/iter (+/- 1) test btree::map::bench::find_seq_10_000 ... bench: 108 ns/iter (+/- 0) test btree::map::bench::insert_rand_100 ... bench: 220 ns/iter (+/- 1) test btree::map::bench::insert_rand_10_000 ... bench: 620 ns/iter (+/- 16) test btree::map::bench::insert_seq_100 ... bench: 411 ns/iter (+/- 12) test btree::map::bench::insert_seq_10_000 ... bench: 534 ns/iter (+/- 14) BTreeMap still has a lot of room for optimization, but it's already beating out TreeMap on most access patterns. [breaking-change]
-
由 bors 提交于
The sentence "The new iterator `filter()` produces returns only the elements that that closure returned `true` for:" can be structured as: "The new iterator `filter()` produces only the elements that that closure returned `true` for:" or as: "The new iterator `filter()` returns only the elements that that closure returned `true` for:" however, not both. I went with "produces", since it then talks about returning true and having "return" so close together doesn't sound nice. r @steveklabnik ?
-
由 bors 提交于
r? @steveklabnik
-
由 bors 提交于
Fix rust-lang/rust#17255 This is such a trivial change. Devs: perhaps you might want to omit to run `make check` on Travis.
-
由 bors 提交于
This is the inverse of `Result::ok` and helps to bridge `Option` and `Result` based APIs.
-
由 bors 提交于
cc #17490 Reopening of #16230
-
由 bors 提交于
over inherent methods accessible via more autoderefs. This simplifies the trait matching algorithm. It breaks code like: impl Foo { fn foo(self) { // before this change, this will be called } } impl<'a,'b,'c> Trait for &'a &'b &'c Foo { fn foo(self) { // after this change, this will be called } } fn main() { let x = &(&(&Foo)); x.foo(); } To explicitly indicate that you wish to call the inherent method, perform explicit dereferences. For example: fn main() { let x = &(&(&Foo)); (***x).foo(); } Part of #17282. [breaking-change] r? @nikomatsakis
-
由 Patrick Walton 提交于
over inherent methods accessible via more autoderefs. This simplifies the trait matching algorithm. It breaks code like: impl Foo { fn foo(self) { // before this change, this will be called } } impl<'a,'b,'c> Trait for &'a &'b &'c Foo { fn foo(self) { // after this change, this will be called } } fn main() { let x = &(&(&Foo)); x.foo(); } To explicitly indicate that you wish to call the inherent method, perform explicit dereferences. For example: fn main() { let x = &(&(&Foo)); (***x).foo(); } Part of #17282. [breaking-change]
-
由 Steven Fackler 提交于
These are the inverses of `Result::ok` and help to bridge `Option` and `Result` based APIs.
-
由 Patrick Walton 提交于
in favor of `move`. This breaks code that used `move` as an identifier, because it is now a keyword. Change such identifiers to not use the keyword `move`. Additionally, this breaks code that was counting on by-value or by-reference capture semantics for unboxed closures (behind the feature gate). Change `ref |:|` to `|:|` and `|:|` to `move |:|`. Part of RFC #63; part of issue #12831. [breaking-change]
-
- 26 9月, 2014 8 次提交
-
-
由 bors 提交于
This commit is another in the series of vector slice API stabilization. The focus here is the *mutable* slice API. Largely, this API inherits the stability attributes [previously assigned](rust-lang#16332) to the analogous methods on immutable slides. It also adds comments to a few `unstable` attributes that were previously missing them. In addition, the commit adds several `_mut` variants of APIs that were missing: - `init_mut` - `head_mut` - `tail_mut` - `splitn_mut` - `rsplitn_mut` Some of the unsafe APIs -- `unsafe_set`, `init_elem`, and `copy_memory` -- were deprecated in favor of working through `as_mut_ptr`, to simplify the API surface. Due to deprecations, this is a: [breaking-change]
-
由 Steven Fackler 提交于
The for loop would *always* exaust the iterator previously, which seems like behavior that was not intended. It's still kind of a weird function.
-
由 bors 提交于
32-bit builds pass the full 'make check' on the bots after this.
-
由 Brian Anderson 提交于
-
由 bors 提交于
The tuple serialization logic should be using the tuple-specific emit function. This fixes part of #17158. The JSON encoder already proxies to `emit_seq_elt` when `emit_tuple_arg` is called, so this should have an effect.
-
由 Clark Gaebel 提交于
-
由 Aaron Turon 提交于
-
由 Aaron Turon 提交于
-