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 #32759

Closed
wants to merge 23 commits into from
Closed

Conversation

frewsxcv and others added 11 commits April 1, 2016 10:18
(1) `x` can be used in main() after the call to spawn(). Because the variables follow normal move semantics, though the keyword `move` is used, and i32 implements `Copy`.
(2) I remove this sentence because the previous sentence gives the referrence to `move closures`, and more description of `move` may be redundant.
Starting with the 1.10.0 release we would like to bootstrap all compilers from
the previous stable release. For example the 1.10.0 compiler should bootstrap
from the literal 1.9.0 release artifacts. To do this, however, we need a way to
enable unstable features temporarily in a stable compiler (as the released
compiler is stable), but it turns out we already have a way to do that!

At compile time the configure script selects a `CFG_BOOTSTRAP_KEY` variable
value and then exports it into the makefiles. If the `RUSTC_BOOTSTRAP_KEY`
environment variable is set to this value, then the compiler is allowed to
"cheat" and use unstable features.

This method of choosing the bootstrap key, however, is problematic for the
intention of bootstrapping from the previous release. Each time a 1.9.0 compiler
is created, a new bootstrap key will be selected. That means that the 1.10.0
compiler will only compile from *our* literal release artifacts. Instead
distributions would like to bootstrap from their own compilers, so instead we
simply hardcode the bootstrap key for each release.

This patch uses the same `CFG_FILENAME_EXTRA` value (a hash of the release
string) as the bootstrap key. Consequently all 1.9.0 compilers, no matter where
they are compiled, will have the same bootstrap key. Additionally we won't need
to keep updating this as it'll be based on the release number anyway.

Once the 1.9.0 beta has been created, we can update the 1.10.0 nightly sources
(the `master` branch at that time) to bootstrap from that release using this
hard-coded bootstrap key. We will likely just hardcode into the makefiles what
the previous bootstrap key was and we'll change that whenever the stage0
compiler is updated.
We need to supply sext/zext attributes to LLVM to ensure that arguments
are extended to the appropriate width in the correct way.

Most platforms extend integers less than 32 bits, though not all.
Conflicts:
	src/doc/book/concurrency.md
The initial implementation of specialization did not use the
`fast_reject` mechanism when checking for overlap, which caused a
serious performance regression in some cases.

This commit modifies the specialization graph to use simplified types
for fast rejection when possible, and along the way refactors the logic
for building the specialization graph.

Closes rust-lang#32499
1. In the English/Japanese phrases example in the "Multiple File
Crates" section of the "Crates and Modules" chapter, there are a total
of 8 module files that Rust looks for, while only four were
listed. This commit lists all 8 explicitly.
2. Title case fix.
@rust-highfive
Copy link
Collaborator

r? @Aatch

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

@Manishearth
Copy link
Member Author

@bors r+ p=20

@bors
Copy link
Contributor

bors commented Apr 6, 2016

📌 Commit 9b40635 has been approved by Manishearth

@bors
Copy link
Contributor

bors commented Apr 6, 2016

⌛ Testing commit 9b40635 with merge 36622ee...

@bors
Copy link
Contributor

bors commented Apr 6, 2016

💔 Test failed - auto-win-msvc-64-opt-rustbuild

Manishearth and others added 4 commits April 6, 2016 11:08
doc: there is no case that is shown, so something was likely missing …

…from the change
…abnik

Mention that it's not actually a data race

The example can't cause a data race since different indices are accesed.

(perhaps we should use an example where i iterates twice?)

r? @steveklabnik
Minor doc fixes in "Crates and Modules" and "Lifetimes" chapters

These commits fix a couple of (minor) issues in the _Crates and Modules_ and the _Lifetimes_ chapters of the book.

r? @steveklabnik
@Manishearth
Copy link
Member Author

@bors r+ force

@bors
Copy link
Contributor

bors commented Apr 6, 2016

📌 Commit 8044c4b has been approved by Manishearth

@bors
Copy link
Contributor

bors commented Apr 6, 2016

⌛ Testing commit 8044c4b with merge 21d127b...

