Most of these are old, but some specific messages for specific tests:
* trait-contravariant-self.rs: failed due to a soundess hole:
05e3248a79
* process-detatch: 15966c3c1f
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
Addresses a chunk of #3965
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
It lived for a while, but was disabled in August 2013:
ce95b01014
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.
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. :) )
Suggesting this because I was confused by what is now visible from the Travis CI / buildbot split.
Found the hint in bors comments on d911936d
Couldn't find anything on https://internals.rust-lang.org/
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`.
`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:🔙: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.
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`.
These errors all relate to type checking, specifically the number of function arguments, and occur in librustc_typeck::check::check_argument_types.
Resolves part of #24407.
* 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`.
cc #25494
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.
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.
r? @steveklabnik
These errors all relate to type checking, specifically the number of function arguments, and occur in librustc_typeck::check::check_argument_types.
Resolves part of #24407.
… 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.
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
