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 14 pull requests #73746

Merged
merged 50 commits into from
Jun 26, 2020
Merged

Rollup of 14 pull requests #73746

merged 50 commits into from
Jun 26, 2020

Conversation

Manishearth
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

eduardosm and others added 30 commits May 26, 2020 17:46
This is done by adding a global atomic variable (non-TLS) that counts how many threads are panicking. In order to check if the current thread is panicking, this variable is read and, if it is zero, no thread (including the one where `panicking` is being called) is panicking and `panicking` can return `false` immediately without needing to access TLS. If the global counter is not zero, the local counter is accessed from TLS to check if the current thread is panicking.
* Suggest potentially missing binop trait bound (fix rust-lang#73416)
* Use structured suggestion for dereference in binop
Apply suggestions from code review

Co-authored-by: Josh Triplett <josh@joshtriplett.org>
* deduplicate logic
* fix typos
* remove unnecessary state
Don't be so reliant on particular line ordering (though FileCheck makes
this hard in general, IMO). Also disable for MSVC.
..which doesn't use variant types.
This keeps FileCheck from tripping over unimportant differences in
codegen.
Verify that the binop trait *is* implemented for the types *if* all the
involved type parameters are replaced with fresh inferred types. When
this is the case, it means that the type parameter was indeed missing a
trait bound. If this is not the case, provide a generic `note` refering
to the type that doesn't implement the expected trait.
When encountering an used moved value where the previous move happened
in a `match` or `if let` pattern, suggest using `ref`. Fix rust-lang#63988.

When encountering a `&mut` value that is used in multiple iterations of
a loop, suggest reborrowing it with `&mut *`. Fix rust-lang#62112.
GuillaumeGomez and others added 16 commits June 25, 2020 13:28
Add a fast path for `std::thread::panicking`.

This is done by adding a global atomic variable (non-TLS) that counts how many threads are panicking. In order to check if the current thread is panicking, this variable is read and, if it is zero, no thread (including the one where `panicking` is being called) is panicking and `panicking` can return `false` immediately without needing to access TLS. If the global counter is not zero, the local counter is accessed from TLS to check if the current thread is panicking.
…trochenkov

Self contained linking option

With objects moved to self-contained directory by rust-lang#72999 we can now add option to control whether to use self-contained on native linkage mode.
…=Manishearth

Implement mixed script confusable lint.

This implements the mixed script confusable lint defined in RFC 2457.
This is blocked on rust-lang#72069 and unicode-rs/unicode-security#13, and will need a Cargo.toml version bump after those are resolved.

The lint message warning is sub-optimal for now. We'll need a mechanism to properly output  `AugmentScriptSet` to screen, this is to be added in `unicode-security` crate.

r? @Manishearth
Add unstable `core::mem::variant_count` intrinsic

Adds a new `const fn` intrinsic which can be used to determine the number of variants in an `enum`.

I've shown this to a couple of people and they invariably ask 'why on earth?', but there's actually a very neat use case:

At the moment, if you want to create an opaque array type that's indexed by an `enum` with one element for each variant, you either have to hard-code the number of variants, add a `LENGTH` variant or use a `Vec`, none of which are suitable in general (number of variants could change; pattern matching `LENGTH` becomes frustrating; might not have `alloc`). By including this intrinsic, it becomes possible to write the following:

```rust
#[derive(Copy, Clone)]
enum OpaqueIndex {
    A = 0,
    B,
    C,
}

struct OpaqueVec<T>(Box<[T; std::mem::num_variants::<OpaqueIndex>()]>);

impl<T> std::ops::Index<OpaqueIndex> for OpaqueVec<T> {
    type Output = T;

    fn index(&self, idx: OpaqueIndex) -> &Self::Output {
        &self.0[idx as usize]
    }
}
```

(We even have a use cases for this in `rustc` and I plan to use it to re-implement the lang-items table.)
Emit line info for generator variants

Debuggers should be able to read a generator / async fn state machine and show the line it's suspended at. Eventually, this could grow into an "async stack trace" feature of sorts. While no debugger support this for Rust today, this PR adds the debuginfo necessary for that support to exist.

[This gist](https://gist.github.com/tmandry/6d7004fa008684f76809208847459f9b) shows the resulting debuginfo for a simple example. Here's a snippet:

```
0x00000986:           DW_TAG_variant
                        DW_AT_discr_value       (0x03)

0x00000988:             DW_TAG_member
                          DW_AT_name    ("3")
                          DW_AT_type    (0x000009bc "Suspend0")
                          DW_AT_decl_file       ("/home/tmandry/code/playground/generator-simple.rs")
                          DW_AT_decl_line       (6)
                          DW_AT_alignment       (8)
                          DW_AT_data_member_location    (0x00)
```

The file and line have been added here. The line currently points to the beginning of the statement containing the yield (or await), because that's what the MIR source info points to for the yield terminator. (We may want to point to the yield or await line specifically, but that can be done independently of this change.)

Debuggers don't know how to use this kind of info yet. However, we're hoping to experiment with adding such support to Fuchsia's debugger. It would be exciting if someone were interested in adding similar to support to gdb/lldb.

r? @oli-obk
cc @eddyb @jonas-schievink

Part of rust-lang#73524.
…tthewjasper

Provide suggestions for some moved value errors

When encountering an used moved value where the previous move happened
in a `match` or `if let` pattern, suggest using `ref`. Fix rust-lang#63988.

When encountering a `&mut` value that is used in multiple iterations of
a loop, suggest reborrowing it with `&mut *`. Fix rust-lang#62112.
make commented examples use valid syntax, and be more consistent
…abnik

Document the mod keyword

Partial fix for rust-lang#34601 .

Documentation for the `mod` keyword.
…abnik

Document the mut keyword

Partial fix for rust-lang#34601.

Documentation for the `mut` keyword. I think it's okay for it to be quite short, this is not the book not the reference, but if you find something is missing, do not hesitate to tell me.
…triplett

Document the return keyword

Partial fix of rust-lang#34601.

This documents the `return` keyword with two short example to explain it is not needed for the last expression in a function and a long example to show its use when interrupting a function execution early.

I did not put a link to the reference since the only link I found was https://doc.rust-lang.org/stable/reference/expressions/return-expr.html#return-expressions.

@rustbot modify labels: T-doc,C-enhancement
Fix ptr doc warnings.

rust-lang#73398 added some stray backtick lines which cause warnings when the docs are built.
… r=davidtwco

Tweak binop errors

* Suggest potentially missing binop trait bound (fix rust-lang#73416)
* Use structured suggestion for dereference in binop
@Manishearth
Copy link
Member Author

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

@bors
Copy link
Contributor

bors commented Jun 26, 2020

📌 Commit 8c5d794 has been approved by Manishearth

@rustbot rustbot added the rollup A PR which is a rollup label Jun 26, 2020
@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 Jun 26, 2020
@bors
Copy link
Contributor

bors commented Jun 26, 2020

⌛ Testing commit 8c5d794 with merge e093b65...

@bors
Copy link
Contributor

bors commented Jun 26, 2020

☀️ Test successful - checks-azure
Approved by: Manishearth
Pushing e093b65 to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.