profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/mcarton/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Martin Carton mcarton Eindhoven, Netherland

arthaud/moc 6

Micro Objective-C compiler

mcarton/CRAPS-Kernel 4

A simple operating system, processor and compiler for Nexys2

arthaud/egg 2

Extended Generator Generator

arthaud/GRO 1

Dépôt pour les cours et TP de « Graphes et Recherche Opérationnelle » en seconde année à l'ENSEEIHT.

arthaud/raytracer 1

A simple raytracer made in Java.

mcarton/interwiki 1

A script to change URL in your browser

mcarton/apply_attr 0

A syntax extension providing higher-order attributes to Rust.

pull request commentrust-lang/rust-clippy

Don't assume lang items will exist.

This still makes a technically correct change, even if it doesn't actually fix anything.

Jarcho

comment created time in 15 minutes

pull request commentrust-lang/rfcs

RFC: An edition-compatible system for "removing" deprecated items from the standard library

maybe deprecated things could be put in their own separate section at the end of the docs, minimized by default, such that you don't have to be distracted by them, but the docs are still there if you really need them.

bstrie

comment created time in 23 minutes

issue openedrust-lang/rust-clippy

Feature request: custom library-specific lints

Over at Bevy we've been discussing building a linter for Bevy code bases, to catch common errors and style issues.

We'd love to be able to integrate with Clippy in some way, but obviously, almost all of these will be completely useless to Rustaceans who aren't using Bevy. Furthermore, we'd want to maintain our own lints, without bogging down the rust-clippy team directly.

What would be the best way to go about this?

created time in 24 minutes

pull request commentrust-lang/rust-clippy

Use diagnostic or language items instead of paths

Turns out this did fix expl_impl_clone_on_copy, which is causing all those warnings. https://github.com/rust-lang/rust-clippy/pull/6868#issuecomment-793256098

Jarcho

comment created time in 36 minutes

PR opened rust-lang/rfcs

Fix typo in RFC 560
+1 -1

0 comment

1 changed file

pr created time in an hour

pull request commentrust-lang/rust-clippy

Don't assume lang items will exist.

Turns out match_path isn't really suitable for most uses . match_path reverses both paths, then truncates the longer one before comparing. This works in the common case where only the trait name is used. In libc, the Clone trait is exported from the root module, and all uses of it are through ::Clone, which will never match the path core::clone::Clone.

Should probably remove all uses of match_path, they probably have the same issue.

Jarcho

comment created time in an hour

issue closedrust-lang/rust-clippy

Suggest replacing .map(f).flatten() with .and_then(f) on Options

What it does

What does this lint do? Checks for usage of _.map(_).flatten(),

This is like https://rust-lang.github.io/rust-clippy/master/index.html#map_flatten but for Options instead of Iterators

Categories (optional)

  • Kind: clippy::style/complexity

Easier to follow what's happening, shorter

Drawbacks

None.

Example

Inspired by @steffahn's suggestion in https://github.com/Nadrieril/dhall-rust/pull/213#issuecomment-792793983

closed time in 2 hours

scottmcm

issue commentrust-lang/rust-clippy

Suggest replacing .map(f).flatten() with .and_then(f) on Options

Ah, so I did! The description in the docs made me think it's only for Iterator::map.

scottmcm

comment created time in 2 hours

pull request commentrust-lang/rust-clippy

Implement new lint: if_then_some_else_none

:v: @giraffate can now approve this pull request <!-- homu: {"type":"Delegated","delegator":"Manishearth","delegate":"giraffate"} -->

magurotuna

comment created time in 3 hours

pull request commentrust-lang/rust-clippy

Implement new lint: if_then_some_else_none

@bors delegate=giraffate

magurotuna

comment created time in 3 hours

pull request commentrust-lang/rust-clippy

Implement new lint: if_then_some_else_none

Yes, I'll do!

magurotuna

comment created time in 3 hours

issue commentrust-lang/rust-clippy

Incorrect suggestion by `useless_let_if_seq` lint

Ran into a case today where the suggestion generated is also incorrect, source:

        let mut changed = false;
        if self.pos != p {
            self.pos = p;
            changed = true;
        }
        if self.rot != r {
            self.rot = r;
            changed = true;
        }

        if changed {
            // do the thing
        }

suggestion:

help: it is more idiomatic to write
    |
106 |         let <mut> changed = if self.rot != r { ..; true } else { if self.pos != p {
107 |             self.pos = p;
108 |             true
109 |         } else {
110 |             false
111 |         } };

The suggestion incorrectly changes the flow control to only update self.pos when self.rot is not changed, compared to the original code

df5602

