Fix typo in alloc_instead_of_core
The description previously claimed it ensures items are imported from alloc, to ensure a crate won't require alloc, which can't be true.
I'm not sure know how to better phrase the changelog entry below.
changelog: [`alloc_instead_of_core`]: fixed typo in description
Add new lint `obfuscated_if_else`
part of #9100, additional commits could make it work with `then` and `unwrap_or_else` as well
changelog: Add new lint `obfuscated_if_else`
unused_self: respect avoid-breaking-exported-api
```
changelog: [`unused_self`]: Now respects the `avoid-breaking-exported-api` config option
```
Fixes#9195.
I mostly copied the implementation from `unnecessary_wraps`, since I don't have much understanding of rustc internals.
Update highlight.js
changelog: none
With [highlight.js v11.6.0](https://github.com/highlightjs/highlight.js/releases/tag/11.6.0), the lint list can finally update from `9.5.0`. No more EOL warning in console! 😄
I also made it switch to the `github-dark` theme when using `coal`, instead of just always using the normal github light theme.
r? `@xFrednet`
Add `std_instead_of_core`, `std_instead_of_alloc`, `alloc_instead_of_core`
Closes#7724
Introduces 3 new lints:
- `std_instead_of_core` - lints items resolved through `std` which are available in `core`
- `std_instead_of_alloc` - lints items resolved through `std` which are available in `alloc`
- `alloc_instead_of_core` - lints items resolved through `alloc` which are available in `core`
Though the original issue only mentions `std_instead_of_alloc`, the other two lints could be useful as well.
questions:
- what do I call the file the lints live in? I was thinking `std_reexports`?
changelog: new lint's: [`std_instead_of_core`], [`std_instead_of_alloc`], [`alloc_instead_of_core`]
[`box_collection`]: raise warn for all std collections
So far, only [`Vec`, `String`, `HashMap`] were considered.
Extend collection checklist for this lint with:
- `HashSet`
- `VecDeque`
- `LinkedList`
- `BTreeMap`
- `BTreeSet`
- `BinaryHeap`
changelog: [`box_collection`]: raise warn for all std collections
Move format_push_string to restriction
Fixes#9077 (kinda) by moving the lint to the restriction group. As I noted in that issue, I think the suggested change is too much and as the OP of the issue points out, the ramifications of the change are not necessarily easily understood. As such I don't think the lint should be enabled by default.
changelog: [`format_push_string`]: moved to restriction (see #9077).
Implement `for<>` lifetime binder for closures
This PR implements RFC 3216 ([TI](https://github.com/rust-lang/rust/issues/97362)) and allows code like the following:
```rust
let _f = for<'a, 'b> |a: &'a A, b: &'b B| -> &'b C { b.c(a) };
// ^^^^^^^^^^^--- new!
```
cc ``@Aaron1011`` ``@cjgillot``
Always create elided lifetime parameters for functions
Anonymous and elided lifetimes in functions are sometimes (async fns) --and sometimes not (regular fns)-- desugared to implicit generic parameters.
This difference of treatment makes it some downstream analyses more complicated to handle. This step is a pre-requisite to perform lifetime elision resolution on AST.
There is currently an inconsistency in the treatment of argument-position impl-trait for functions and async fns:
```rust
trait Foo<'a> {}
fn foo(t: impl Foo<'_>) {} //~ ERROR missing lifetime specifier
async fn async_foo(t: impl Foo<'_>) {} //~ OK
fn bar(t: impl Iterator<Item = &'_ u8>) {} //~ ERROR missing lifetime specifier
async fn async_bar(t: impl Iterator<Item = &'_ u8>) {} //~ OK
```
The current implementation reports "missing lifetime specifier" on `foo`, but **accepts it** in `async_foo`.
This PR **proposes to accept** the anonymous lifetime in both cases as an extra generic lifetime parameter.
This change would be insta-stable, so let's ping t-lang.
Anonymous lifetimes in GAT bindings keep being forbidden:
```rust
fn foo(t: impl Foo<Assoc<'_> = Bar<'_>>) {}
^^ ^^
forbidden ok
```
I started a discussion here: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Anonymous.20lifetimes.20in.20universal.20impl-trait/near/284968606
r? ``@petrochenkov``