@bors
Copy link
Contributor

bors commented Apr 6, 2016

💔 Test failed - auto-linux-64-opt-mir

…lexcrichton

Address FIXMEs related to short lifetimes in `HashMap`.

None
Remove error description of `move`

(1) `x` can be used in main() after the call to spawn(). Because the variables follow normal move semantics, though the keyword `move` is used, and i32 implements `Copy`.
(2) I remove this sentence because the previous sentence gives the referrence to `move closures`, and more description of `move` may be redundant.
…=brson

mk: Hardcode the bootstrap key for each release

Starting with the 1.10.0 release we would like to bootstrap all compilers from
the previous stable release. For example the 1.10.0 compiler should bootstrap
from the literal 1.9.0 release artifacts. To do this, however, we need a way to
enable unstable features temporarily in a stable compiler (as the released
compiler is stable), but it turns out we already have a way to do that!

At compile time the configure script selects a `CFG_BOOTSTRAP_KEY` variable
value and then exports it into the makefiles. If the `RUSTC_BOOTSTRAP_KEY`
environment variable is set to this value, then the compiler is allowed to
"cheat" and use unstable features.

This method of choosing the bootstrap key, however, is problematic for the
intention of bootstrapping from the previous release. Each time a 1.9.0 compiler
is created, a new bootstrap key will be selected. That means that the 1.10.0
compiler will only compile from *our* literal release artifacts. Instead
distributions would like to bootstrap from their own compilers, so instead we
simply hardcode the bootstrap key for each release.

This patch uses the same `CFG_FILENAME_EXTRA` value (a hash of the release
string) as the bootstrap key. Consequently all 1.9.0 compilers, no matter where
they are compiled, will have the same bootstrap key. Additionally we won't need
to keep updating this as it'll be based on the release number anyway.

Once the 1.9.0 beta has been created, we can update the 1.10.0 nightly sources
(the `master` branch at that time) to bootstrap from that release using this
hard-coded bootstrap key. We will likely just hardcode into the makefiles what
the previous bootstrap key was and we'll change that whenever the stage0
compiler is updated.
Handle integer-extending for C ABI

We need to supply sext/zext attributes to LLVM to ensure that arguments
are extended to the appropriate width in the correct way.

Most platforms extend integers less than 32 bits, though not all.
Remove strange names created by lack of privacy-conscious name lookup

The fixed issue that allowed this was rust-lang#12808.
Reinstate fast_reject for overlap checking

The initial implementation of specialization did not use the
`fast_reject` mechanism when checking for overlap, which caused a
serious performance regression in some cases.

This commit modifies the specialization graph to use simplified types
for fast rejection when possible, and along the way refactors the logic
for building the specialization graph.

Closes rust-lang#32499

r? @nikomatsakis
Fix typos in atomic compare_exchange.

Failure ordering can't be Release, not (not) Acquire. Seems like a typo copy-pasted all over.
@Manishearth
Copy link
Member Author

@bors r+ force

@bors
Copy link
Contributor

bors commented Apr 6, 2016

📌 Commit ee55501 has been approved by Manishearth

@Manishearth
Copy link
Member Author

@bors force

@Manishearth
Copy link
Member Author

@bors force retry

@bors
Copy link
Contributor

bors commented Apr 6, 2016

⌛ Testing commit ee55501 with merge 6409dfe...

@bors
Copy link
Contributor

bors commented Apr 6, 2016

💔 Test failed - auto-mac-32-opt

@Manishearth
Copy link
Member Author

Travis seems to think tidy is fine but buildbot doesn't?

check: formatting
/Users/rustbuild/src/rust-buildbot/slave/auto-mac-32-opt/build/src/librustc/traits/error_reporting.rs:439: line longer than 100 chars
/Users/rustbuild/src/rust-buildbot/slave/auto-mac-32-opt/build/src/test/compile-fail/substs-verbose.rs:13: TODO is deprecated; use FIXME

* linted 6854 .rs files

looks like some leftover files?

@Manishearth Manishearth closed this Apr 6, 2016
@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.