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 13 pull requests #35945

Closed
wants to merge 38 commits into from
Closed

Rollup of 13 pull requests #35945

wants to merge 38 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.
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.
This fixes rust-lang#35849, a regression introduced by the typeck refactoring
around TyNever/!.
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
Remove the old AST-based backend from rustc_trans.

Starting with Rust 1.13, `--disable-orbit` , `-Z orbit=off` and `#[rustc_no_mir]` have been removed.
Only the new MIR backend is left in the compiler, and only early const_eval uses ASTs from other crates.

Filling drop (previously "zeroing drop"), `#[unsafe_no_drop_flag]` and associated unstable APIs are gone.
Implementing `Drop` doesn't add a flag anymore to the type, all of the dynamic drop is function local.
This is a [breaking-change], please use `Option::None` and/or `mem::forget` if you are unsure about your ability to prevent/control the drop of a value. In the future, `union` will be usable in some such cases.

**NOTE**: DO NOT MERGE before we get the new beta as the stage0, there's some cruft to remove.

All of this will massively simplify any efforts to implement (and as such it blocks) features such as `union`s, safe use of `#[packed]` or new type layout optimizations, not to mention many other experiments.
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.
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? @pnkfelix

(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 d7b694f has been approved by eddyb

@eddyb
Copy link
Member Author

eddyb commented Aug 23, 2016

@bors force

@bors
Copy link
Contributor

bors commented Aug 23, 2016

⌛ Testing commit d7b694f with merge eb6267b...

@bors
Copy link
Contributor

bors commented Aug 23, 2016

💔 Test failed - auto-linux-cross-opt

@eddyb
Copy link
Member Author

eddyb commented Aug 23, 2016

Why do I even bother

@eddyb eddyb closed this Aug 23, 2016
@eddyb eddyb deleted the rollup branch August 23, 2016 18:30
@eddyb eddyb restored the rollup branch August 23, 2016 18:38
@eddyb
Copy link
Member Author

eddyb commented Aug 23, 2016

Ah I broke the bots anyway.

@eddyb eddyb reopened this Aug 23, 2016
@eddyb
Copy link
Member Author

eddyb commented Aug 23, 2016

@bors r+ p=100

@bors
Copy link
Contributor

bors commented Aug 23, 2016

💡 This pull request was already approved, no need to approve it again.

@bors
Copy link
Contributor

bors commented Aug 23, 2016

📌 Commit d7b694f has been approved by eddyb

@eddyb
Copy link
Member Author

eddyb commented Aug 23, 2016

@bors retry

@eddyb
Copy link
Member Author

eddyb commented Aug 23, 2016

@bors force clean

@bors
Copy link
Contributor

bors commented Aug 23, 2016

⌛ Testing commit d7b694f with merge 1487ad0...

@bors
Copy link
Contributor

bors commented Aug 23, 2016

💔 Test failed - auto-linux-cross-opt

@eddyb
Copy link
Member Author

eddyb commented Aug 23, 2016

Still FUBAR sigh.

@eddyb eddyb closed this Aug 23, 2016
@eddyb eddyb deleted the rollup branch August 23, 2016 19:00
@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.