Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 15 pull requests #35944

Closed
wants to merge 40 commits into from
Closed

Rollup of 15 pull requests #35944

wants to merge 40 commits into from

Conversation

tbu- and others added 30 commits August 16, 2016 02:15
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.
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.
* 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)
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`
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.
…, r=GuillaumeGomez

replace `Div` example with something more evocative of division

Analogous to PR rust-lang#35860.

r? @GuillaumeGomez
@rust-highfive
Copy link
Collaborator

r? @Aatch

(rust_highfive has picked a reviewer for you, use r? to override)

@eddyb
Copy link
Member Author

eddyb commented Aug 23, 2016

@bors r+ p=100

@bors
Copy link
Contributor

bors commented Aug 23, 2016

📌 Commit 26432c6 has been approved by eddyb

@bors
Copy link
Contributor

bors commented Aug 23, 2016

🔒 Merge conflict

@bors
Copy link
Contributor

bors commented Aug 23, 2016

☔ The latest upstream changes (presumably #35656) made this pull request unmergeable. Please resolve the merge conflicts.

@eddyb eddyb closed this Aug 23, 2016
@eddyb eddyb deleted the rollup branch August 23, 2016 18:17
@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup
Projects
None yet
Development

Successfully merging this pull request may close these issues.