bors [Mon, 15 Jun 2015 06:44:42 +0000 (06:44 +0000)]
Auto merge of #26168 - sfackler:stdout-panic, r=alexcrichton
Closes #25977
The various `stdfoo_raw` methods in std::io now return `io::Result`s,
since they may not exist on Windows. They will always return `Ok` on
Unix-like platforms.
bors [Mon, 15 Jun 2015 05:11:53 +0000 (05:11 +0000)]
Auto merge of #25359 - thepowersgang:result-expect-2, r=alexcrichton
As it says in the title. I've added an `expect` method to `Result` that allows printing both an error message (e.g. what operation was attempted), and the error value. This is separate from the `unwrap` and `ok().expect("message")` behaviours.
Steven Fackler [Wed, 10 Jun 2015 04:39:36 +0000 (21:39 -0700)]
Implement RFC 1014
Closes #25977
The various `stdfoo_raw` methods in std::io now return `io::Result`s,
since they may not exist on Windows. They will always return `Ok` on
Unix-like platforms.
bors [Sun, 14 Jun 2015 19:42:26 +0000 (19:42 +0000)]
Auto merge of #26071 - petrochenkov:assert1, r=alexcrichton
`assert_eq!` has better diagnostics than `assert!` and is more helpful when something actually breaks, but the diagnostics has it's price - `assert_eq!` generate some formatting code which is slower to compile and possibly run.
[My measurements](https://internals.rust-lang.org/t/assert-a-b-or-assert-eq-a-b/1367/12?u=petrochenkov) show that presence of this formatting code doesn't affect compilation + execution time of the test suite significantly, so `assert_eq!` can be used instead of `assert!` consistently.
(Some tests doesn't reside in src/test, they are not affected by these changes, I'll probably open a separate PR for them later)
bors [Sun, 14 Jun 2015 17:18:25 +0000 (17:18 +0000)]
Auto merge of #26296 - aidanhs:aphs-fix-musl-make-install, r=alexcrichton
musl only creates rlib files for stdlib linking so we need to ignore the `CFG_LIB_GLOB_` setting, otherwise we an error:
```
$ make --debug VERBOSE=1 dist-tar-bins
[...]
Successfully remade target file `prepare-target-x86_64-unknown-linux-gnu-host-x86_64-unknown-linux-gnu-2-dir-x86_64-unknown-linux-gnu'.
File `prepare-target-x86_64-unknown-linux-musl-host-x86_64-unknown-linux-gnu-2-dir-x86_64-unknown-linux-gnu' does not exist.
Must remake target `prepare-target-x86_64-unknown-linux-musl-host-x86_64-unknown-linux-gnu-2-dir-x86_64-unknown-linux-gnu'.
umask 022 && mkdir -p tmp/dist/rustc-1.2.0-dev-x86_64-unknown-linux-gnu-image/lib/rustlib/x86_64-unknown-linux-musl/lib
umask 022 && mkdir -p tmp/dist/rustc-1.2.0-dev-x86_64-unknown-linux-gnu-image/lib/rustlib/x86_64-unknown-linux-gnu/bin
LIB_NAME="liblibc-d8ace771.rlib"; MATCHES=""; if [ -n "$MATCHES" ]; then echo "warning: one or libraries matching Rust library 'liblibc-*.rlib'" && echo " (other than '$LIB_NAME' itself) alre
ady present" && echo " at destination tmp/dist/rustc-1.2.0-dev-x86_64-unknown-linux-gnu-image/lib/rustlib/x86_64-unknown-linux-musl/lib:" && echo $MATCHES ; fi
install -m644 `ls -drt1 x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-*.rlib` tmp/dist/rustc-1.2.0-dev-x86_64-unknown-linux-gnu-image/lib/rustlib/x86_64-unk
nown-linux-musl/lib/
LIB_NAME=""; MATCHES=""; if [ -n "$MATCHES" ]; then echo "warning: one or libraries matching Rust library 'libstd-*.so'" && echo " (other than '$LIB_NAME' itself) already present" && echo
" at destination tmp/dist/rustc-1.2.0-dev-x86_64-unknown-linux-gnu-image/lib/rustlib/x86_64-unknown-linux-musl/lib:" && echo $MATCHES ; fi
install -m644 `ls -drt1 x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-*.so` tmp/dist/rustc-1.2.0-dev-x86_64-unknown-linux-gnu-image/lib/rustlib/x86_64-unknow
n-linux-musl/lib/
ls: cannot access x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-*.so: No such file or directory
install: missing destination file operand after ‘tmp/dist/rustc-1.2.0-dev-x86_64-unknown-linux-gnu-image/lib/rustlib/x86_64-unknown-linux-musl/lib/’
Try 'install --help' for more information.
make: *** [prepare-target-x86_64-unknown-linux-musl-host-x86_64-unknown-linux-gnu-2-dir-x86_64-unknown-linux-gnu] Error 1
```
`CFG_INSTALL_ONLY_RLIB_` is provided for this reason and fixes `make install` and `make dist`.
bors [Sun, 14 Jun 2015 11:20:36 +0000 (11:20 +0000)]
Auto merge of #26252 - bluss:relative-paths, r=alexcrichton
mk: Build crates with relative source file paths
The path we pass to rustc will be visible in panic messages and
backtraces: they will be user visible!
Avoid junk in these paths by passing relative paths to rustc.
For most advanced users, `libcore` or `libstd` in the path will be
a clue to the location -- inside our code, not theirs.
Store both the relative path to the source as well as the absolute.
Use the relative path where it matters, compiling the main crates,
instead of changing all of the build process to cope with relative
paths.
Example output after this patch:
```
$ ./testunwrap
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362
$ RUST_BACKTRACE=1 ./testunwrap
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362
stack backtrace:
1: 0x7ff59c1e9956 - sys::backtrace::write::h67a542fd2b201576des
at ../src/libstd/sys/unix/backtrace.rs:158
2: 0x7ff59c1ed5b6 - panicking::on_panic::h3d21c41cdd5c12d41Xw
at ../src/libstd/panicking.rs:58
3: 0x7ff59c1e7b6e - rt::unwind::begin_unwind_inner::h9f3a5440cebb8baeLDw
at ../src/libstd/rt/unwind/mod.rs:273
4: 0x7ff59c1e7f84 - rt::unwind::begin_unwind_fmt::h4fe8a903e0c296b0RCw
at ../src/libstd/rt/unwind/mod.rs:212
5: 0x7ff59c1eced7 - rust_begin_unwind
6: 0x7ff59c22c11a - panicking::panic_fmt::h00b0cd49c98a9220i5B
at ../src/libcore/panicking.rs:64
7: 0x7ff59c22b9e0 - panicking::panic::hf549420c0ee03339P3B
at ../src/libcore/panicking.rs:45
8: 0x7ff59c1e621d - option::Option<T>::unwrap::h501963526474862829
9: 0x7ff59c1e61b1 - main::hb5c91ce92347d1e6eaa
10: 0x7ff59c1f1c18 - rust_try_inner
11: 0x7ff59c1f1c05 - rust_try
12: 0x7ff59c1ef374 - rt::lang_start::h7e51e19c6677cffe5Sw
at ../src/libstd/rt/unwind/mod.rs:147
at ../src/libstd/rt/unwind/mod.rs:130
at ../src/libstd/rt/mod.rs:128
13: 0x7ff59c1e628e - main
14: 0x7ff59b3f6b44 - __libc_start_main
15: 0x7ff59c1e6078 - <unknown>
16: 0x0 - <unknown>
```
bors [Sat, 13 Jun 2015 20:33:53 +0000 (20:33 +0000)]
Auto merge of #26249 - steveklabnik:remove_extern_panic, r=alexcrichton
This test has an interesting history, because of fail -> panic. It was
originally called extern-fail.rs:
https://github.com/rust-lang/rust/commits/master/src/test/run-fail/extern-fail.rs
As you can see, that failure was not specific to this test, however,
this code does stuff with the runtime, which was removed. Given that
it hasn't even been able to compile in a long time, we should just
remove it.
Ulrik Sverdrup [Fri, 12 Jun 2015 17:40:07 +0000 (19:40 +0200)]
mk: Build crates with relative paths to rustc
The path we pass to rustc will be visible in panic messages and
backtraces: they will be user visible!
Avoid junk in these paths by passing relative paths to rustc.
For most advanced users, `libcore` or `libstd` in the path will be
a clue to the location -- inside our code, not theirs.
Store both the relative path to the source as well as the absolute.
Use the relative path where it matters, compiling the main crates,
instead of changing all of the build process to cope with relative
paths.
Example output after this patch:
```
$ ./testunwrap
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362
$ RUST_BACKTRACE=1 ./testunwrap
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362
stack backtrace:
1: 0x7ff59c1e9956 - sys::backtrace::write::h67a542fd2b201576des
at ../src/libstd/sys/unix/backtrace.rs:158
2: 0x7ff59c1ed5b6 - panicking::on_panic::h3d21c41cdd5c12d41Xw
at ../src/libstd/panicking.rs:58
3: 0x7ff59c1e7b6e - rt::unwind::begin_unwind_inner::h9f3a5440cebb8baeLDw
at ../src/libstd/rt/unwind/mod.rs:273
4: 0x7ff59c1e7f84 - rt::unwind::begin_unwind_fmt::h4fe8a903e0c296b0RCw
at ../src/libstd/rt/unwind/mod.rs:212
5: 0x7ff59c1eced7 - rust_begin_unwind
6: 0x7ff59c22c11a - panicking::panic_fmt::h00b0cd49c98a9220i5B
at ../src/libcore/panicking.rs:64
7: 0x7ff59c22b9e0 - panicking::panic::hf549420c0ee03339P3B
at ../src/libcore/panicking.rs:45
8: 0x7ff59c1e621d - option::Option<T>::unwrap::h501963526474862829
9: 0x7ff59c1e61b1 - main::hb5c91ce92347d1e6eaa
10: 0x7ff59c1f1c18 - rust_try_inner
11: 0x7ff59c1f1c05 - rust_try
12: 0x7ff59c1ef374 - rt::lang_start::h7e51e19c6677cffe5Sw
at ../src/libstd/rt/unwind/mod.rs:147
at ../src/libstd/rt/unwind/mod.rs:130
at ../src/libstd/rt/mod.rs:128
13: 0x7ff59c1e628e - main
14: 0x7ff59b3f6b44 - __libc_start_main
15: 0x7ff59c1e6078 - <unknown>
16: 0x0 - <unknown>
```
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
Steve Klabnik [Fri, 12 Jun 2015 17:11:17 +0000 (13:11 -0400)]
Remove old runtime panic test
This test has an interesting history, because of fail -> panic. It was
originally called extern-fail.rs:
https://github.com/rust-lang/rust/commits/master/src/test/run-fail/extern-fail.rs
As you can see, that failure was not specific to this test, however,
this code does stuff with the runtime, which was removed. Given that
it hasn't even been able to compile in a long time, we should just
remove it.
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.
projects / rust.git / log