Skip to content

Commit b796087

Browse files
borsbors
committedOct 18, 2017
Auto merge of #45368 - kennytm:rollup, r=kennytm
Rollup of 10 pull requests - Successful merges: #44138, #45082, #45098, #45181, #45217, #45281, #45325, #45326, #45340, #45354 - Failed merges:
·
1.86.01.23.0
2 parents fc208bb + 6b505d6 commit b796087

File tree

26 files changed

+401
-124
lines changed

26 files changed

+401
-124
lines changed
 

‎.travis.yml

+1-1
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ matrix:
1212
fast_finish: true
1313
include:
1414
# Images used in testing PR and try-build should be run first.
15-
- env: IMAGE=x86_64-gnu-llvm-3.7 RUST_BACKTRACE=1
15+
- env: IMAGE=x86_64-gnu-llvm-3.9 RUST_BACKTRACE=1
1616
if: type = pull_request OR branch = auto
1717

1818
- env: IMAGE=dist-x86_64-linux DEPLOY=1

‎CONTRIBUTING.md

+110
Original file line numberDiff line numberDiff line change
@@ -365,6 +365,116 @@ In order to prepare your PR, you can run the build locally by doing
365365
there, you may wish to set `submodules = false` in the `config.toml`
366366
to prevent `x.py` from resetting to the original branch.
367367

