- 18 1月, 2017 6 次提交
-
-
由 bors 提交于
E0034: provide disambiguated syntax for candidates For a given file ```rust trait A { fn foo(&self) {} } trait B : A { fn foo(&self) {} } fn bar<T: B>(a: &T) { a.foo() } ``` provide the following output ``` error[E0034]: multiple applicable items in scope --> file.rs:6:5 | 6 | a.foo(1) | ^^^ multiple `foo` found | note: candidate #1 is defined in the trait `A` --> file.rs:2:11 | 2 | trait A { fn foo(&self, a: usize) {} } | ^^^^^^^^^^^^^^^^^^^^^^^^^^ help: to use it here write `A::foo(&a, 1)` instead --> file.rs:6:5 | 6 | a.foo(1) | ^^^ note: candidate #2 is defined in the trait `B` --> file.rs:3:15 | 3 | trait B : A { fn foo(&self, a: usize) {} } | ^^^^^^^^^^^^^^^^^^^^^^^^^^ help: to use it here write `B::foo(&a, 1)` instead --> file.rs:6:5 | 6 | a.foo(1) | ^^^ ``` Fix #37767.
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 bors 提交于
Improve the slice iterator's searching methods Improve all, any, find, position, rposition by explicitly unrolling the loop for the slice iterators. - Introduce a few extension methods and functions for raw pointers make the new code easy to express - Introduce helper methods `search_while, rsearch_while` that generalize all the searching methods LLVM doesn't unroll the loop in `.find()` by default (clang is the same), so performance benefits a lot from explicit unrolling here. An iterator method without conditional exits (like `.fold()`) does not need this on the other hand. One of the raw pointer extension methods is `fn post_inc(&mut self) -> Self` which is the rustic equivalent of “`ptr++`”, and it is a nice way to express the raw pointer loop (see commit 3). Specific development notes about `search_while`: I tried both computing an end pointer "rounded" to 4, as well as the `ptrdistance >= 4` loop condition, ptrdistance was better. I tried handling the last 0-3 elements unrolled or with a while loop, the loop was better.
-
由 bors 提交于
incr.comp.: Delete orphaned work-products. The new partitioning scheme uncovered a hole in our incr. comp. cache directory garbage collection. So far, we relied on unneeded work products being deleted during the initial cache invalidation phase. However, we the new scheme, we get object files/work products that only contain code from upstream crates. Sometimes this code is not needed anymore (because all callers have been removed from the source) but because nothing that actually influences the contents of these work products had changed, we never deleted them from disk. r? @nikomatsakis
-
- 17 1月, 2017 27 次提交
-
-
由 bors 提交于
Fix stage 1 tests broken because i128 doesn't work in stage 1 Broken by https://github.com/rust-lang/rust/pull/38992.
-
由 bors 提交于
Merge ObjectSum and PolyTraitRef in AST/HIR + some other refactoring `ObjectSum` and `PolyTraitRef` are the same thing (list of bounds), they exist separately only due to parser quirks. The second commit merges them. The first commit replaces `Path` with `Ty` in (not yet supported) equality predicates. They are parsed as types anyway and arbitrary types can always be disguised as paths using aliases, so this doesn't add any new functionality. The third commit uses `Vec` instead of `P<[T]>` in AST. AST is not immutable like HIR and `Vec`s are more convenient for it, unnecessary conversions are also avoided. The last commit renames `parse_ty_sum` (which is used for parsing types in general) into `parse_ty`, and renames `parse_ty` (which is used restricted contexts where `+` is not permitted due to operator priorities or other reasons) into `parse_ty_no_plus`. This is the first part of https://github.com/rust-lang/rust/issues/39085#issuecomment-272743755 and https://github.com/rust-lang/rust/issues/39080 focused on data changes and mechanical renaming, I'll submit a PR with parser changes a bit later. r? @EddyB
-
由 bors 提交于
Fix UB in test helpers Macro expansion producing defined has undefined behavior in C/C++.
-
由 bors 提交于
travis: Pass --release-channel=nightly on deploy This commit passes the `--release-channel=nightly` flag to all images which have the `DEPLOY` flag set. This means that we'll name artifacts and the compiler appropriately. This reworks a bit how arguments are passed, but for now doesn't change what's already being passed. Eventually we'll want to avoid enabling debug assertions and llvm assertions for *all* releases, but I figure we can tackle that a little bit more down the road.
-
由 Vadim Petrochenkov 提交于
-
由 Alex Crichton 提交于
This commit passes the `--release-channel=nightly` flag to all images which have the `DEPLOY` flag set. This means that we'll name artifacts and the compiler appropriately. This reworks a bit how arguments are passed, but for now doesn't change what's already being passed. Eventually we'll want to avoid enabling debug assertions and llvm assertions for *all* releases, but I figure we can tackle that a little bit more down the road.
-
由 bors 提交于
proc macros/qquote: Handle empty delimited tokens r? @jseyfried
-
由 bors 提交于
Fix linker failure on windows Fixes #38933. r? @ollie27
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Michael Woerister 提交于
-
由 Vadim Petrochenkov 提交于
-
由 bors 提交于
Rollup of 6 pull requests - Successful merges: #38247, #39028, #39065, #39084, #39105, #39106 - Failed merges:
-
由 Guillaume Gomez 提交于
libcollections: btree/set: fix a typo
-
由 Guillaume Gomez 提交于
libcollections: btree/map: fix typos
-
由 Guillaume Gomez 提交于
An update to patterns documentation As it is written the current pattern page creates a lot of confusion, even for someone with previous rust experience. It's so hard because it introduces an entirely new language feature without explaining. Someone could update it within the span of a few minutes by just explaining the newly introduced feature. ```rust match c { x => println!("x: {} c: {}", x, c), } ``` No where in the book up to this point has it explained that identifiers match patterns with just a name create an irrefutable pattern. The page uses this feature without explanation, it just assumes that readers would immediately understand it. To confuse the issue even further the topic uses this feature to explain shadowing, placing two x's from different scopes and different meanings without ever explaining why there is shadowing. What follows comes across as utterly nonsensical given everything the reader would know about Rust about this point: ```rust the result: x: c c: c x: x ``` x is c? What? Yes even if you understand that x here is not the x in the previous scope why would x equal 'c' here? What previous chapter explained this? The previous chapter on 'matching' only mentions the catch all '_' and never in any shape or form mentioned that a name here creates an irrefutable pattern and binds a value. There are numerous examples of people not understanding this section, not finding answers and looking for them online about `x: c c: c`: https://github.com/rust-lang/book/issues/316 https://stackoverflow.com/questions/35563141/match-shadowing-example-in-the-patterns-section-of-the-rust-book-is-very-perplex https://users.rust-lang.org/t/confusion-about-match-and-patterns/3937 https://www.bountysource.com/issues/38852461-question-on-patterns-section-shadowing-example-existing-book And a [google search for `rust x: c c: c`](https://www.google.com/search?q=rust+%22x:+c+c:+c%22) finds many more people being tripped up, including people who speak a language other than English. I am confident that this page has resulted in questions on the irc channel more than once. Given rust already has a pretty big learning curve I recommend this be fixed. I was asked to create PR from where I made this same case in the [rust book repository issue](https://github.com/rust-lang/book/issues/316) (I didn't realize this was a separate project).
-
由 Guillaume Gomez 提交于
Add doc examples & description in `std::os::unix::ffi`. None
-
由 Guillaume Gomez 提交于
Minor improvements to docs in std::env structures/functions. * Call functions "functions" instead of "methods". * Link structures to their constructor functions * Add other misc. documentation links
-
由 Guillaume Gomez 提交于
Document the optional extra arguments to assert_eq!() / assert_ne!() And clarify that those arguments in assert!() are in fact formattable.
-
由 Ivan Stankovic 提交于
-
由 Ivan Stankovic 提交于
-
由 bors 提交于
(Shot at) Fix endian bugs in i128 intrinsic impls Attempt to fix the endianness issues on big-endian machines such as power pc. Could not test if it actually makes stuff work on the powerpc, because setting up cross-compiler for ppc seems to be nigh-impossible on arch.
-
由 Mark Simulacrum 提交于
Broken by https://github.com/rust-lang/rust/pull/38992.
-
由 Vadim Petrochenkov 提交于
-
由 bors 提交于
travis: Mirror some NetBSD artifacts This mirrors a few artifacts that have been flaky to download recently on our own S3 bucket, which has historically been more reliable. Closes #39097
-
由 Alex Crichton 提交于
This mirrors a few artifacts that have been flaky to download recently on our own S3 bucket, which has historically been more reliable. Closes #39097
-
- 16 1月, 2017 7 次提交
-
-
由 bors 提交于
rustdoc: Give primitive types stability attributes This is especially important for i128/u128 to make it clear they are unstable in the docs.
-
由 bors 提交于
Minor improvement to strange grammar in E0525 Hi, I just ran into this error from rustc, and it had some strange grammar, so I cleaned it up a bit.
-
由 Simonas Kazlauskas 提交于
Macro expansion producing defined has undefined behavior in C/C++.
-
由 Simonas Kazlauskas 提交于
-
由 bors 提交于
Mark safe_suggestion and pushpop_unsafe as removed in feature_gate.rs This removes two features from feature_gate.rs: `safe_suggestion` and `pushpop_unsafe`. Both had been removed in other places already, but were forgotten to be removed from feature_gate.rs. * `safe_suggestion` was added in commit 164f0105 and then removed again in commit c11fe553 both in the same PR #38099. * `pushpop_unsafe` was added in commit 1829fa51 and removed again in commit d399098f Removes two elements from the whitelist of non gate tested unstable lang features (issue #39059).
-
由 Scott Olson 提交于
This is a clearer name since they represent [a, b, c] array literals.
-
由 bors 提交于
Fix missing blank space issue r? @Manishearth
-