The lint message will now use the full, correct path to the `Debug`
trait, even in `no_std`.

also refactor `FnKind` and `visit_assoc_item` visitors

It's not needed.

…ionForest, r=nikomatsakis

Remove `RefCell` usage from `ObligationForest`.

It's not needed.

This doesn't affect performance, it just simplifies the code a little.

r? @nikomatsakis

…=Centril

Implement `unused_parens` for `const` and `static` items

Fixes rust-lang#67942

…henkov

Towards unified `fn` grammar

Part of rust-lang#68728.

- Syntactically, `fn` items in `extern { ... }` blocks can now have bodies (`fn foo() { ... }` as opposed to `fn foo();`). As above, we use semantic restrictions instead.

- Syntactically, `fn` items in free contexts (directly in a file or a module) can now be without bodies (`fn foo();` as opposed to `fn foo() { ... }`. As above, we use semantic restrictions instead, including for non-ident parameter patterns.

- We move towards unifying the `fn` front matter; this is fully realized in rust-lang#68728.

r? @petrochenkov

…, r=estebank

Make associated item collection a query

Before this change, every time associated items were iterated over (which rustc does *a lot* – this can probably be further optimized), there would be N+1 queries to fetch all assoc. items. Now there's just one after they've been computed once.

or_patterns: add regression test for rust-lang#68785

Fixes rust-lang#68785.

(Fixed by rust-lang#67668.)

cc rust-lang#54883
r? @estebank

…chenkov

use def_path_str for missing_debug_impls message

The lint message will now use the full, correct path to the `Debug`
trait, even in `no_std`.

stop using BytePos for computing spans in librustc_parse/parser/mod.rs

Computing spans using logic such as `self.token.span.lo() + BytePos(1)` can cause internal compiler errors like rust-lang#68730 when non-ascii characters are given as input.

rust-lang#68735 partially addressed this problem, but only for one case. Moreover, its usage of `next_point()` does not actually align with what `bump_with()` expects. For example, given the token `>>=`, we should pass the span consisting of the final two characters `>=`, but `next_point()` advances the span beyond the end of the `=`.

This pull request instead computes the start of the new span by doing `start_point(self.token.span).hi()`. This matches `self.token.span.lo() + BytePos(1)` in the common case where the characters are ascii, and it gracefully handles multibyte characters.

Fixes rust-lang#68783.

…1, r=Dylan-DPC

clean up E0271 explanation

r? @Dylan-DPC

Forbid using `0` as issue number

Fixes rust-lang#67496

r? @Centril