- 05 2月, 2016 3 次提交
-
-
由 Steve Klabnik 提交于
"stmt" already includes the terminating semicolon.
-
由 Steve Klabnik 提交于
According to http://www.copyright.gov/circs/circ01.pdf (See screenshot of relevant section below) , listing the first year of publication in the copyright is enough ![selection_008](https://cloud.githubusercontent.com/assets/829526/12409934/7021c3a6-be95-11e5-8d1a-18f6948571e0.png) The commits d5c8f626 and f979f91a have changed the copyright years This commit reverts back those changes, so that license year is again 2014 (As it was, when this license was first introduced in commit 90ba013b ) -------------------------------------- Edit 1: Added screenshot
-
由 bors 提交于
- use `symlink_file` and `symlink_dir` instead of the old `soft_link` - create a junction instead of a directory symlink for testing recursive_rmdir (as it causes the same troubles, but can be created by users without `SeCreateSymbolicLinkPrivilege`) - `remove_dir_all` was unable to remove directory symlinks and junctions - only run tests that create symlinks if we have the right permissions. - rename `Path2` to `Path` - remove the global `#[allow(deprecated)]` and outdated comments - After factoring out `create_junction()` from the test `directory_junctions_are_directories` and removing needlessly complex code, what I was left with was: ``` #[test] #[cfg(windows)] fn directory_junctions_are_directories() { use sys::fs::create_junction; let tmpdir = tmpdir(); let foo = tmpdir.join("foo"); let bar = tmpdir.join("bar"); fs::create_dir(&foo).unwrap(); check!(create_junction(&foo, &bar)); assert!(bar.metadata().unwrap().is_dir()); } ``` It test whether a junction is a directory instead of a reparse point. But it actually test the target of the junction (which is a directory if it exists) instead of the junction itself, which should always be a symlink. So this test is invalid, and I expect it only exists because the author was suprised by it. So I removed it. Some things that do not yet work right: - relative symlinks do not accept forward slashes - the conversion of paths for `create_junction` is hacky - `remove_dir_all` now messes with the internal data of `FileAttr` to be able to remove symlinks. We should add some method like `is_symlink_dir()` to it, so code outside the standard library can see the difference between file and directory symlinks too.
-
- 04 2月, 2016 16 次提交
-
-
由 bors 提交于
r? @nrc
-
由 Paul Dicker 提交于
-
由 bors 提交于
This is useful when you have an API that takes a `T: ToSocketAddrs` and needs to turn that into an owned value which will be passed to another API taking `T: ToSocketAddrs` at a later time, for example: https://github.com/sfackler/rust-hyper-socks/blob/master/src/lib.rs#L15
-
由 bors 提交于
I have it set as stable right now under the rationale that it's extending an existing, stable API to another type in the "obvious" way. r? @alexcrichton cc @reem
-
由 Steven Fackler 提交于
-
由 Steven Fackler 提交于
-
由 bors 提交于
-
由 bors 提交于
After the truly incredible and embarrassing mess I managed to make in my last pull request, this should be a bit less messy. Fixes #31267 - with this change, the code mentioned in the issue compiles. Found and fixed another issue as well - constants of zero-size types, when used in ExprRepeats inside associated constants, were causing the compiler to crash at the same place as #31267. An example of this: ``` struct Bar; const BAZ: Bar = Bar; struct Foo([Bar; 1]); struct Biz; impl Biz { const BAZ: Foo = Foo([BAZ; 1]); } fn main() { let foo = Biz::BAZ; println!("{:?}", foo); } ``` However, I'm fairly certain that my fix for this is not as elegant as it could be. The problem seems to occur only with an associated constant of a tuple struct containing a fixed size array which is initialized using a repeat expression, and when the element to be repeated provided to the repeat expression is another constant which is of a zero-sized type. The fix works by looking for constants and associated constants which are zero-width and consequently contain no data, but for which rustc is still attempting to emit an LLVM value; it simply stops rustc from attempting to emit anything. By my logic, this should work fine since the only values that are emitted in this case (according to the comments) are for closures with side effects, and constants will never have side effects, so it's fine to simply get rid of them. It fixes the error and things compile fine with it, but I have a sneaking suspicion that it could be done in a far better manner. r? @nikomatsakis
-
由 bors 提交于
Rust currently emits atomic loads and stores with the LLVM `volatile` qualifier. This is unnecessary and prevents LLVM from performing optimization on these atomic operations.
-
由 bors 提交于
Fixes #30349
-
由 bors 提交于
This pull request adds support for [Illumos](http://illumos.org/)-based operating systems: SmartOS, OpenIndiana, and others. For now it's x86-64 only, as I'm not sure if 32-bit installations are widespread. This PR is based on #28589 by @potatosalad, and also closes #21000, #25845, and #25846. Required changes in libc are already merged: https://github.com/rust-lang-nursery/libc/pull/138 Here's a snapshot required to build a stage0 compiler: https://s3-eu-west-1.amazonaws.com/nbaksalyar/rustc-sunos-snapshot.tar.gz It passes all checks from `make check`. There are some changes I'm not quite sure about, e.g. macro usage in `src/libstd/num/f64.rs` and `DirEntry` structure in `src/libstd/sys/unix/fs.rs`, so any comments on how to rewrite it better would be greatly appreciated. Also, LLVM configure script might need to be patched to build it successfully, or a pre-built libLLVM should be used. Some details can be found here: https://llvm.org/bugs/show_bug.cgi?id=25409 Thanks! r? @brson
-
由 Matt Brubeck 提交于
"stmt" already includes the terminating semicolon.
-
由 bors 提交于
This is very useful when the RwLock is synchronizing access to a data structure and you would like to return or store guards which contain references to data inside the data structure instead of the data structure itself.
-
由 Paul Dicker 提交于
-
由 Paul Dicker 提交于
-
由 bors 提交于
This reports an error at the point of calling `Command::spawn()` or one of its equivalents. Fixes #30858 Fixes #30862
-
- 03 2月, 2016 21 次提交
-
-
由 Kamal Marhubi 提交于
This reports an error at the point of calling `Command::spawn()` or one of its equivalents. Fixes https://github.com/rust-lang/rust/issues/30858 Fixes https://github.com/rust-lang/rust/issues/30862
-
由 bors 提交于
r? @steveklabnik
-
由 Nikita Baksalyar 提交于
-
由 bors 提交于
I didn't change any content, just added another slash so we can see those comments in the docs r? @steveklabnik
-
由 Oliver Schneider 提交于
-
由 bors 提交于
-
由 Simonas Kazlauskas 提交于
-
由 bors 提交于
WIP implementation of #31209. The goal is to insert fake/dummy definitions for names that we failed to import so that later resolver stages won't complain about them.
-
由 Daniel Campbell 提交于
-
由 bors 提交于
Something went haywire with github last night and the old PR https://github.com/rust-lang/rust/pull/31230 got closed somehow. This new PR is to replace the old one. This incorporates all of the feedback from the other PR. @alexcrichton I incorporated the suggestion from @semarie and the result is cleaner and clearer. I think this is ready to go.
-
由 Dave Huseby 提交于
-
由 Dave Huseby 提交于
-
由 Dave Huseby 提交于
-
由 Dave Huseby 提交于
-
由 Dave Huseby 提交于
-
由 Dirk Gadsden 提交于
-
由 Dirk Gadsden 提交于
-
由 bors 提交于
This mirrors the behavior of `clang-cl.exe` by adding a `CodeView` global variable when emitting debug information. This should in turn help stack traces that are generated when code is compiled with debuginfo enabled. Closes #28133
-
由 bors 提交于
- Successful merges: #27499, #31220, #31329, #31332, #31347, #31351, #31352, #31366 - Failed merges:
-
由 Jonathan Reem 提交于
-
由 Simonas Kazlauskas 提交于
-