bors [Mon, 12 Oct 2020 13:49:19 +0000 (13:49 +0000)]
Auto merge of #6158 - giraffate:improve_updating_references, r=phansch
Remove the generated files by `update-references.sh` if they are empty
An empty file may be generated by `update-references.sh` and committed as is when creating a patch like https://github.com/rust-lang/rust-clippy/pull/6101#issuecomment-702076508 and https://github.com/rust-lang/rust-clippy/pull/6079#pullrequestreview-496502721. So, I think it would be helpful to add documentation, and automatically remove the generated file if it's empty.
bors [Sat, 10 Oct 2020 13:29:05 +0000 (13:29 +0000)]
Auto merge of #6154 - flip1995:ice_fixes, r=ebroto
Fix two ICEs caused by ty.is_{sized,freeze}
Fixes #6153
Properly fixes #6139
The test case in #6153 is kind of weird. Even removing one of the arguments of the `foo` function prevented the ICE. I think this test case is actually minimal.
bors [Sat, 10 Oct 2020 06:32:32 +0000 (06:32 +0000)]
Auto merge of #5727 - rail-rain:manual_memcpy_with_counter, r=flip1995
Expands `manual_memcpy` to lint ones with loop counters
Closes #1670
This PR expands `manual_memcpy` to lint ones with loop counters as described in https://github.com/rust-lang/rust-clippy/issues/1670#issuecomment-293280204
Although the current code is working, I have a couple of questions and concerns.
~~Firstly, I manually implemented `Clone` for `Sugg` because `AssocOp` lacks `Clone`. As `AssocOp` only holds an enum, which is `Copy`, as a value, it seems `AssocOp` can be `Clone`; but, I was not sure where to ask it. Should I make a PR to `rustc`?~~ The [PR]( https://github.com/rust-lang/rust/pull/73629) was made.
Secondly, manual copying with loop counters are likely to trigger `needless_range_loop` and `explicit_counter_loop` along with `manual_memcpy`; in fact, I explicitly allowed them in the tests. Is there any way to disable these two lints when a code triggers `manual_memcpy`?
And, another thing I'd like to note is that `Sugg` adds unnecessary parentheses when expressions with parentheses passed to its `hir` function, as seen here:
```
error: it looks like you're manually copying between slices
--> $DIR/manual_memcpy.rs:145:14
|
LL | for i in 3..(3 + src.len()) {
| ^^^^^^^^^^^^^^^^^^ help: try replacing the loop by: `dst[3..((3 + src.len()))].clone_from_slice(&src[..((3 + src.len()) - 3)])
```
However, using the `hir` function is needed to prevent the suggestion causing errors when users use bitwise operations; and also this have already existed, for example: `verbose_bit_mask`. Thus, I think this is fine.
changelog: Expands `manual_memcpy` to lint ones with loop counters
bors [Fri, 9 Oct 2020 23:14:58 +0000 (23:14 +0000)]
Auto merge of #6151 - bofh69:master, r=ebroto
Preserve raw strs for: format!(s) to s.to_string() lint
fixes #6142
clippy::useless_format will keep the source's string (after converting {{ and }} to { and }) when suggesting a change from format!() to .to_string() usage. Ie:
| let s = format!(r#""hello {{}}""#);
| ^^^^^^^^^^^^^^^^^^^^^ help: consider using `.to_string()`: `r#""hello {}""#.to_string()`
changelog: [`useless_format`]: preserve raw string literals when no arguments to `format!()` are provided.
bors [Fri, 9 Oct 2020 16:46:09 +0000 (16:46 +0000)]
Auto merge of #6130 - Ambroisie:lint-ptr-eq, r=Manishearth
New lint: Recommend using `ptr::eq` when possible
This is based almost entirely on the code available in the previous PR #4596. I merely updated the code to make it compile.
Fixes #3661.
- [ ] I'm not sure about the lint name, but it was the one used in the original PR.
- [X] Added passing UI tests (including committed `.stderr` file)
- [X] `cargo test` passes locally
- [X] Executed `cargo dev update_lints`
- [X] Added lint documentation
- [X] Run `cargo dev fmt`
bors [Fri, 9 Oct 2020 13:23:01 +0000 (13:23 +0000)]
Auto merge of #6149 - flip1995:update_actions, r=ebroto
Remove deprecated set-env from GHA
This updates all of our action dependencies and removes every usage of `set-env`. `set-env` and `add-path` has been deprecated: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/
bors [Fri, 9 Oct 2020 13:02:25 +0000 (13:02 +0000)]
Auto merge of #6148 - flip1995:release_doc, r=ebroto
Update release documentation
When updating the beta branch, we want to reset, instead of rebase. Otherwise we might produce again new commits on the beta branch, that aren't on the master branch.
bors [Fri, 9 Oct 2020 12:41:08 +0000 (12:41 +0000)]
Auto merge of #6131 - Ambroisie:fix-doc-tools, r=flip1995
Rename tables to typecheck_result()
While working on #6130, I noticed that part of the documentation was updated to use `LateContext::typeck_results`, but the paragraph still referred to the old `tables` field of `LateContext`.
I've not added the PRs fixing `same_item_push` because those were backported, namely:
* [#5908](https://github.com/rust-lang/rust-clippy/pull/5908)
* [#5997](https://github.com/rust-lang/rust-clippy/pull/5997)
* [#6016](https://github.com/rust-lang/rust-clippy/pull/6016)
The following PR was reverted, so I've ignored it too:
* [#5984](https://github.com/rust-lang/rust-clippy/pull/5984)
~~Also, I took the liberty of adding a "Thanks" section, naming all the contributors to this release. I think they deserve visibility in the changelog. Please tell me if we want to add this or maybe it's redundant given we link to the PRs?~~
bors [Thu, 8 Oct 2020 22:50:29 +0000 (22:50 +0000)]
Auto merge of #6133 - JPTIZ:no-box-for-c-ffi, r=ebroto
clippy_lints: Do not warn against Box parameter in C FFI
changelog: [`boxed_local`]: don't lint in `extern fn` arguments
Fixes #5542.
When using C FFI, to handle pointers in parameters it is needed to
declare them as `Box` in its Rust-side signature. However, the current
linter warns against the usage of Box stating that "local variable
doesn't need to be boxed here".
This commit fixes it by ignoring functions whose Abi is C.
bors [Thu, 8 Oct 2020 21:33:32 +0000 (21:33 +0000)]
Auto merge of #6117 - dtolnay:string_lit_as_bytes, r=ebroto
Downgrade string_lit_as_bytes to nursery
Between #1402 (regarding `to_owned`) and #4494 (regarding `impl Read`), as well as other confusion I've seen hit in my work codebase involving string_lit_as_bytes (`"...".as_bytes().into()`), I don't think this lint is at a quality to be enabled by default.
I would consider re-enabling this lint after it is updated to understand when the surrounding type information is sufficient to unsize `b"..."` to &\[u8\] without causing a type error.
As currently implemented, this lint is pushing people to write `&b"_"[..]` which is not an improvement over `"_".as_bytes()` as far as I am concerned.
---
changelog: Remove string_lit_as_bytes from default set of enabled lints
Replace run_compiler with RunCompiler builder pattern.
RunCompiler::new takes non-optional params, and optional
params can be set using set_*field_name* method.
finally `run` will forward all fields to `run_compiler`.
bors [Thu, 8 Oct 2020 16:56:14 +0000 (16:56 +0000)]
Auto merge of #6138 - giraffate:note_that_we_follow_rustc_no_merge_policy, r=Manishearth
Add note that we follow a rustc no merge-commit policy
I think it would be better to add a note that we follow a rustc no merge-commit policy. For example, it was mentioned at https://github.com/rust-lang/rust-clippy/pull/5694#issuecomment-641871096.
clippy_lints: Do not warn against Box parameter in C FFI
Fixes #5542.
When using C FFI, to handle pointers in parameters it is needed to
declare them as `Box` in its Rust-side signature. However, the current
linter warns against the usage of Box stating that "local variable
doesn't need to be boxed here".
This commit fixes it by ignoring functions whose Abi is Cdecl.
bors [Wed, 7 Oct 2020 23:10:34 +0000 (23:10 +0000)]
Auto merge of #6128 - dtolnay:rc_buffer, r=yaahc
Downgrade rc_buffer to restriction
I think Arc\<Vec\<T\>\> and Arc\<String\> and similar are a totally reasonable data structure, as observed by others in the comments on [#6044](https://github.com/rust-lang/rust-clippy/pull/6044#event-3799579830) as well. Doing `Arc::make_mut(&mut self.vec).push(...)` or `Arc::make_mut(&mut self.string).push_str("...")` is a terrific and well performing copy-on-write pattern. Linting this with an enabled-by-default <kbd>performance</kbd> lint strikes me as an unacceptable false positive balance.
As of #6090 the documentation of this lint now contains:
> **Known problems:** This pattern can be desirable ...
which should indicate that we shouldn't be linting against correct, reasonable, well-performing patterns with an enabled-by-default lint.
Mentioning #6044, #6090.
r? `@yaahc,` who reviewed the lint.
---
changelog: Remove rc_buffer from default set of enabled lints
bors [Wed, 7 Oct 2020 04:58:13 +0000 (04:58 +0000)]
Auto merge of #6120 - phansch:replace-lazy-static, r=Manishearth
Replace some lazy_static usage with once_cell feature
This replaces some `lazy_static` usage with [`SyncLazy`](https://doc.rust-lang.org/nightly/std/lazy/struct.SyncLazy.html) of the unstable `once_cell` feature.
bors [Tue, 6 Oct 2020 22:33:57 +0000 (22:33 +0000)]
Auto merge of #6127 - ebroto:reinstate_forbid_restriction, r=flip1995
Reinstate test for forbid(clippy::restriction)
In [this commit](https://github.com/rust-lang/rust-clippy/pull/6126/commits/5747c15961da9d2d0b0dd775174d39f3b5961597) coming from rust-lang/rust (#6126) the test for `#![forbid(clippy::restriction)]` was removed because some restriction lints were being allowed after the forbid.
This change reinstates the test for `forbid` by using a separate file.
Yuki Okushi [Tue, 6 Oct 2020 07:26:11 +0000 (16:26 +0900)]
Rollup merge of #77560 - rschoon:fix-litkind-rc-bytebuf, r=lcnr
Fix LitKind's byte buffer to use refcounted slice
While working on adding a new lint for clippy (see https://github.com/rust-lang/rust-clippy/pull/6044) for avoiding shared ownership of "mutable buffer" types (such as using `Rc<Vec<T>>` instead of `Rc<[T]>`), I noticed a type exported from rustc_ast and used by clippy gets caught by the lint. This PR fixes the exported type.
This PR includes the actual change to clippy too, but I will open a PR directly against clippy for that part (although it will currently fail to build there).
bors [Tue, 6 Oct 2020 06:59:33 +0000 (06:59 +0000)]
Auto merge of #6078 - ebroto:unnecessary_sort_by_take_2, r=phansch
unnecessary sort by: avoid dereferencing the suggested closure parameter
This change tries to simplify the solution for problematic cases but is less restrictive than #6006.
* We can't dereference shared references to non-Copy types, so the new suggestion does not do that. Note that this implies that the suggested closure parameter will be a reference.
* We can't take a reference to the closure parameter in the returned key, so we don't lint in those cases. This can happen either because the key borrows from the parameter (e.g. `|a| a.borrows()`), or because we suggest `|a| Reverse(a)`. If we did we would hit this error:
```
error: lifetime may not live long enough
--> /home/ebroto/src/ebroto-clippy/tests/ui/unnecessary_sort_by.fixed:19:25
|
19 | vec.sort_by_key(|b| Reverse(b));
| -- ^^^^^^^^^^ returning this value requires that `'1` must outlive `'2`
| ||
| |return type of closure is Reverse<&'2 isize>
| has type `&'1 isize`
error: aborting due to previous error
```
Note that Clippy does not currently have the (MIR-based) machinery necessary to check that what is borrowed is actually the closure parameter.
changelog: [`unnecessary_sort_by`]: avoid dereferencing the suggested closure parameter
bors [Mon, 5 Oct 2020 21:17:37 +0000 (21:17 +0000)]
Auto merge of #6114 - FliegendeWurst:no-mistyped-fraction, r=Manishearth
Do not lint float fractions in `mistyped_literal_suffixes`
As suggested in https://github.com/rust-lang/rust-clippy/issues/4706#issuecomment-544797928, the fractional part is now ignored (the integer part is checked instead).
Fixes: #4706
changelog: `mistyped_literal_suffixes` no longer warns on the fractional part of a float (e.g. 713.23_64)
bors [Fri, 2 Oct 2020 22:22:37 +0000 (22:22 +0000)]
Auto merge of #6105 - bugadani:sus-char, r=ebroto
Lint for invisible Unicode characters other than ZWSP
This PR extends the existing `zero_width_space` lint to look for other invisible characters as well (in this case, `\\u{ad}` soft hyphen.
I feel like this lint is the logical place to add the check, but I also realize the lint name is not particularly flexible, but I also understand that it shouldn't be renamed for compatibility reasons.
Open questions:
- What other characters should trigger the lint?
- What should be done with the lint name?
- How to indicate the change in functionality?
Motivation behind this PR: https://github.com/rust-lang/rust/issues/77417 - I managed to shoot myself in the foot by an invisible character pasted into my test case.
changelog: rename [`zero_width_space`] to [`invisible_characters`] and add SHY and WJ to the list.
bors [Fri, 2 Oct 2020 21:21:49 +0000 (21:21 +0000)]
Auto merge of #6098 - longlb:interior_mut_const, r=ebroto
Downgrade interior_mutable_const lints to warn by default
This change updates the two lints in the file non_copy_const.rs to be warn by default rather than deny by default. It also updates the known problems for declare_interior_mutable_const to mention some issues that are affected by the lints.
This is a repeat pull request since I botched the first one (#6012). Apart from my messing up the commits of that one, I also had a problem where the stderr of the tests didn't change despite me changing both lints to warn by default. Is this normal behaviour for some lints or do I need to adjust the tests to accommodate the change?
projects / rust.git / log