These functions allow to read from and write to a file from multiple
threads without changing the per-file cursor, avoiding the race between
the seek and the read.

The offset given is relative to the start of the file, independent from
the current file cursor.

These fit with other From implementations between integer types.

This helps the coding style of avoiding the 'as' operator that sometimes
silently truncates, and signals that these specific conversions are
lossless and infaillible.

For symmetry with From<char> for u32.

…on cache.

There were a bunch of more-of-less the same few lines for doing a
fill_bytes+transmute, and I didn't want to copy-paste it yet again.

This means that /dev/urandom doesn't have to be opened.

Fixes rust-lang#35753.

* A step towards rust-lang#34902
* More stable error messages in some places related to crate loading
* Possible slight performance improvements since all `HashMap`s
  replaced had small keys where `FnvHashMap` should be faster
  (although I didn't measure)

Analogous to PR rust-lang#35860.

r? @GuillaumeGomez

This fixes rust-lang#35849, a regression introduced by the typeck refactoring
around TyNever/!.

Macro expansions produce code tagged with debug locations that are completely different from the surrounding expressions.  This wrecks havoc on debugger's ability the step over source lines.

In order to have a good line stepping behavior in debugger, we overwrite debug locations of macro expansions with that of the outermost expansion site.

…lwoerister

Fix debug line number info for macro expansions.

Macro expansions result in code tagged with completely different debug locations than the surrounding expressions.  This wrecks havoc on debugger's ability the step over source lines.
This change fixes the problem by tagging expanded code as "inlined" at the macro expansion site, which allows the debugger to sort it out.
Note that only the outermost expansion is currently handled, stepping into a macro will still result in stepping craziness.

r? @eddyb

Implement `read_offset` and `write_offset`

These functions allow to read from and write to a file from multiple
threads without changing the per-file cursor, avoiding the race between
the seek and the read.

…ing, r=nikomatsakis

Implement synchronization scheme for incr. comp. directory

This PR implements a copy-on-write-based synchronization scheme for the incremental compilation cache directory. For technical details, see the documentation at the beginning of `rustc_incremental/persist/fs.rs`.

The PR contains unit tests for some functions but for testing whether the scheme properly handles races, a more elaborate test setup would be needed. It would probably involve a small tool that allows to manipulate the incremental compilation directory in a controlled way and then letting a compiler instance run against directories in different states. I don't know if it's worth the trouble of adding another test category to `compiletest`, but I'd be happy to do so.

Fixes rust-lang#32754
Fixes rust-lang#34957

…hton

Implement std::convert traits for char

This is motivated by avoiding the `as` operator, which sometimes silently truncates, and instead use conversions that are explicitly lossless and infallible.

I’m less certain that `From<u8> for char` should be implemented: while it matches an existing behavior of `as`, it’s not necessarily the right thing to use for non-ASCII bytes. It effectively decodes bytes as ISO/IEC 8859-1 (since Unicode designed its first 256 code points to be compatible with that encoding), but that is not apparent in the API name.

typeck: use NoExpectation to check return type of diverging fn

Fixes rust-lang#35849.

Thanks @eddyb.

…ichton

Use arc4rand(9) on FreeBSD

From rust-random/rand#112:

>After reading through rust-lang#30691 it seems that there's general agreement that using OS-provided facilities for seeding rust userland processes is fine as long as it doesn't use too much from libc. FreeBSD's `arc4random_buf(3)` is not only a whole lot of libc code, but also not even currently exposed in the libc crate. Fortunately, the mechanism `arc4random_buf(3)` et al. use for getting entropy from the kernel ([`arc4rand(9)`](https://www.freebsd.org/cgi/man.cgi?query=arc4random&apropos=0&sektion=9&manpath=FreeBSD+10.3-RELEASE&arch=default&format=html)) is exposed via `sysctl(3)` with constants that are already in the libc crate.

>I haven't found too much documentation on `KERN_ARND`—it's missing or only briefly described in most of the places that cover sysctl mibs. But, from digging through the kernel source, it appears that the sysctl used in this PR is very close to just calling `arc4rand(9)` directly (with `reseed` set to 0 and no way to change it).

I expected [rand](/rust-lang-nursery/rand) to reply quicker, so I tried submitting it there first. It's been a few weeks with no comment, so I don't know the state of it, but maybe someone will see it here and have an opinion. This is basically the same patch. It pains me to duplicate the code but I guess it hasn't been factored out into just one place yet.

modify fds-are-cloexec test to open a file that exists

Fixes rust-lang#35753.

Is it a valid assumption that the current directory is always the root of the repo when the tests are run?

r? @nagisa

Use `FnvHashMap` in more places

* A step towards rust-lang#34902 (see my comments there)
* More stable error messages in some places related to crate loading
* Possible slight performance improvements since all `HashMap`s
  replaced had small keys where `FnvHashMap` should be faster
  (although I didn't measure)

(likewise for `HashSet` -> `FnvHashSet`)

…hton

Change a weird line break in `core::str`

Update rust-installer. Fixes rust-lang#35840

cc @Diggsey

Mark panicking tests as `should_panic` instead of `no_run`.

None

rustc_trans: do not generate allocas for unused locals.

This fixes a regression observed in a [`mio` test](https://travis-ci.org/carllerche/mio/jobs/152142886) which was referencing a 4MB `const` array.
Even though MIR rvalue promotion would promote the borrow of the array, a dead temp was left behind.
As the array doesn't have an immediate type, an `alloca` was generated for it, even though it had no uses.

The fix is pretty dumb: assume that locals need to be borrowed or assigned before being used.
And if it can't be used, it doesn't get an `alloca`, even if the type would otherwise demand it.
This could change in the future, but all the MIR we generate now doesn't break that rule.

…ndturner

Err codes

r? @jonathandturner

…, r=GuillaumeGomez

replace `Div` example with something more evocative of division

Analogous to PR rust-lang#35860.

r? @GuillaumeGomez

Update E0195 to new error format

Fixes rust-lang#35511
Part of rust-lang#35233

r? @jonathandturner