bors [Fri, 12 Jun 2015 23:05:06 +0000 (23:05 +0000)]
Auto merge of #26160 - alexcrichton:revert-rc-as-ref, r=aturon
This is a revert of PR #26008 which caused the unintended breakage reported in #26096. We may want to add these implementations in the long run, but for now this revert allows us to take some more time to evaluate the impact of such a change (e.g. run it through crater).
The `os::unix::fs::Metadata` structure was also removed entirely, moving all of
its associated methods into the `os::unix::fs::MetadataExt` trait instead. The
methods are all marked as `#[stable]` still.
As some minor cleanup, some deprecated and unstable fs apis were also removed:
Features that were explicitly left unstable include:
* fs::WalkDir - the semantics of this were not considered in the recent fs
expansion RFC.
* fs::DirBuilder - it's still not 100% clear if the naming is right here and if
the set of functionality exposed is appropriate.
* fs::canonicalize - the implementation on Windows here is specifically in
question as it always returns a verbatim path. Additionally the Unix
implementation is susceptible to buffer overflows on long paths unfortunately.
* fs::PathExt - as this is just a convenience trait, it is not stabilized at
this time.
* fs::set_file_times - this funciton is still waiting on a time abstraction.
* process-detatch: https://github.com/rust-lang/rust/commit/15966c3c1f99810ac81053769651776a67181dae
says "this test is being ignored until signals are implemented" That's
not happening for a long time, and when it is, we'll write tests for
it.
* deep-vector{,2}.rs: "too big for our poor macro infrastructure", and has
been ignored over a year.
* borrowck-nested-calls.rs's FIXME #6268 was closed in favor of
rust-lang/rfcs#811
* issue-15167.rs works properly now
* issue-9737.rs works properly now
* match-var-hygiene.rs works properly now
Rollup merge of #24495 - nathanl:nathanl-explain-bin-flag, r=steveklabnik
Explain the --bin flag in terms of the difference
between shipping binary and library code
I'm not sure if my explanation is even quite correct, but as a newbie coming from Ruby, this is my best guess. (In Rubyland, libraries always ship with the source code because there's no other form you can ship. :) )
bors [Fri, 12 Jun 2015 01:36:55 +0000 (01:36 +0000)]
Auto merge of #26226 - alexcrichton:fix-msvc-dist, r=brson
Right now the distribution tarball for MSVC only includes the *.dll files for
the supporting libraries, but not the corresponding *.lib files which allow
actually linking to the dll. This means that the current MSVC nightlies cannot
produce dynamically linked binaries as the *.lib files are not available to link
against.
This commit modifies the `LIB_GLOB` used to copy the files around to include the
`lib` variant of the `dll`.
bors [Thu, 11 Jun 2015 21:35:10 +0000 (21:35 +0000)]
Auto merge of #26199 - swgillespie:issue-26092, r=alexcrichton
`driver::build_output_filenames` calls `file_stem` on a PathBuf obtained from the output file compiler flag. It's possible to pass the empty string to this compiler flag. When file_stem is called on an empty Path, it returns None, which is unwrapped and the compiler panics.
This change modifies the `unwrap` to an `unwrap_or` so that the empty string is passed through the compilation pipeline until it reaches `trans::back::write_output_file`, which will emit an appropriate error.
Instead of panicking, the error that is emitted now is:
```
$ rustc -o "" thing.rs
error: could not write output to : No such file or directory
```
The `:` is a little strange, but it /is/ reporting the filename (the empty string) correctly, I suppose. Both gcc and clang hand the output file to ld, which emits a similar error message when faced with the empty string as an output file:
```
$ clang -o "" thing.c
ld: can't open output file for writing: , errno=2 for architecture x86_64
```
This PR also adds a test for this, in `run-make`. This fixes issue #26092.
Alex Crichton [Thu, 11 Jun 2015 20:50:56 +0000 (13:50 -0700)]
mk: Tweak the LIB_GLOB for MSVC
Right now the distribution tarball for MSVC only includes the *.dll files for
the supporting libraries, but not the corresponding *.lib files which allow
actually linking to the dll. This means that the current MSVC nightlies cannot
produce dynamically linked binaries as the *.lib files are not available to link
against.
This commit modifies the `LIB_GLOB` used to copy the files around to include the
`lib` variant of the `dll`.
bors [Thu, 11 Jun 2015 08:22:39 +0000 (08:22 +0000)]
Auto merge of #26159 - alexcrichton:tweak-process-lowering-raising, r=brson
* Slate these features to be stable in 1.2 instead of 1.1 (not being backported)
* Have the `FromRawFd` implementations follow the contract of the `FromRawFd`
trait by taking ownership of the primitive specified.
* Refactor the implementations slightly to remove the `unreachable!` blocks as
well as separating the stdio representation of `std::process` from
`std::sys::process`.
Rollup merge of #26202 - nham:revise_E0072, r=alexcrichton
Converts the size calculation in the explanation from a fenced code block to an indented one. I think it looks better when not rendered, and is the same rendered.
Rollup merge of #26191 - jimblandy:master, r=steveklabnik
In the discussion of returning closures, it seems like the example code got simplified, but only the later copies got fixed. The final working code has `factory` returning `|x| x + num`, but the earlier code has `|x| vec.push(x)`.
The first form seemed to have more distracting characteristics, and the code wasn't right anyway, so I changed them to all use the second form, and updated the error messages.
Rollup merge of #26181 - Stebalien:fix-26178, r=steveklabnik
The list of in-production users is probably incomplete. It's based on a [post](https://www.reddit.com/r/rust/comments/2x567m/who_is_using_rust_or_what_projects_that_are/cox7eby) by /u/mozilla_kmc
bors [Thu, 11 Jun 2015 06:46:25 +0000 (06:46 +0000)]
Auto merge of #26155 - dhuseby:fixing_bitrig_net_tests, r=alexcrichton
… congruent due to rounding errors
@semarie this affected both openbsd and bitrig. it seems the correct solution is to switch to fixed point arithmetic in the timeout code, the same as freebsd.
bors [Thu, 11 Jun 2015 05:05:20 +0000 (05:05 +0000)]
Auto merge of #26154 - pmarcelll:master, r=Gankro
Various methods in both libcore/char.rs and librustc_unicode/char.rs were previously marked with #[inline], now every method is marked in char's impl blocks.
Partially fixes #26124.
EDIT: I'm not familiar with pull reqests (yet), apparently Github added my second commit to thit PR...
Fixes #26124
bors [Wed, 10 Jun 2015 22:37:38 +0000 (22:37 +0000)]
Auto merge of #25777 - shepmaster:cstring-return-to-c, r=alexcrichton
As far as I was able to determine, it's currently *impossible* to allocate a C NUL-terminated string in Rust and then return it to C (transferring ownership), without leaking memory. There is support for passing the string to C (borrowing).
To complicate matters, it's not possible for the C code to just call `free` on the allocated string, due to the different allocators in use.
`CString` has no way to recreate itself from a pointer. This commit adds one. This is complicated a bit because Rust `Vec`s want the pointer, size, and capacity.
To deal with that, another method to shrink and "leak" the `CString` to a `char *` is also provided.
We can then use `strlen` to determine the length of the string, which must match the capacity.
Alex Crichton [Tue, 9 Jun 2015 23:41:14 +0000 (16:41 -0700)]
std: Tweak process raising/lowering implementations
* Slate these features to be stable in 1.2 instead of 1.1 (not being backported)
* Have the `FromRawFd` implementations follow the contract of the `FromRawFd`
trait by taking ownership of the primitive specified.
* Refactor the implementations slightly to remove the `unreachable!` blocks as
well as separating the stdio representation of `std::process` from
`std::sys::process`.
The `os::unix::fs::Metadata` structure was also removed entirely, moving all of
its associated methods into the `os::unix::fs::MetadataExt` trait instead. The
methods are all marked as `#[stable]` still.
As some minor cleanup, some deprecated and unstable fs apis were also removed:
Features that were explicitly left unstable include:
* fs::WalkDir - the semantics of this were not considered in the recent fs
expansion RFC.
* fs::DirBuilder - it's still not 100% clear if the naming is right here and if
the set of functionality exposed is appropriate.
* fs::canonicalize - the implementation on Windows here is specifically in
question as it always returns a verbatim path. Additionally the Unix
implementation is susceptible to buffer overflows on long paths unfortunately.
* fs::PathExt - as this is just a convenience trait, it is not stabilized at
this time.
* fs::set_file_times - this funciton is still waiting on a time abstraction.