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.
I added a `disallowed_method` lint that works similar to `blacklisted_name`, e.g allows config-defined disallowed method calls.
This lint allows advanced users to patch in undesired method calls for specific projects. It basically uses the DefId of method calls and matches it to parsed strings. Is there an alternative approach that could use more easily digestible configuration strings?
All tests pass as expected except for a linting error on `ui/redundant_pattern_matching_option`, which I am not sure how to resolve since I don't think I changed anything affecting it.
changelog: Add disallowed_method lint to warn on user-defined method calls
Auto merge of #6084 - ebroto:ui_tests_cleanup, r=flip1995
UI tests cleanup
`@matthiaskrgr` noticed some `run-pass` annotations in some crash tests that were added in #3922. At that moment they seemed to be necessary to make the tests fail in case of an ICE, but they do not seem to be needed anymore. To test this I forced an ICE in a file with and without annotations, with and without stderr files, and the ICE makes the test fail every time.
In addition, I've applied a suggestion from `@ehuss` and `@jyn514` to add `emit=metadata` to the rustc flags for the UI tests. In my machine this improved the run time from ~17 to ~12 seconds.
Jonas Schievink [Fri, 25 Sep 2020 00:29:31 +0000 (02:29 +0200)]
Rollup merge of #76724 - ecstatic-morse:dataflow-pass-names, r=lcnr
Allow a unique name to be assigned to dataflow graphviz output
Previously, if the same analysis were invoked multiple times in a single compilation session, the graphviz output for later runs would overwrite that of previous runs. Allow callers to add a unique identifier to each run so this can be avoided.