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
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?
Auto merge of #6093 - ebroto:6089_renamed_lifetimes, r=Manishearth
needless arbitrary self: handle macros
This fixes two cases related to macros:
* If the parameter comes from expansion, do not lint as the user has no possibility of changing it. This is not directly related to the fixed issue, but we should probably do that.
* If *only* the lifetime name comes from expansion, lint, but allow the user decide the name of the lifetime. In the related issue, the lifetime was unnamed and then renamed by `async_trait`, so just removing the name in the suggestion would work, but in the general case a macro can rename a lifetime that was named differently, and we can't reliably know that name anymore.
As a hint for the reviewer, the expanded code for the test can be checked with this command (from the root dir of the repo):
```sh
rustc -L target/debug/test_build_base/needless_arbitrary_self_type_unfixable.stage-id.aux -Zunpretty=expanded tests/ui/needless_arbitrary_self_type_unfixable.rs
```
Rollup merge of #76474 - bjorn3:driver_selected_codegen, r=oli-obk
Add option to pass a custom codegen backend from a driver
This allows the driver to pass information to the codegen backend. For example the headcrab debugger may in the future want to use cg_clif to JIT code to be injected in the debuggee. This would PR make it possible to tell cg_clif which symbol can be found at which address and to tell it to inject the JITed code into the right process.
This PR may also help with https://github.com/rust-lang/miri/pull/1540 by allowing miri to provide a codegen backend that only emits metadata and doesn't perform any codegen.
projects / rust.git / log