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 8 pull requests #52199

Closed
wants to merge 22 commits into from

Conversation

Mark-Simulacrum
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

Aaron Power and others added 22 commits June 22, 2018 21:23
The docs were not specifying how to compute the alignment of the struct, so I had to spend some time trying to figure out how that works. Found the answer [on this page](http://camlorn.net/posts/April%202017/rust-struct-field-reordering.html):

> The total size of this struct is 5, but the most-aligned field is b with alignment 2, so we round up to 6 and give the struct an alignment of 2 bytes.
This allows them to be used in #[repr(C)] structs without warnings. Since rust-lang/rfcs#1649 and rust-lang#35603 they are already documented to have "the same in-memory representation as" their corresponding primitive types. This just makes that explicit.
The previous syntax was causing rustdoc to interpret them as links.
Clarifying how the alignment of the struct works

The docs were not specifying how to compute the alignment of the struct, so I had to spend some time trying to figure out how that works. Found the answer [on this page](http://camlorn.net/posts/April%202017/rust-struct-field-reordering.html):

> The total size of this struct is 5, but the most-aligned field is b with alignment 2, so we round up to 6 and give the struct an alignment of 2 bytes.
Add #[repr(transparent)] to Atomic* types

This allows them to be used in `#[repr(C)]` structs without warnings. Since rust-lang/rfcs#1649 and rust-lang#35603 they are already documented to have "the same in-memory representation as" their corresponding primitive types. This just makes that explicit.

This was briefly part of rust-lang#51395, but was controversial and therefore dropped. But it turns out that it's essentially already documented (which I had forgotten).
Copy libgcc as well after building musl

This is needed for rust-lang/libc#1034.

r? @alexcrichton
use proper footnote syntax for references

The previous syntax was causing rustdoc to interpret them as links.
…ebank

find and highlight the `&` or `'_` in `region_name`

Before:

```
   --> $DIR/dyn-trait-underscore.rs:18:5
    |
 LL | fn a<T>(items: &[T]) -> Box<dyn Iterator<Item=&T>> {
-   |         ----- lifetime `'1` appears in this argument
 LL |     Box::new(items.iter()) //~ ERROR cannot infer an appropriate lifetime
    |     ^^^^^^^^^^^^^^^^^^^^^^ cast requires that `'1` must outlive `'static`
```

After:

```
   --> $DIR/dyn-trait-underscore.rs:18:5
    |
 LL | fn a<T>(items: &[T]) -> Box<dyn Iterator<Item=&T>> {
+   |                - let's call the lifetime of this reference `'1`
 LL |     Box::new(items.iter()) //~ ERROR cannot infer an appropriate lifetime
    |     ^^^^^^^^^^^^^^^^^^^^^^ cast requires that `'1` must outlive `'static`
```

Not intended as the final end point necessarily in any sense. I intentionally left some to-do points to fill in later:

- Does not apply to upvars in closures yet (should be relatively easy)
- Does not handle the case where we can't find a precise match very well
- And of course we can still tweak wording

but shows the basic idea of how to make the `Ty` and `hir::Ty` to find a good spot to highlight.

r? @estebank
cc @davidtwco
Correct some codegen stats counter inconsistencies

I noticed some possible typos/inconsistencies in the codegen counters. For example, `fsub` was getting counted as an integer `sub`, whereas `fadd` was counted as an add. And `addincoming` was only being counted on the initial call.

https://github.com/rust-lang/rust/blob/dbd10f81758381339f98994b8d31814cf5e98707/src/librustc_codegen_llvm/builder.rs#L831-L841

Only remaining inconsistencies I can see are things like `fadd_fast` are counted as `fadd`. But the vector versions like `vector_reduce_fmax_fast` are counted as `vector.reduce.fmax_fast` not as their 'base' versions (`vector_reduce_fmax` is counted as `vector.reduce.fmax`).
…hton

Warn windows-gnu users that the bundled gcc can't compile

Add a `DO NOT USE THIS gcc.exe FOR COMPILATION.txt` file to `lib\rustlib\*-pc-windows-gnu\bin` folders in `windows-gnu` installations in order to warn against attempting to use the bundled `gcc.exe` as a C compiler. I'm pretty sure that location is usually found manually, so this should be easily noticeable.

This mistake has been made plenty of times and has lead to misunderstandings:
Rust: [Bundled gcc (windows x64) is unable to build any c file](rust-lang#24418)
gtk-rs:    [Compiling on windows](gtk-rs/gtk#625)
bzip2-rs: [Build failure at gcc level: blocksort.c not found](alexcrichton/bzip2-rs#30)

Alternatives: rename the bundled `gcc.exe` to e.g. `rustc-gcc.exe` or `gcc-linker.exe`. This might require a more comprehensive change or break crates already using it as a linker.

r? @alexcrichton
@Mark-Simulacrum
Copy link
Member Author

@bors r+ p=4

@bors
Copy link
Contributor

bors commented Jul 10, 2018

📌 Commit bb9f494 has been approved by Mark-Simulacrum

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jul 10, 2018
@bors
Copy link
Contributor

bors commented Jul 10, 2018

⌛ Testing commit bb9f494 with merge dd59301c62820031839dcc530c5f0e5851c30a11...

@bors
Copy link
Contributor

bors commented Jul 10, 2018

💔 Test failed - status-travis

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 10, 2018
@rust-highfive
Copy link
Collaborator

The job dist-x86_64-netbsd of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[00:31:59]    Compiling libc v0.0.0 (file:///checkout/src/rustc/libc_shim)
[00:31:59]    Compiling alloc v0.0.0 (file:///checkout/src/liballoc)
[00:31:59]    Compiling std_unicode v0.0.0 (file:///checkout/src/libstd_unicode)
[00:32:00] [RUSTC-TIMING] std_unicode test:false 0.086
[00:32:00] error[E0658]: The attribute `target_vendor` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
[00:32:00]    --> rustc/libc_shim/../../liblibc/src/unix/mod.rs:313:42
[00:32:00]     |
[00:32:00] 313 |         #[cfg_attr(feature = "stdbuild", target_vendor = "rumprun")]
[00:32:00]     |
[00:32:00]     |
[00:32:00]     = help: add #![feature(custom_attribute)] to the crate attributes to enable
[00:32:00] error: aborting due to previous error
[00:32:00] 
[00:32:00] For more information about this error, try `rustc --explain E0658`.
[00:32:00] [RUSTC-TIMING] libc test:false 0.328
[00:32:00] [RUSTC-TIMING] libc test:false 0.328
[00:32:00] error: Could not compile `libc`.
[00:32:00] Caused by:
[00:32:00] Caused by:
[00:32:00]   process didn't exit successfully: `/checkout/obj/build/bootstrap/debug/rustc --crate-name libc rustc/libc_shim/../../liblibc/src/lib.rs --color always --error-format json --crate-type lib --emit=dep-info,link -C opt-level=2 --cfg feature="default" --cfg feature="stdbuild" -C metadata=8dd8865d2057534d -C extra-filename=-8dd8865d2057534d --out-dir /checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-netbsd/release/deps --target x86_64-unknown-netbsd -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-netbsd/release/deps -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/release/deps --extern compiler_builtins=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-netbsd/release/deps/libcompiler_builtins-201253f95fc262be.rlib --extern core=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-netbsd/release/deps/libcore-d6429dbfd5d2229b.rlib -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-netbsd/release/build/compiler_builtins-4ac7974cfefb5381/out` (exit code: 101)
[00:32:05] [RUSTC-TIMING] alloc test:false 5.871
[00:32:05] error: build failed
[00:32:05] error: build failed
[00:32:05] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-netbsd" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "--message-format" "json"
[00:32:05] expected success, got: exit code: 101
[00:32:05] thread 'main' panicked at 'cargo must succeed', bootstrap/compile.rs:1117:9
[00:32:05] travis_fold:end:stage1-std

[00:32:05] travis_time:end:stage1-std:start=1531201660993127732,finish=1531201723813709146,duration=62820581414

---
travis_time:end:1f8277c6:start=1531201724553316708,finish=1531201724559925248,duration=6608540
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0a6d36b8
$ head -30 ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
head: cannot open ‘./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers’ for reading: No such file or directory
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:08676444
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

1 similar comment
@rust-highfive
Copy link
Collaborator

The job dist-x86_64-netbsd of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[00:31:59]    Compiling libc v0.0.0 (file:///checkout/src/rustc/libc_shim)
[00:31:59]    Compiling alloc v0.0.0 (file:///checkout/src/liballoc)
[00:31:59]    Compiling std_unicode v0.0.0 (file:///checkout/src/libstd_unicode)
[00:32:00] [RUSTC-TIMING] std_unicode test:false 0.086
[00:32:00] error[E0658]: The attribute `target_vendor` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
[00:32:00]    --> rustc/libc_shim/../../liblibc/src/unix/mod.rs:313:42
[00:32:00]     |
[00:32:00] 313 |         #[cfg_attr(feature = "stdbuild", target_vendor = "rumprun")]
[00:32:00]     |
[00:32:00]     |
[00:32:00]     = help: add #![feature(custom_attribute)] to the crate attributes to enable
[00:32:00] error: aborting due to previous error
[00:32:00] 
[00:32:00] For more information about this error, try `rustc --explain E0658`.
[00:32:00] [RUSTC-TIMING] libc test:false 0.328
[00:32:00] [RUSTC-TIMING] libc test:false 0.328
[00:32:00] error: Could not compile `libc`.
[00:32:00] Caused by:
[00:32:00] Caused by:
[00:32:00]   process didn't exit successfully: `/checkout/obj/build/bootstrap/debug/rustc --crate-name libc rustc/libc_shim/../../liblibc/src/lib.rs --color always --error-format json --crate-type lib --emit=dep-info,link -C opt-level=2 --cfg feature="default" --cfg feature="stdbuild" -C metadata=8dd8865d2057534d -C extra-filename=-8dd8865d2057534d --out-dir /checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-netbsd/release/deps --target x86_64-unknown-netbsd -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-netbsd/release/deps -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/release/deps --extern compiler_builtins=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-netbsd/release/deps/libcompiler_builtins-201253f95fc262be.rlib --extern core=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-netbsd/release/deps/libcore-d6429dbfd5d2229b.rlib -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-netbsd/release/build/compiler_builtins-4ac7974cfefb5381/out` (exit code: 101)
[00:32:05] [RUSTC-TIMING] alloc test:false 5.871
[00:32:05] error: build failed
[00:32:05] error: build failed
[00:32:05] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-netbsd" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "--message-format" "json"
[00:32:05] expected success, got: exit code: 101
[00:32:05] thread 'main' panicked at 'cargo must succeed', bootstrap/compile.rs:1117:9
[00:32:05] travis_fold:end:stage1-std

[00:32:05] travis_time:end:stage1-std:start=1531201660993127732,finish=1531201723813709146,duration=62820581414

---
travis_time:end:1f8277c6:start=1531201724553316708,finish=1531201724559925248,duration=6608540
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0a6d36b8
$ head -30 ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
head: cannot open ‘./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers’ for reading: No such file or directory
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:08676444
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@kennytm
Copy link
Member

kennytm commented Jul 10, 2018

(Legit, caused by #52157)

@kennytm kennytm closed this Jul 10, 2018
@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 S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.