comment created time in 4 hours

pull request commentrust-lang/rfcs

RFC: An edition-compatible system for "removing" deprecated items from the standard library

Responding to comments:


A policy of employing Rustdoc aliases to explicitly redirect users of deprecated items to their replacements in Rustdoc search results.

Would it make sense to have this redirection be a part of the rustc_deprecated attribute itself? It seems likely that the replacement is mentioned in the human text of the deprecation; making that machine accessible could be nice.

Actually, this might already be supported, to a degree. #[rustc_deprecated] has both a mandatory reason field, which is shown to the user in warning messages, and an optional suggestion field, which seems like it is intended for machine consumption via cargo fix and the like. The problem is that documentation of this field is so nonexistent that even in the rare places where it's being used, it's being used incorrectly: e.g. here is the suggestion that motivated that this field be added in the first place, and yet cargo fix exits with an error when it tries and invariably fails to apply this suggestion. Here is an item where cargo fix applies the suggestion properly. AFAICT the current implementation is limited to only transforming one identifier into another identifier, without being able to do anything smarter e.g. transforming an identifier into an expression, changing parameter order, adding import paths, etc. But even with those limitations this could still probably be successfully applied to several of the items mentioned in the RFC (currently none at all are making use of this). I'll update the RFC with this in mind.


Historically, I have not found sufficient motivation for actually hiding things. It doesn't have any of the traditional advantages of removal, because they're not removed, only hidden.

For users of the new edition these items would be effectively removed; the only stronger statement would be to forbid instead of deny them, which would also be fully within the purview of an edition's capabilities.

Upon reading this RFC, it seems like the only clear benefit is "the documentation is smaller."

The goal is not smallness, rather it is that the documentation should not be permanently cluttered with things that users are encouraged not to use. To illustrate, as of Rust 1.52, of the 61 stable modules in the Rust stdlib, 12 of them will be marked as deprecated; a full fifth of the modules listed on the index page will be for modules that users are expected to ignore. Of course, due to the conservative policy proposed here, these specific modules would not actually be removed for several more years, but it would be nice to think that someday they would no longer clutter the index. This problem of increasing noise in the documentation is only going to become more acute as time passes; this RFC seeks to tackle it before it becomes too onerous.


My concern: People reading code sometimes search the docs for APIs used by that code in order to figure out what they do.

This is addressed by the following:

  1. When a user uses a deprecated item, they currently receive a compiler warning telling them what the suggested replacement is. Under this RFC, for users on new editions this warning would become an error, but the compiler message would remain the same. It is simple to search for the documentation of the suggested replacement.
  2. As proposed by this RFC, Rustdoc aliases would be leveraged so that even users who haven't compiled the code would be shown the documentation of its suggested replacement.
  3. As mentioned above, and as will be proposed by the next revision of this RFC, the suggestion field may be leveraged to automate the transition away from deprecated items, reducing the number of occurrences wherein a user has an excuse to examine a deprecated item.

Maybe some kind of "collapse and/or fade" behaviour for APIs removed on the current edition

An interesting idea, I'll add this to the alternatives section, and will pursue it further if there is continued resistance to the doc(hidden) aspect of this RFC.


I'd like deprecations to become deny by default in newer editions, but if they're still in older editions I still might want to look them up in the docs. Making that harder seems like it has no advantages.

The RFC's argument is not that there are no disadvantages, but rather that on balance it is a positive for consumers of the documentation. For example, see the search results page when searching for "max"; on my screen, of the 23 results that are immediately visible and above the fold, 14 of them are deprecated; if you were looking for a numeric constant, the 14 deprecated ones have pushed all but 3 of the suggested replacements off the bottom of the screen, below the fold. This is exacerbated by the fact that search results show no deprecation warning, and by the fact that deprecated items are sorting before non-deprecated ones; fixing both of these would involved annotating search results with additional markup and metadata, further swelling the enormous multi-megabyte JSON file that powers the search engine and which is starting to contribute to complaints of slowness of Rustdoc's search. Removing old deprecated items would free up size budget that could be spent treating newer deprecated items more intelligently, which would benefit every user of the docs, even those that aren't searching for anything related to a deprecated item.

bstrie

comment created time in 5 hours

issue closedrust-lang/rust-clippy

False positive with redundant_closure

<!-- Hi there! Whether you've come to make a suggestion for a new lint, an improvement to an existing lint or to report a bug or a false positive in Clippy, you've come to the right place.

For bug reports and false positives, please include the output of cargo clippy -V in the report.

Thank you for using Clippy!

Write your comment below this line: -->

Not sure if it's not a duplicate of some issue, there are a lot of tickets, but this still seems distinct. Tested both on nightly and stable.

