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

Closed
wants to merge 29 commits into from
Closed

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

m-ou-se and others added 29 commits October 8, 2020 23:51
Co-authored-by: Peter Todd <pete@petertodd.org>
Co-authored-by: David Tolnay <dtolnay@gmail.com>
This resolves issues where the cross-build of LLVM fails because it tries to
link to the host's system libraries instead of the target's system libraries.
For example, if you had this code:

    fn foo(x: i32, y: f32) -> f32 {
        x * y
    }

You would get this error:

    error[E0277]: cannot multiply `f32` to `i32`
     --> src/lib.rs:2:7
      |
    2 |     x * y
      |       ^ no implementation for `i32 * f32`
      |
      = help: the trait `Mul<f32>` is not implemented for `i32`

However, that's not usually how people describe multiplication. People
usually describe multiplication like how the division error words it:

    error[E0277]: cannot divide `i32` by `f32`
     --> src/lib.rs:2:7
      |
    2 |     x / y
      |       ^ no implementation for `i32 / f32`
      |
      = help: the trait `Div<f32>` is not implemented for `i32`

So that's what this change does. It changes this:

    error[E0277]: cannot multiply `f32` to `i32`
     --> src/lib.rs:2:7
      |
    2 |     x * y
      |       ^ no implementation for `i32 * f32`
      |
      = help: the trait `Mul<f32>` is not implemented for `i32`

To this:

    error[E0277]: cannot multiply `i32` by `f32`
     --> src/lib.rs:2:7
      |
    2 |     x * y
      |       ^ no implementation for `i32 * f32`
      |
      = help: the trait `Mul<f32>` is not implemented for `i32`
Previously the title would be

    lib.rs.html -- source

if `lib.rs` was the actual source filename. Now the title is

    lib.rs – source

(note the en dash).
Even in the PR that introduced this comment, it does not seem like these locals are actually ignored -- just their `source_info` is adjusted:
https://github.com/rust-lang/rust/pull/44700/files#diff-ae2f3c7e2f9744f7ef43e96072b10e98d4e3fe74a3a399a3ad8a810fbe56c520R139
…, r=dtolnay

Add Pin::static_ref, static_mut.

This adds `Pin::static_ref` and `Pin::static_mut`, which convert a static reference to a pinned static reference.

Static references are effectively already pinned, as what they refer to has to live forever and can never be moved.

---

Context: I want to update the `sys` and `sys_common` mutexes/rwlocks/condvars to use `Pin<&self>` in their functions, instead of only warning in the unsafety comments that they may not be moved. That should make them a little bit less dangerous to use. Putting such an object in a `static` (e.g. through `sys_common::StaticMutex`) fulfills the requirements about never moving it, but right now there's no safe way to get a `Pin<&T>` to a `static`. This solves that.
…hewjasper

Mark inout asm! operands as used in liveness pass

Variables used in `inout` operands in inline assembly (that is, they're used as both input and output to some arbitrary assembly instruction) are being marked as read and written, but are not marked as being used in the RWU table during the liveness pass. This can result in such expressions triggering an unused variable lint warning. This is incorrect behavior- reads without uses are currently only used for compound assignments. We conservatively assume that an `inout` operand is being read and used in the context of the assembly instruction.

Closes rust-lang#77915
…-Simulacrum

Haiku: explicitly set CMAKE_SYSTEM_NAME when cross-compiling

This resolves issues where the cross-build of LLVM fails because it tries to
link to the host's system libraries instead of the target's system libraries.
BTreeMap: split off most code of remove and split_off

Putting map.rs on a diet, in addition to rust-lang#77851.
r? @dtolnay
…or, r=estebank

Improve wording of "cannot multiply" type error

For example, if you had this code:

    fn foo(x: i32, y: f32) -> f32 {
        x * y
    }

You would get this error:

    error[E0277]: cannot multiply `f32` to `i32`
     --> src/lib.rs:2:7
      |
    2 |     x * y
      |       ^ no implementation for `i32 * f32`
      |
      = help: the trait `Mul<f32>` is not implemented for `i32`

However, that's not usually how people describe multiplication. People
usually describe multiplication like how the division error words it:

    error[E0277]: cannot divide `i32` by `f32`
     --> src/lib.rs:2:7
      |
    2 |     x / y
      |       ^ no implementation for `i32 / f32`
      |
      = help: the trait `Div<f32>` is not implemented for `i32`

So that's what this change does. It changes this:

    error[E0277]: cannot multiply `f32` to `i32`
     --> src/lib.rs:2:7
      |
    2 |     x * y
      |       ^ no implementation for `i32 * f32`
      |
      = help: the trait `Mul<f32>` is not implemented for `i32`

To this:

    error[E0277]: cannot multiply `i32` by `f32`
     --> src/lib.rs:2:7
      |
    2 |     x * y
      |       ^ no implementation for `i32 * f32`
      |
      = help: the trait `Mul<f32>` is not implemented for `i32`
…=jyn514

rustdoc: Show the correct source filename in page titles, without `.html`

Previously the title would be

    lib.rs.html -- source

if `lib.rs` was the actual source filename. Now the title is

    lib.rs - source
fix static_ptr_ty for foreign statics

Cc rust-lang#74840

This does not fix that issue but fixes a problem in `static_ptr_ty` that we noticed while discussing that issue. I also added and updated a few comments. The one about `internal` locals being ignored does not seem to have been true [even in the commit that introduced it](https://github.com/rust-lang/rust/pull/44700/files#diff-ae2f3c7e2f9744f7ef43e96072b10e98d4e3fe74a3a399a3ad8a810fbe56c520R139).

r? @oli-obk
@JohnTitor
Copy link
Member Author

@bors r+ rollup=never p=5
@rustbot modify labels: rollup

@rustbot rustbot added the rollup A PR which is a rollup label Oct 21, 2020
@bors
Copy link
Contributor

bors commented Oct 21, 2020

📌 Commit 34c2223 has been approved by JohnTitor

@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 Oct 21, 2020
@bors
Copy link
Contributor

bors commented Oct 21, 2020

⌛ Testing commit 34c2223 with merge 2955f58d804aec211f944b3cb19ffad65334533f...

@bors
Copy link
Contributor

bors commented Oct 21, 2020

💔 Test failed - checks-actions

@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 Oct 21, 2020
@JohnTitor
Copy link
Member Author

#77976 is the cause.

@JohnTitor JohnTitor closed this Oct 21, 2020
@JohnTitor JohnTitor deleted the rollup-i4bhfly branch October 21, 2020 04:54
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.

10 participants