mut_mut triggers for regex! macro about rust-clippy HOT 9 CLOSED

I think it may not be too problematic and in fact makes a lot of sense: We should watch out for macro expansion and (perhaps optionally) if the macro is external to the current crate, omit the warning.

from rust-clippy.

That sounds good.

We can pick up the syntaxcontext of idents and stuff I think. If an ident is not doc.rust-lang.org/syntax/ast/constant.EMPTY_CTXT.html, we ignore it. Not sure though.

from rust-clippy.

We may want to look up if the macro is defined in the current crate, and issue a warning in that case anyway.

from rust-clippy.

I'm not sure if that info is kept around post-expansion in an easy-to-access manner.

The spans might help here.

from rust-clippy.

I'm curious how the compiler does it when reporting errors – it always tells me which macro was expanded.

Looking into the code, the code map has a function we may be able to use. I'll push an untested prototype into a 'macro_expn' branch. However, I'm not sure if we should include regex! as a test dependency or if there is another alternative.

from rust-clippy.

@killercup: Are you ok with me reusing your line of code as a test case? I may be able to reduce it, but it's the best starting point we have.

from rust-clippy.

@llogiq Sure, you can reproduce about a gazillion lines of this when you compile trpl-ebook with cargo run --features "dev" --release :)

from rust-clippy.

In PR #68 I have added a better in_macro check that we should be able to reuse for other lints (btw. we should even be able to create a basic check_expr(…) to closure adapter that will only trigger when not within an external macro expansion.

Note that this enables you to write e.g. let mut zero = &mut &mut "zero"; within a macro invocation without the lint triggering, but I'm ok with paying that price for getting rid of the false positives.

from rust-clippy.

The latest merged PR #82 makes this issue go away (as well as similar issues in other lints)

from rust-clippy.