- 18 7月, 2017 23 次提交
-
-
由 Mark Simulacrum 提交于
Fix erroneous reference to Arc instead of Rc in rc::Weak documentation The docs for `rc::Weak` refer to `Arc` in one place, where they should obviously be referring to `Rc`; presumably this was erroneously copied over from the `arc::Weak` docs.
-
由 Mark Simulacrum 提交于
redox: handle multiple paths in PATH
-
由 Mark Simulacrum 提交于
`std::time::Duration`: improve _precision_ of terminology in docs Changed wording of docs on `std::time::Duration` for better clarity w.r.t. the contents of the type and the purpose of its methods. (Specifically, removed the use of the word "precision" to describe the fractional part of the `Duration` because "precision" is more properly used to describe how _precise_ a value is, i.e. its granularity in this case.)
-
由 Mark Simulacrum 提交于
Workaround "Quasi-quoting is inefficient" warning in incremental rustbuild introduced in #43252. After #43252 is merged, building stage0 libcore with `-i` (`--incremental`) flag will cause 17 "Quasi-quoting might make incremental compilation very inefficient: NtExpr(..)" warnings, as in #40946. ``` warning: Quasi-quoting might make incremental compilation very inefficient: NtExpr(..) --> src/libcore/default.rs:133:21 | 133 | #[doc = $doc] | ^^^^ ... 139 | default_impl! { (), (), "Returns the default value of `()`" } | ------------------------------------------------------------- in this macro invocation (× 17) ``` True fix for #40946 will take at least 12 weeks from now to make into the next stage0, so it is quicker to workaround it in libcore instead. cc @vbrandl @jseyfried
-
由 Mark Simulacrum 提交于
libstd: remove redundant & from &Path::new(...) ```rust fn Path::new<S: AsRef ...>(s: &S) -> &Path ``` * https://doc.rust-lang.org/std/path/struct.Path.html#method.new
-
由 Mark Simulacrum 提交于
Change Travis CI job order. Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so pull requests will start testing as immediately after the build is started. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed). (IMO `$SKIP_BUILD` should not even exist: those irrelevant jobs should not start at all, but that would require travis-ci/travis-ci#2778 which has been rejected)
-
由 Mark Simulacrum 提交于
Update merge queue link in CONTRIBUTING.md
-
由 Mark Simulacrum 提交于
Update docs on Error struct. #29355 This adds a pretty contrived example of the usage of fmt::Error. I am very open to suggestions for a better one. I have also highlighted the fmt::Error vs std::error::Error. r? @steveklabnik
-
由 bors 提交于
Support generic lifetime arguments in method calls Fixes https://github.com/rust-lang/rust/issues/42403 Fixes https://github.com/rust-lang/rust/issues/42115 Lifetimes in a method call `x.f::<'a, 'b, T, U>()` are treated exactly like lifetimes in the equivalent UFCS call `X::f::<'a, 'b, T, U>`. In addition, if the method has late bound lifetime parameters (explicit or implicit), then explicitly specifying lifetime arguments is not permitted (guarded by a compatibility lint). [breaking-change] because previously lifetimes in method calls were accepted unconditionally. r? @EddyB
-
由 Lynn 提交于
-
由 kennytm 提交于
Reorder the job matrix to take advantage of the order how Travis CI starts them in rust-lang/rust. Plus other refactoring of `.travis.yml`. 1. Move the `$ALLOW_PR` image to the top, so users' PRs will start testing immediately. Previously the `$ALLOW_PR` image starts 6 minutes after the build was scheduled. 2. Move the slow macOS images near the top, so they share more time with the rest of the faster Linux builds, which should shorten total test time (actually not much, about 7 minutes at most if this change does work). 3. Merged the `install` section of both Linux and macOS to make the `env:` section a bit shorter, and enable change 4 below. 4. Do not download or install anything if `$SKIP_BUILD == true`, which further reduces chance of spurious failure in the PR-CI stage (avoid the red cross appearing even if CI passed).
-
由 bors 提交于
travis: Make a few `curl` invocations more resilient Use the `-f` flag to indicate that, for example, a 500 response code is to be considered a failure, triggering the normal retry logic. Also ignore errors where we check the date from google.com, as a failure there shouldn't fail the build.
-
由 Alex Crichton 提交于
Use the `-f` flag to indicate that, for example, a 500 response code is to be considered a failure, triggering the normal retry logic. Also ignore errors where we check the date from google.com, as a failure there shouldn't fail the build.
-
由 Ian Douglas Scott 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
Fix treatment of lifetimes defined in nested types during detection of late bound regions in signatures. Do not replace substs with inference variables when "cannot specify lifetime arguments explicitly..." is reported as a lint.
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Collin J. Sutton 提交于
Changed wording of docs on `std::time::Duration` for better clarity w.r.t. the contents of the type and the purpose of its methods.
-
由 kennytm 提交于
After #43252 is merged, building stage0 libcore with -i (--incremental) flag will cause 17 "Quasi-quoting might make incremental compilation very inefficient: NtExpr(..)" warnings, as in #40946. Fixing the warning in #40946 will take 12 weeks from now to make into the next stage0, so it is quicker to workaround it in libcore instead.
-
由 bors 提交于
Add support for dylibs with Address Sanitizer Many applications use address sanitizer to assert correct behaviour of their programs. When using Rust with C, it's much more important to assert correct programs with tools like asan/lsan due to the unsafe nature of the access across an ffi boundary. However, previously only rust bin types could use asan. This posed a challenge for existing C applications that link or dlopen .so when the C application is compiled with asan. This PR enables asan to be linked to the dylib and cdylib crate type. We alter the test to check the proc-macro crate does not work with -Z sanitizer=address. Finally, we add a test that compiles a shared object in rust, then another rust program links it and demonstrates a crash through the call to the library. This PR is nearly complete, but I do require advice on the change to fix the -lasan that currently exists in the dylib test. This is required because the link statement is not being added correctly to the rustc build when -Z sanitizer=address is added (and I'm not 100% sure why) Thanks,
-
由 NODA, Kai 提交于
fn Path::new<S: AsRef ...>(s: &S) -> &Path Signed-off-by: NNODA, Kai <nodakai@gmail.com>
-
- 17 7月, 2017 13 次提交
-
-
由 bors 提交于
Fix `range_covered_by_constructor` for exclusive ranges. This resolves #43253
-
由 bors 提交于
Change some notes into suggestions r? @petrochenkov since you commented on the same edits in #39458
-
由 Sam Cappleman-Lynes 提交于
-
由 Oliver Schneider 提交于
The produced paths aren't stable between builds, since reporting paths inside resolve, before resolve is finished might produce paths resolved to type aliases instead of the concrete type. Compile-fail tests can match just parts of messages, so they don't "suffer" from this issue. This is just a workaround, the instability should be fixed in the future.
-
由 Oliver Schneider 提交于
-
由 Oliver Schneider 提交于
-
由 bors 提交于
More Rust/RLS integration r? @alexcrichton cc https://github.com/rust-lang-nursery/rls/issues/310 closes #41199 closes #41197
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
-
由 bors 提交于
Compile `compiler_builtins` with `abort` panic strategy A workaround for https://github.com/rust-lang/rust/issues/43095 In case this causes unexpected consequences, I use a simpler workaround locally: ```diff --- a/src/bootstrap/bin/rustc.rs +++ b/src/bootstrap/bin/rustc.rs @@ -175,7 +175,9 @@ fn main() { } if let Ok(s) = env::var("RUSTC_CODEGEN_UNITS") { - cmd.arg("-C").arg(format!("codegen-units={}", s)); + if crate_name != "compiler_builtins" { + cmd.arg("-C").arg(format!("codegen-units={}", s)); + } } // Emit save-analysis info. ``` r? @alexcrichton
-
由 bors 提交于
Stabilize float_bits_conv for Rust 1.21 Stabilizes the `float_bits_conv` lib feature for the 1.20 release of Rust. I've initially implemented the feature in #39271 and later made PR #43025 to output quiet NaNs even on platforms with different encodings, which seems to have been the only unresolved issue of the API. Due to PR #43025 being only applied to master this stabilisation can't happen for Rust 1.19 through the usual "stabilisation on beta" system that is being done for library APIs. r? @BurntSushi closes #40470.
-
由 Sam Cappleman-Lynes 提交于
-
由 Sam Cappleman-Lynes 提交于
This resolves #43253
-
- 16 7月, 2017 4 次提交
-
-
由 bors 提交于
add u128/i128 to sum/product implementors Resolves #43235.
-
由 bors 提交于
Document default values for primitive types All primitive types implement the `Default` trait but the documentation just says `Returns the "default value" for a type.` and doesn't give a hint about the actual default value. I think it would be good to document the default values in a proper way. I changed the `default_impl` macro to accept a doc string as a third parameter and use this string to overwrite the documentation of `default()` for each primitive type. The generated documentation now looks like this: ![Documentation of default() on the bool primitive](https://i.imgur.com/nK6TApo.png)
-
由 Vadim Petrochenkov 提交于
-
由 bors 提交于
macros: fix regression involving identifiers in `macro_rules!` patterns. Fixes #42019. r? @nrc
-