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 6 pull requests #5526

Closed
wants to merge 16 commits into from
Closed

Conversation

flip1995
Copy link
Member

@flip1995 flip1995 commented Apr 25, 2020

Successful merges:

Failed merges:

r? @ghost

changelog: rollup

flip1995 and others added 16 commits April 22, 2020 20:32
Downgrade match_bool to pedantic

I don't quite buy the justification in https://rust-lang.github.io/rust-clippy/. The justification is:

> It makes the code less readable.

In the Rust codebases I've worked in, I have found people were comfortable using `match bool` (selectively) to make code more readable. For example, initializing struct fields is a place where the indentation of `match` can work better than the indentation of `if`:

```rust
let _ = Struct {
    v: {
        ...
    },
    w: match doing_w {
        true => ...,
        false => ...,
    },
    x: Nested {
        c: ...,
        b: ...,
        a: ...,
    },
    y: if doing_y {
        ...
    } else { // :(
        ...
    },
    z: ...,
};
```

Or sometimes people prefer something a bit less pithy than `if` when the meaning of the bool doesn't read off clearly from the condition:

```rust
if set.insert(...) {
    ... // ???
} else {
    ...
}

match set.insert(...) {
    // set.insert returns false if already present
    false => ...,
    true => ...,
}
```

Or `match` can be a better fit when the bool is playing the role more of a value than a branch condition:

```rust
impl ErrorCodes {
    pub fn from(b: bool) -> Self {
        match b {
            true => ErrorCodes::Yes,
            false => ErrorCodes::No,
        }
    }
}
```

And then there's plain old it's-1-line-shorter, which means we get 25% more content on a screen when stacking a sequence of conditions:

```rust
let old_noun = match old_binding.is_import() {
    true => "import",
    false => "definition",
};
let new_participle = match new_binding.is_import() {
    true => "imported",
    false => "defined",
};
```

Bottom line is I think this lint fits the bill better as a pedantic lint; I don't think linting on this by default is justified.

changelog: Remove match_bool from default set of enabled lints
…hiaskrgr

Avoid running cargo+internal lints when not enabled

r? @matthiaskrgr

changelog: none
Add a note to the beta sections of release.md

changelog: none
…hearth

Deploy time travel

Since not only commits to the master branch, but also tags and the beta branch are deployed, we have to be cautious which version of the deploy script is used. GHA always runs the workflow that is commited on the `ref`, that gets tested. For tagged commits. this is 6 weeks outdated workflows/scripts. To prevent this, this workflow first checks out the deploy.sh script, the website templates and all python scripts generating files for the website.

changelog: none
Register redundant_field_names and non_expressive_names as early passes

Fixes rust-lang#5356
Fixes rust-lang#5521

We should move all pre_expansion_passes to early_passes, since they were soft deprecated in the rust compiler IIUC.

changelog: none
…, r=flip1995

Add lifetime test case for `new_ret_no_self`

cc rust-lang#734 (comment)

changelog: none
@flip1995 flip1995 closed this Apr 25, 2020
@flip1995 flip1995 deleted the rollup-jfdxsyw branch April 25, 2020 19:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants