- 18 2月, 2017 1 次提交
-
-
由 Taylor Cramer 提交于
-
- 14 2月, 2017 5 次提交
-
-
由 bors 提交于
Automate vendoring by invoking cargo-vendor when building src dist tarballs. This avoids #39633 bringing the `src/vendor` checked into git by #37524, past 200,000 lines of code. I believe the strategy of having rustbuild run `cargo vendor` during the `dist src` step is sound. However, the only way to be sure `cargo-vendor` exists is to run `cargo install --force cargo-vendor`, which will recompile it every time (not passing `--force` means you can't tell between "already exists" and "build error"). ~~This is quite suboptimal and I'd like to somehow do it in each `Dockerfile` that would need it.~~ * [ ] Cache `CARGO_HOME` (i.e. `~/.cargo`) between CI runs * `bin/cargo-vendor` and the actual caches are the relevant bits * [x] Do not build `cargo-vendor` all the time * ~~Maybe detect `~/.cargo/bin/cargo-vendor` already exists?~~ * ~~Could also try to build it in a `Dockerfile` but do we have `cargo`/`rustc` there?~~ * Final solution: check `cargo install --list` for a line starting with `cargo-vendor ` cc @rust-lang/tools
-
由 bors 提交于
Add PartialOrd, Ord derivations to TypeId I want to be able to sort a `Vec` of types which contain `TypeId`s, so an `Ord` derivation would be very useful to me. `Hash` and `PartialEq`/`Eq` already exist, so the missing `PartialOrd` and `Ord` derivations feel like an oversight to me.
-
由 bors 提交于
Add intrinsics & target features for rd{rand,seed} One question is whether or not we want to map feature name `rdrnd` to `rdrand` instead. EDIT: as for use case, I would like to port my rdrand crate from inline assembly to these intrinsics.
-
由 Eduard-Mihai Burtescu 提交于
-
由 bors 提交于
Rollup of 5 pull requests - Successful merges: #39716, #39758, #39759, #39774, #39784 - Failed merges:
-
- 13 2月, 2017 22 次提交
-
-
由 Corey Farwell 提交于
typo fix
-
由 Corey Farwell 提交于
Remove '--disable-rustbuild' option from configure script. Fixes https://github.com/rust-lang/rust/issues/39762.
-
由 Corey Farwell 提交于
add solaris rustbuild support Add Solaris as recognized ostype Add cputype recognition for Solaris Fixes #39729 A future pull request will discriminate between the commercial release and older opensource derivatives to account for divergence, for now, this is compatible with both.
-
由 Corey Farwell 提交于
Remove duplicated "parameter" in E0089 text Closes #39732
-
由 Corey Farwell 提交于
Add `swap` method for `Cell` Addition to #39264 r? @alexcrichton
-
由 Jake Goulding 提交于
They now always say how many lifetime / type parameters were expected and are explicit about stating "lifetime" or "type" instead of just "parameter".
-
由 Jake Goulding 提交于
Closes #39732
-
由 king6cong 提交于
-
由 bors 提交于
Fix some typos in the core::fmt docs.
-
由 bors 提交于
[MIR] SwitchInt Everywhere Something I've been meaning to do for a very long while. This PR essentially gets rid of 3 kinds of conditional branching and only keeps the most general one - `SwitchInt`. Primary benefits are such that dealing with MIR now does not involve dealing with 3 different ways to do conditional control flow. On the other hand, constructing a `SwitchInt` currently requires more code than what previously was necessary to build an equivalent `If` terminator. Something trivially "fixable" with some constructor methods somewhere (MIR needs stuff like that badly in general). Some timings (tl;dr: slightly faster^1 (unexpected), but also uses slightly more memory at peak (expected)): ^1: Not sure if the speed benefits are because of LLVM liking the generated code better or the compiler itself getting compiled better. Either way, its a net benefit. The CORE and SYNTAX timings done for compilation without optimisation. ``` AFTER: Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 31.50 secs Finished release [optimized] target(s) in 31.42 secs Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 439.56 secs Finished release [optimized] target(s) in 435.15 secs CORE: 99% (24.81 real, 0.13 kernel, 24.57 user); 358536k resident CORE: 99% (24.56 real, 0.15 kernel, 24.36 user); 359168k resident SYNTAX: 99% (49.98 real, 0.48 kernel, 49.42 user); 653416k resident SYNTAX: 99% (50.07 real, 0.58 kernel, 49.43 user); 653604k resident BEFORE: Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 31.84 secs Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 451.17 secs CORE: 99% (24.66 real, 0.20 kernel, 24.38 user); 351096k resident CORE: 99% (24.36 real, 0.17 kernel, 24.18 user); 352284k resident SYNTAX: 99% (52.24 real, 0.56 kernel, 51.66 user); 645544k resident SYNTAX: 99% (51.55 real, 0.48 kernel, 50.99 user); 646428k resident ``` cc @nikomatsakis @EddyB
-
由 Ahmed Charles 提交于
-
-
由 bors 提交于
macros: fix inert attributes from `proc_macro_derives` with `#![feature(proc_macro)]` This PR refactors collection of `proc_macro_derive` invocations to fix #39347. After this PR, the input to a `#[proc_macro_derive]` function no longer sees `#[derive]`s on the underlying item. For example, consider: ```rust extern crate my_derives; use my_derives::{Trait, Trait2}; #[derive(Copy, Clone)] #[derive(Trait)] #[derive(Trait2)] struct S; ``` Today, the input to the `Trait` derive is `#[derive(Copy, Clone, Trait2)] struct S;`, and the input to the `Trait2` derive is `#[derive(Copy, Clone)] struct S;`. More generally, a `proc_macro_derive` sees all builtin derives, as well as all `proc_macro_derive`s listed *after* the one being invoked. After this PR, both `Trait` and `Trait2` will see `struct S;`. This is a [breaking-change], but I believe it is highly unlikely to cause breakage in practice. r? @nrc
-
由 Shawn Walker-Salas 提交于
-
由 bors 提交于
Rollup of 7 pull requests - Successful merges: #39654, #39662, #39697, #39740, #39743, #39756, #39760 - Failed merges:
-
由 Guillaume Gomez 提交于
Improve grammar on field init docs
-
由 Guillaume Gomez 提交于
Sustitutes try! for ? in the Result documentation Hopefully newcomers will go strait to use `?`
-
由 Guillaume Gomez 提交于
Add tested item in the rustdoc --test output r? @alexcrichton cc @SergioBenitez
-
由 Guillaume Gomez 提交于
rustdoc: Only include a stability span if needed. This patch gets rid of the empty stability boxes in docs by only including the span that creates it when the item actually has a stability class. Here are images of the issue on `std::process::Output`: Before: <img width="340" alt="before" src="https://cloud.githubusercontent.com/assets/122457/22853638/ff88d1b2-f010-11e6-90d6-bf3d10e2fffa.png"> After: <img width="333" alt="after" src="https://cloud.githubusercontent.com/assets/122457/22853639/06bfe7cc-f011-11e6-9892-f0ea2cc6ec90.png"> This is my first non-trivial patch to Rust, so I'm sure some of my approach is not idiomatic. Let me know how you'd like me to adjust!
-
由 Guillaume Gomez 提交于
Add the item type to the tooltip See: https://users.rust-lang.org/t/seeking-opinions-from-colorblind-rustaceans-coloring-in-rustdoc-code-blocks
-
由 Guillaume Gomez 提交于
Fixes #39661 Clarifies the potential ambiguity.
-
由 Guillaume Gomez 提交于
rustdoc: Show attributes on all item types Currently attributes are only shown for structs, unions and enums but they should be shown for all items. For example it is useful to know if a function is `#[no_mangle]`.
-
- 12 2月, 2017 12 次提交
-
-
由 Eduard-Mihai Burtescu 提交于
-
由 bors 提交于
Add recursion limit to inhabitedness check Fixes #39489. Add test aswell.
-
由 Jeffrey Seyfried 提交于
-
由 Shawn Walker-Salas 提交于
remove unnecessary gcc_s addition in libstd for Solaris
-
由 Jake Goulding 提交于
-
由 Shawn Walker-Salas 提交于
Don't need to catch WindowsError. That was very silly of me.
-
由 Shawn Walker-Salas 提交于
Add cputype recognition for Solaris Fixes #39729
-
由 bors 提交于
Auto merge of #39554 - zackmdavis:assert_eq_has_a_terrible_error_message_when_given_a_trailing_comma, r=BurntSushi improve error message when two-arg assert_eq! receives a trailing comma Previously, `assert_eq!(left, right,)` (respectively, `assert_ne!(left, right,)`; note the trailing comma) would result in a confusing "requires at least a format string argument" error. In reality, a format string is optional, but the trailing comma puts us into the "match a token tree of zero or more tokens" branch of the macro (in order to support the optional format string), and passing the empty token tree into `format_args!` results in the confusing error. If instead we match a token tree of one or more tokens, we get a much more sensible "unexpected end of macro invocation" error. While we're here, fix up a stray space before a comma in the match guards. Resolves #39369. ----- **Before:** ``` $ rustc scratch.rs error: requires at least a format string argument --> scratch.rs:2:5 | 2 | assert_eq!(1, 2,); | ^^^^^^^^^^^^^^^^^^ | = note: this error originates in a macro outside of the current crate error: aborting due to previous error ``` **After:** ``` $ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc scratch.rs error: unexpected end of macro invocation --> scratch.rs:2:20 | 2 | assert_eq!(1, 2,); | ^ ```
-
由 Jeffrey Seyfried 提交于
-
由 Jordi Polo 提交于
-
由 bors 提交于
treat setting the number of test-threads to 0 as an error It is currently possible to call `cargo test -- --test-threads=0` which will cause cargo to hang until aborted. This change will fix that and will report an appropriate error to the user.
-
由 bors 提交于
[LLVM 4.0] Fix CreateCompileUnit This is largely identical to @dylanmckay's [patch](https://github.com/dylanmckay), except that it doesn't try to use `file_metadata()`. I don't think that is necessary because we don't want the compile unit to be added to `debug_context.created_files`, though I'd like confirmation from someone who knows for sure. If that is needed, I can modify `file_metadata_()` so that it can be used from `compile_unit_metadata()`.
-