~/k/pastebinrun (master|✔) $ cargo clippy -V
clippy 0.0.212 (082cfa7 2019-06-07)
~/k/pastebinrun (master|✔) $ cargo +nightly clippy -V
clippy 0.0.212 (b041511 2019-08-07)

Sample code:

fn callbacker(_: impl Fn(&mut [u8])) {}
fn g<W>(_: W) {}
fn main() {
    callbacker(|w| g(w));
}

Causes the following warning.

    Checking playground v0.0.1 (/playground)
warning: redundant closure found
 --> src/main.rs:4:16
  |
4 |     callbacker(|w| g(w));
  |                ^^^^^^^^ help: remove closure as shown: `g`
  |
  = note: `#[warn(clippy::redundant_closure)]` on by default
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#redundant_closure

The closure cannot be removed as shown.

closed time in 5 hours

xfix

push eventrust-lang/rust-clippy

Cameron Steffen

commit sha bf98aa6fb8e02db15ad18d517145f13a5bed2921

Fix redundant closure with macros

view details

Cameron Steffen

commit sha 8c540dcd2d1d240219c1a4aa28dd745ea010b501

Improve the redundant_closure message

view details

bors

commit sha 2cb5bbf80ca497956531c071661dfd370d95fcf3

Auto merge of #6871 - camsteffen:redundant-closure-macro, r=Manishearth Fix redundant closure with macros changelog: Fix redundant_closure FPs with macros Fixes #6732 Fixes #6850 Fixes #4354 (addresses the error message confusion)

view details

push time in 5 hours

PR merged rust-lang/rust-clippy

Fix redundant closure with macros S-waiting-on-review

changelog: Fix redundant_closure FPs with macros

Fixes #6732 Fixes #6850 Fixes #4354 (addresses the error message confusion)

+98 -40

5 comments

4 changed files

camsteffen

pr closed time in 5 hours

issue closedrust-lang/rust-clippy

redundant_closure must not expand macro in suggestion

<!-- Thank you for filing a bug report! 🐛 Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --> Lint name: redundant_closure

warning: redundant closure found
   --> src/iter/test.rs:121:13
    |
121 |             || vec![],
    |             ^^^^^^^^^ help: remove closure as shown: `$crate::vec::Vec::new`
    |
    = note: `#[warn(clippy::redundant_closure)]` on by default
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#redundant_closure

This is obviously not going to work with $crate::vec...

The suggestion should just say Vec::new()

How to fix: find out where the lint generates the snippet and use snippet_with_macro_callsite instead of just snippet.