368+
#### Breaking Tools Built With The Compiler
369+
[breaking-tools-built-with-the-compiler]: #breaking-tools-built-with-the-compiler
370+
371+
Rust's build system builds a number of tools that make use of the
372+
internals of the compiler. This includes clippy,
373+
[RLS](https://github.com/rust-lang-nursery/rls) and
374+
[rustfmt](https://github.com/rust-lang-nursery/rustfmt). If these tools
375+
break because of your changes, you may run into a sort of "chicken and egg"
376+
problem. These tools rely on the latest compiler to be built so you can't update
377+
them to reflect your changes to the compiler until those changes are merged into
378+
the compiler. At the same time, you can't get your changes merged into the compiler
379+
because the rust-lang/rust build won't pass until those tools build and pass their
380+
tests.
381+
382+
That means that, in the default state, you can't update the compiler without first
383+
fixing rustfmt, rls and the other tools that the compiler builds.
384+
385+
Luckily, a feature was [added to Rust's build](https://github.com/rust-lang/rust/pull/45243)
386+
to make all of this easy to handle. The idea is that you mark the tools as "broken",
387+
so that the rust-lang/rust build passes without trying to build them, then land the change
388+
in the compiler, wait for a nightly, and go update the tools that you broke. Once you're done
389+
and the tools are working again, you go back in the compiler and change the tools back
390+
from "broken".
391+
392+
This should avoid a bunch of synchronization dances and is also much easier on contributors as
393+
there's no need to block on rls/rustfmt/other tools changes going upstream.
394+
395+
Here are those same steps in detail:
396+
397+
1. (optional) First, if it doesn't exist already, create a `config.toml` by copying
398+
`config.toml.example` in the root directory of the Rust repository.
399+
Set `submodules = false` in the `[build]` section. This will prevent `x.py`
400+
from resetting to the original branch after you make your changes. If you
401+
need to [update any submodules to their latest versions][updating-submodules],
402+
see the section of this file about that for more information.
403+
2. (optional) Run `./x.py test src/tools/rustfmt` (substituting the submodule
404+
that broke for `rustfmt`). Fix any errors in the submodule (and possibly others).
405+
3. (optional) Make commits for your changes and send them to upstream repositories as a PR.
406+
4. (optional) Maintainers of these submodules will **not** merge the PR. The PR can't be
407+
merged because CI will be broken. You'll want to write a message on the PR referencing
408+
your change, and how the PR should be merged once your change makes it into a nightly.
409+
5. Update `src/tools/toolstate.toml` to indicate that the tool in question is "broken",
410+
that will disable building it on CI. See the documentation in that file for the exact
411+
configuration values you can use.
412+
6. Commit the changes to `src/tools/toolstate.toml`, **do not update submodules in your commit**,
413+
and then update the PR you have for rust-lang/rust.
414+
7. Wait for your PR to merge.
415+
8. Wait for a nightly
416+
9. (optional) Help land your PR on the upstream repository now that your changes are in nightly.
417+
10. (optional) Send a PR to rust-lang/rust updating the submodule, reverting `src/tools/toolstate.toml` back to a "building" or "testing" state.
418+
419+
#### Updating submodules
420+
[updating-submodules]: #updating-submodules
421+
422+
These instructions are specific to updating `rustfmt`, however they may apply
423+
to the other submodules as well. Please help by improving these instructions
424+
if you find any discrepencies or special cases that need to be addressed.
425+
426+
To update the `rustfmt` submodule, start by running the appropriate
427+
[`git submodule` command](https://git-scm.com/book/en/v2/Git-Tools-Submodules).
428+
For example, to update to the latest commit on the remote master branch,
429+
you may want to run:
430+
```
431+
git submodule update --remote src/tools/rustfmt
432+
```
433+
If you run `./x.py build` now, and you are lucky, it may just work. If you see
434+
an error message about patches that did not resolve to any crates, you will need
435+
to complete a few more steps which are outlined with their rationale below.
436+
437+
*(This error may change in the future to include more information.)*
438+
```
439+
error: failed to resolve patches for `https://github.com/rust-lang-nursery/rustfmt`
440+
441+
Caused by:
442+
patch for `rustfmt-nightly` in `https://github.com/rust-lang-nursery/rustfmt` did not resolve to any crates
443+
failed to run: ~/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo build --manifest-path ~/rust/src/bootstrap/Cargo.toml
444+
```
445+
446+
If you haven't used the `[patch]`
447+
section of `Cargo.toml` before, there is [some relevant documentation about it
448+
in the cargo docs](http://doc.crates.io/manifest.html#the-patch-section). In
449+
addition to that, you should read the
450+
[Overriding dependencies](http://doc.crates.io/specifying-dependencies.html#overriding-dependencies)
451+
section of the documentation as well.
452+
453+
Specifically, the following [section in Overriding dependencies](http://doc.crates.io/specifying-dependencies.html#testing-a-bugfix) reveals what the problem is:
454+
455+
> Next up we need to ensure that our lock file is updated to use this new version of uuid so our project uses the locally checked out copy instead of one from crates.io. The way [patch] works is that it'll load the dependency at ../path/to/uuid and then whenever crates.io is queried for versions of uuid it'll also return the local version.
456+
>
457+
> This means that the version number of the local checkout is significant and will affect whether the patch is used. Our manifest declared uuid = "1.0" which means we'll only resolve to >= 1.0.0, < 2.0.0, and Cargo's greedy resolution algorithm also means that we'll resolve to the maximum version within that range. Typically this doesn't matter as the version of the git repository will already be greater or match the maximum version published on crates.io, but it's important to keep this in mind!
458+
459+
This says that when we updated the submodule, the version number in our
460+
`src/tools/rustfmt/Cargo.toml` changed. The new version is different from
461+
the version in `Cargo.lock`, so the build can no longer continue.
462+
463+
To resolve this, we need to update `Cargo.lock`. Luckily, cargo provides a
464+
command to do this easily.
465+
466+
First, go into the `src/` directory since that is where `Cargo.toml` is in
467+
the rust repository. Then run, `cargo update -p rustfmt-nightly` to solve
468+
the problem.
469+
470+
```
471+
$ cd src
472+
$ cargo update -p rustfmt-nightly
473+
```
474+
475+
This should change the version listed in `src/Cargo.lock` to the new version you updated
476+
the submodule to. Running `./x.py build` should work now.
477+
368478
## Writing Documentation
369479
[writing-documentation]: #writing-documentation
370480

‎config.toml.example

+1-1
Original file line numberDiff line numberDiff line change
@@ -35,7 +35,7 @@
3535
# If an external LLVM root is specified, we automatically check the version by
3636
# default to make sure it's within the range that we're expecting, but setting
3737
# this flag will indicate that this version check should not be done.
38-
#version-check = false
38+
#version-check = true
3939

4040
# Link libstdc++ statically into the librustc_llvm instead of relying on a
4141
# dynamic version to be available.

‎src/bootstrap/config.rs

+1
Original file line numberDiff line numberDiff line change
@@ -299,6 +299,7 @@ impl Config {
299299
let mut config = Config::default();
300300
config.llvm_enabled = true;
301301
config.llvm_optimize = true;
302+
config.llvm_version_check = true;
302303
config.use_jemalloc = true;
303304
config.backtrace = true;
304305
config.rust_optimize = true;

‎src/bootstrap/native.rs

+7-4
Original file line numberDiff line numberDiff line change
@@ -259,11 +259,14 @@ fn check_llvm_version(build: &Build, llvm_config: &Path) {
259259

260260
let mut cmd = Command::new(llvm_config);
261261
let version = output(cmd.arg("--version"));
262-
if version.starts_with("3.5") || version.starts_with("3.6") ||
263-
version.starts_with("3.7") {
264-
return
262+
let mut parts = version.split('.').take(2)
263+
.filter_map(|s| s.parse::<u32>().ok());
264+
if let (Some(major), Some(minor)) = (parts.next(), parts.next()) {
265+
if major > 3 || (major == 3 && minor >= 9) {
266+
return
267+
}
265268
}
266-
panic!("\n\nbad LLVM version: {}, need >=3.5\n\n", version)
269+
panic!("\n\nbad LLVM version: {}, need >=3.9\n\n", version)
267270
}
268271

269272
#[derive(Debug, Copy, Clone, PartialEq, Eq, Hash)]

‎src/ci/docker/x86_64-gnu-llvm-3.7/Dockerfile ‎src/ci/docker/x86_64-gnu-llvm-3.9/Dockerfile

+4-2
Original file line numberDiff line numberDiff line change
@@ -11,15 +11,17 @@ RUN apt-get update && apt-get install -y --no-install-recommends \
1111
cmake \
1212
sudo \
1313
gdb \
14-
llvm-3.7-tools \
14+
llvm-3.9-tools \
1515
libedit-dev \
1616
zlib1g-dev \
1717
xz-utils
1818

1919
COPY scripts/sccache.sh /scripts/
2020
RUN sh /scripts/sccache.sh
2121

22+
# using llvm-link-shared due to libffi issues -- see #34486
2223
ENV RUST_CONFIGURE_ARGS \
2324
--build=x86_64-unknown-linux-gnu \
24-
--llvm-root=/usr/lib/llvm-3.7
25+
--llvm-root=/usr/lib/llvm-3.9 \
26+
--enable-llvm-link-shared
2527
ENV RUST_CHECK_TARGET check

‎src/doc/unstable-book/src/language-features/lang-items.md

+92
Original file line numberDiff line numberDiff line change
@@ -227,3 +227,95 @@ A third function, `rust_eh_unwind_resume`, is also needed if the `custom_unwind_
227227
flag is set in the options of the compilation target. It allows customizing the
228228
process of resuming unwind at the end of the landing pads. The language item's name
229229
is `eh_unwind_resume`.
230+
231+
## List of all language items
232+
233+
This is a list of all language items in Rust along with where they are located in
234+
the source code.
235+
236+
- Primitives
237+
- `i8`: `libcore/num/mod.rs`
238+
- `i16`: `libcore/num/mod.rs`
239+
- `i32`: `libcore/num/mod.rs`
240+
- `i64`: `libcore/num/mod.rs`
241+
- `i128`: `libcore/num/mod.rs`
242+
- `isize`: `libcore/num/mod.rs`
243+
- `u8`: `libcore/num/mod.rs`
244+
- `u16`: `libcore/num/mod.rs`
245+
- `u32`: `libcore/num/mod.rs`
246+
- `u64`: `libcore/num/mod.rs`
247+
- `u128`: `libcore/num/mod.rs`
248+
- `usize`: `libcore/num/mod.rs`
249+
- `f32`: `libstd/f32.rs`
250+
- `f64`: `libstd/f64.rs`
251+
- `char`: `libstd_unicode/char.rs`
252+
- `slice`: `liballoc/slice.rs`
253+
- `str`: `liballoc/str.rs`
254+
- `const_ptr`: `libcore/ptr.rs`
255+
- `mut_ptr`: `libcore/ptr.rs`
256+
- `unsafe_cell`: `libcore/cell.rs`
257+
- Runtime
258+
- `start`: `libstd/rt.rs`
259+
- `eh_personality`: `libpanic_unwind/emcc.rs` (EMCC)
260+
- `eh_personality`: `libpanic_unwind/seh64_gnu.rs` (SEH64 GNU)
261+
- `eh_personality`: `libpanic_unwind/seh.rs` (SEH)
262+
- `eh_unwind_resume`: `libpanic_unwind/seh64_gnu.rs` (SEH64 GNU)
263+
- `eh_unwind_resume`: `libpanic_unwind/gcc.rs` (GCC)
264+
- `msvc_try_filter`: `libpanic_unwind/seh.rs` (SEH)
265+
- `panic`: `libcore/panicking.rs`
266+
- `panic_bounds_check`: `libcore/panicking.rs`
267+
- `panic_fmt`: `libcore/panicking.rs`
268+
- `panic_fmt`: `libstd/panicking.rs`
269+
- Allocations
270+
- `owned_box`: `liballoc/boxed.rs`
271+
- `exchange_malloc`: `liballoc/heap.rs`
272+
- `box_free`: `liballoc/heap.rs`
273+
- Operands
274+
- `not`: `libcore/ops/bit.rs`
275+
- `bitand`: `libcore/ops/bit.rs`
276+
- `bitor`: `libcore/ops/bit.rs`
277+
- `bitxor`: `libcore/ops/bit.rs`
278+
- `shl`: `libcore/ops/bit.rs`
279+
- `shr`: `libcore/ops/bit.rs`
280+
- `bitand_assign`: `libcore/ops/bit.rs`
281+
- `bitor_assign`: `libcore/ops/bit.rs`
282+
- `bitxor_assign`: `libcore/ops/bit.rs`
283+
- `shl_assign`: `libcore/ops/bit.rs`
284+
- `shr_assign`: `libcore/ops/bit.rs`
285+
- `deref`: `libcore/ops/deref.rs`
286+
- `deref_mut`: `libcore/ops/deref.rs`
287+
- `index`: `libcore/ops/index.rs`
288+
- `index_mut`: `libcore/ops/index.rs`
289+
- `add`: `libcore/ops/arith.rs`
290+
- `sub`: `libcore/ops/arith.rs`
291+
- `mul`: `libcore/ops/arith.rs`
292+
- `div`: `libcore/ops/arith.rs`
293+
- `rem`: `libcore/ops/arith.rs`
294+
- `neg`: `libcore/ops/arith.rs`
295+
- `add_assign`: `libcore/ops/arith.rs`
296+
- `sub_assign`: `libcore/ops/arith.rs`
297+
- `mul_assign`: `libcore/ops/arith.rs`
298+
- `div_assign`: `libcore/ops/arith.rs`
299+
- `rem_assign`: `libcore/ops/arith.rs`
300+
- `eq`: `libcore/cmp.rs`
301+
- `ord`: `libcore/cmp.rs`
302+
- Functions
303+
- `fn`: `libcore/ops/function.rs`
304+
- `fn_mut`: `libcore/ops/function.rs`
305+
- `fn_once`: `libcore/ops/function.rs`
306+
- `generator_state`: `libcore/ops/generator.rs`
307+
- `generator`: `libcore/ops/generator.rs`
308+
- Other
309+
- `coerce_unsized`: `libcore/ops/unsize.rs`
310+
- `drop`: `libcore/ops/drop.rs`
311+
- `drop_in_place`: `libcore/ptr.rs`
312+
- `clone`: `libcore/clone.rs`
313+
- `copy`: `libcore/marker.rs`
314+
- `send`: `libcore/marker.rs`
315+
- `sized`: `libcore/marker.rs`
316+
- `unsize`: `libcore/marker.rs`
317+
- `sync`: `libcore/marker.rs`
318+
- `phantom_data`: `libcore/marker.rs`
319+
- `freeze`: `libcore/marker.rs`
320+
- `debug_trait`: `libcore/fmt/mod.rs`
321+
- `non_zero`: `libcore/nonzero.rs`

‎src/doc/unstable-book/src/library-features/alloc-jemalloc.md

+2-51
Original file line numberDiff line numberDiff line change
@@ -8,55 +8,6 @@ See also [`alloc_system`](library-features/alloc-system.html).
88

99
------------------------
1010

11-
The compiler currently ships two default allocators: `alloc_system` and
12-
`alloc_jemalloc` (some targets don't have jemalloc, however). These allocators
13-
are normal Rust crates and contain an implementation of the routines to
14-
allocate and deallocate memory. The standard library is not compiled assuming
15-
either one, and the compiler will decide which allocator is in use at
16-
compile-time depending on the type of output artifact being produced.
17-
18-
Binaries generated by the compiler will use `alloc_jemalloc` by default (where
19-
available). In this situation the compiler "controls the world" in the sense of
20-
it has power over the final link. Primarily this means that the allocator
21-
decision can be left up the compiler.
22-
23-
Dynamic and static libraries, however, will use `alloc_system` by default. Here
24-
Rust is typically a 'guest' in another application or another world where it
25-
cannot authoritatively decide what allocator is in use. As a result it resorts
26-
back to the standard APIs (e.g. `malloc` and `free`) for acquiring and releasing
27-
memory.
28-
29-
# Switching Allocators
30-
31-
Although the compiler's default choices may work most of the time, it's often
32-
necessary to tweak certain aspects. Overriding the compiler's decision about
33-
which allocator is in use is done simply by linking to the desired allocator:
34-
35-
```rust,no_run
36-
#![feature(alloc_system)]
37-
38-
extern crate alloc_system;
39-
40-
fn main() {
41-
let a = Box::new(4); // Allocates from the system allocator.
42-
println!("{}", a);
43-
}
44-
```
45-
46-
In this example the binary generated will not link to jemalloc by default but
47-
instead use the system allocator. Conversely to generate a dynamic library which
48-
uses jemalloc by default one would write:
49-
50-
```rust,ignore
51-
#![feature(alloc_jemalloc)]
52-
#![crate_type = "dylib"]
53-
54-
extern crate alloc_jemalloc;
55-
56-
pub fn foo() {
57-
let a = Box::new(4); // Allocates from jemalloc.
58-
println!("{}", a);
59-
}
60-
# fn main() {}
61-
```
11+
This feature has been replaced by [the `jemallocator` crate on crates.io.][jemallocator].
6212

13+
[jemallocator]: https://crates.io/crates/jemallocator

0 commit comments

Comments
 (0)
Please sign in to comment.