( this type of bug popped up a couple of times already https://github.com/rust-lang/rust-clippy/pull/6801#issuecomment-787063756 maybe we should lint for that?)

closed time in 5 hours

matthiaskrgr

issue closedrust-lang/rust-clippy

False Positive: redundant_closure with macro

<!-- Thank you for filing a bug report! 🐛 Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --> Lint name: redundant_closure

I tried this code:

use quote::quote;

fn _bar() {
    // Clippy suggests '||quote!()' => '$crate::__private::TokenStream::new'
    let _ = true.then(||quote!());
}

Playground

Meta

clippy 0.0.212 (cb75ad5d 2021-02-10)

rustc 1.50.0 (cb75ad5db 2021-02-10)
binary: rustc
commit-hash: cb75ad5db02783e8b0222fee363c5f63f7e2cf5b
commit-date: 2021-02-10
host: x86_64-pc-windows-msvc
release: 1.50.0

closed time in 5 hours

TyPR124

pull request commentrust-lang/rust-clippy

Fix redundant closure with macros

:sunny: Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test Approved by: Manishearth Pushing 2cb5bbf80ca497956531c071661dfd370d95fcf3 to master... <!-- homu: {"type":"BuildCompleted","approved_by":"Manishearth","base_ref":"master","builders":{"checks-action_test":"https://github.com/rust-lang/rust-clippy/runs/2060519908","checks-action_dev_test":"https://github.com/rust-lang/rust-clippy/runs/2060432945","checks-action_remark_test":"https://github.com/rust-lang/rust-clippy/runs/2060426045"},"merge_sha":"2cb5bbf80ca497956531c071661dfd370d95fcf3"} -->

camsteffen

comment created time in 5 hours

pull request commentrust-lang/rust-clippy

Fix redundant closure with macros

:hourglass: Testing commit 8c540dcd2d1d240219c1a4aa28dd745ea010b501 with merge 2cb5bbf80ca497956531c071661dfd370d95fcf3... <!-- homu: {"type":"BuildStarted","head_sha":"8c540dcd2d1d240219c1a4aa28dd745ea010b501","merge_sha":"2cb5bbf80ca497956531c071661dfd370d95fcf3"} -->

camsteffen

comment created time in 6 hours

push eventrust-lang/rust-clippy

Cameron Steffen

commit sha bf98aa6fb8e02db15ad18d517145f13a5bed2921

Fix redundant closure with macros

view details

Cameron Steffen

commit sha 8c540dcd2d1d240219c1a4aa28dd745ea010b501

Improve the redundant_closure message

view details

bors

commit sha 2cb5bbf80ca497956531c071661dfd370d95fcf3

Auto merge of #6871 - camsteffen:redundant-closure-macro, r=Manishearth Fix redundant closure with macros changelog: Fix redundant_closure FPs with macros Fixes #6732 Fixes #6850 Fixes #4354 (addresses the error message confusion)

view details

push time in 6 hours

pull request commentrust-lang/rust-clippy

Fix redundant closure with macros

:pushpin: Commit 8c540dcd2d1d240219c1a4aa28dd745ea010b501 has been approved by Manishearth

<!-- @bors r=Manishearth 8c540dcd2d1d240219c1a4aa28dd745ea010b501 --> <!-- homu: {"type":"Approved","sha":"8c540dcd2d1d240219c1a4aa28dd745ea010b501","approver":"Manishearth"} -->

camsteffen

comment created time in 6 hours

pull request commentrust-lang/rust-clippy

Fix redundant closure with macros

@bors r+

camsteffen

comment created time in 6 hours

pull request commentrust-lang/rust-clippy

Fix redundant closure with macros

r? @Manishearth

(rust-highfive has picked a reviewer for you, use r? to override)

camsteffen

comment created time in 8 hours

PR opened rust-lang/rust-clippy

Fix redundant closure with macros

changelog: Fix redundant_closure FPs with macros

Fixes #6732 Fixes #6850

+98 -40

0 comment

4 changed files

pr created time in 8 hours

pull request commentrust-lang/rust-clippy

Opt-in to rustc_private for `rust-analyzer`

This tells rust-analyzer to use the rustc_private crates located at rust-analyzer.rustcSource for development of the crates within clippy (This setting can be "discover" to automatically detect it based on your active toolchain, which works because rustc-dev ships the source now). This is now opt-in and allows rust-analyzer to resolve the rustc crates for non-workspace member crates - previously it was implicitely active for every crate in the current workspace.

This should mean that so long as every user has:

{ "rust-analyzer.rustcSource": "discover" }

set, rust-analyzer should just work in this repository.

That being said, if you have rustcSource set and are working within the rust repository itself, then you might still have problems. I'm not sure how developing within rust currently works using rust-analyzer so some clarification on that would be helpful. However, in any case this change does not change behaviour (i.e. this change is not a regression, since the dependency on the rustc_private crates would still have been added automatically, this just makes it implcit).

That is, previous to this change I believe rust-analyzer would not correctly work on the version of clippy within the rust repo, and it still won't.

This should obsolete #5803 (and/or the other upstream changes already have done that, and this PR only brings it to your attention).

DJMcNab

comment created time in 8 hours

pull request commentrust-lang/rust-clippy

`match_wildcard` imporvements

I left the wording as is, but it could be improved.

The suggestion to change the message instead of ignore the lint for Option and Result was from @camsteffen. I can definitely agree with it for wildcard_enum_match_arm, which is just banning wild matches outright. I'm not really sure about match_wildcard_for_single_variants though. The reason for the lint is the wild match is standing in for a singled variant, but new ones might be added in the future. This is just not true for most std types.

Jarcho

comment created time in 8 hours

pull request commentrust-lang/rust-clippy

Opt-in to rustc_private for `rust-analyzer`

What does this do? Is it related to https://github.com/rust-lang/rust-clippy/issues/5803 ? Does it change the way rust-analyzer handles the way clippy depends on rustc crates? How does it interact with the subrepo nested inside the rustc repo vs the standalone repo that we have here?

DJMcNab

comment created time in 8 hours

issue openedrust-lang/rust-clippy

Suggest replacing .map(f).flatten() with .and_then(f) on Options

What it does

What does this lint do? Checks for usage of _.map(_).flatten(),

This is like https://rust-lang.github.io/rust-clippy/master/index.html#map_flatten but for Options instead of Iterators

Categories (optional)

  • Kind: clippy::style/complexity

Easier to follow what's happening, shorter

Drawbacks

None.

Example

Inspired by @steffahn's suggestion in https://github.com/Nadrieril/dhall-rust/pull/213#issuecomment-792793983

created time in 8 hours