… r=b-naber

Make elaboration generic over input

Combines all the `elaborate_*` family of functions into just one, which is an iterator over the same type that you pass in (e.g. elaborating `Predicate` gives `Predicate`s, elaborating `Obligation`s gives `Obligation`s, etc.)

Instead of repeating the same logic by walking HIR during metadata encoding.

The only difference is that we are no longer encoding `macro_rules` items, but we never currently need them as a part of this list.
They can be encoded separately if this need ever arises.

`module_reexports` is also un-querified, because I don't see any reasons to make it a query, only overhead.

resolve: Pre-compute non-reexport module children

Instead of repeating the same logic by walking HIR during metadata encoding.

The only difference is that we are no longer encoding `macro_rules` items, but we never currently need them as a part of this list. They can be encoded separately if this need ever arises.

`module_reexports` is also un-querified, because I don't see any reasons to make it a query, only overhead.

This allows allocating `Expr`s into a dropless arena, which is useful
for using length prefixed thing slices in HIR, since these can only be
allocated in the dropless arena and not in a typed arena. This is
something I'm working on.

…errors

Don't transmute `&List<GenericArg>` <-> `&List<Ty>`

In rust-lang#93505 we allowed safely transmuting between `&List<GenericArg<'_>>` and `&List<Ty<'_>>`. This was possible because `GenericArg` is a tagged pointer and the tag for types is `0b00`, such that a `GenericArg` with a type inside has the same layout as `Ty`.

While this was meant as an optimization, it doesn't look like it was actually any perf or max-rss win (see rust-lang#94799 (comment), rust-lang#94841, rust-lang#110496 (comment)).

Additionally the way it was done is quite fragile — `unsafe` code was not properly documented or contained in a module, types were not marked as `repr(C)` (making the transmutes possibly unsound). All of this makes the code maintenance harder and blocks other possible optimizations (as an example I've found out about these `transmutes` when my change caused them to sigsegv compiler).

Thus, I think we can safely (pun intended) remove those transmutes, making maintenance easier, optimizations possible, code less cursed, etc.

r? `@compiler-errors`

Fixes rust-lang#10634

…icit_item_bounds usages; remove bound_explicit_item_bounds query

…lyBinder; use this to simplify some EarlyBinder noise around explicit_item_bounds calls

Enable flatten-format-args by default.

Part of rust-lang#99012.

This enables the `flatten-format-args` feature that was added by rust-lang#106824:

> This change inlines string literals, integer literals and nested format_args!() into format_args!() during ast lowering, making all of the following pairs result in equivalent hir:
>
> ```rust
> println!("Hello, {}!", "World");
> println!("Hello, World!");
> ```
>
> ```rust
> println!("[info] {}", format_args!("error"));
> println!("[info] error");
> ```
>
> ```rust
> println!("[{}] {}", status, format_args!("error: {}", msg));
> println!("[{}] error: {}", status, msg);
> ```
>
> ```rust
> println!("{} + {} = {}", 1, 2, 1 + 2);
> println!("1 + 2 = {}", 1 + 2);
> ```
>
> And so on.
>
> This is useful for macros. E.g. a `log::info!()` macro could just pass the tokens from the user directly into a `format_args!()` that gets efficiently flattened/inlined into a `format_args!("info: {}")`.
>
> It also means that `dbg!(x)` will have its file, line, and expression name inlined:
>
> ```rust
> eprintln!("[{}:{}] {} = {:#?}", file!(), line!(), stringify!(x), x); // before
> eprintln!("[example.rs:1] x = {:#?}", x); // after
> ```
>
> Which can be nice in some cases, but also means a lot more unique static strings than before if dbg!() is used a lot.

This is mostly an optimization, except that it will be visible through [`fmt::Arguments::as_str()`](https://doc.rust-lang.org/nightly/std/fmt/struct.Arguments.html#method.as_str).

In rust-lang#106823, there was already a libs-api FCP about the documentation of `fmt::Arguments::as_str()` to allow it to give `Some` rather than `None` depending on optimizations like this. That was just a documentation update though. This PR is the one that actually makes the user visible change:

```rust
assert_eq!(format_args!("abc").as_str(), Some("abc")); // Unchanged.
assert_eq!(format_args!("ab{}", "c").as_str(), Some("abc")); // Was `None` before!
```

Allow to feed a value in another query's cache and remove `WithOptConstParam`

I used it to remove `WithOptConstParam` queries, as an example.

The idea is that a query (here `typeck(function)`) can write into another query's cache (here `type_of(anon const)`). The dependency node for `type_of` would depend on all the current dependencies of `typeck`.

There is still an issue with cycles: if `type_of(anon const)` is accessed before `typeck(function)`, we will still have the usual cycle.  The way around this issue is to `ensure` that `typeck(function)` is called before accessing `type_of(anon const)`.

When replayed, we may the following cases:
- `typeck` is green, in that case `type_of` is green too, and all is right;
- `type_of` is green, `typeck` may still be marked as red (it depends on strictly more things than `type_of`) -> we verify that the saved value and the re-computed value of `type_of` have the same hash;
- `type_of` is red, then `typeck` is red -> it's the caller responsibility to ensure `typeck` is recomputed *before* `type_of`.

As `anon consts` have their own `DefPathData`, it's not possible to have the def-id of the anon-const point to something outside the original function, but the general case may have to be resolved before using this device more broadly.

There is an open question about loading from the on-disk cache.  If `typeck` is loaded from the on-disk cache, the side-effect does not happen. The regular `type_of` implementation can go and fetch the correct value from the decoded `typeck` results, and the dep-graph will check that the hashes match, but I'm not sure we want to rely on this behaviour.

I specifically allowed to feed the value to `type_of` from inside a call to `type_of`.  In that case, the dep-graph will check that the fingerprints of both values match.

This implementation is still very sensitive to cycles, and requires that we call `typeck(function)` before `typeck(anon const)`.  The reason is that `typeck(anon const)` calls `type_of(anon const)`, which calls `typeck(function)`, which feeds `type_of(anon const)`, and needs to build the MIR so needs `typeck(anon const)`.  The latter call would not cycle, since `type_of(anon const)` has been set, but I'd rather not remove the cycle check.

Add offset_of! macro (RFC 3308)

Implements rust-lang/rfcs#3308 (tracking issue rust-lang#106655) by adding the built in macro `core::mem::offset_of`. Two of the future possibilities are also implemented:

* Nested field accesses (without array indexing)
* DST support (for `Sized` fields)

I wrote this a few months ago, before the RFC merged. Now that it's merged, I decided to rebase and finish it.

cc `@thomcc` (RFC author)

…726,RalfJung

Evaluate place expression in `PlaceMention`

rust-lang#102256 introduces a `PlaceMention(place)` MIR statement which keep trace of `let _ = place` statements from surface rust, but without semantics.

This PR proposes to change the behaviour of `let _ =` patterns with respect to the borrow-checker to verify that the bound place is live.

Specifically, consider this code:
```rust
let _ = {
    let a = 5;
    &a
};
```

This passes borrowck without error on stable. Meanwhile, replacing `_` by `_: _` or `_p` errors with "error[E0597]: `a` does not live long enough", [see playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c448d25a7c205dc95a0967fe96bccce8).

This PR *does not* change how `_` patterns behave with respect to initializedness: it remains ok to bind a moved-from place to `_`.

The relevant test is `tests/ui/borrowck/let_underscore_temporary.rs`. Crater check found no regression.

For consistency, this PR changes miri to evaluate the place found in `PlaceMention`, and report eventual dangling pointers found within it.

r? `@RalfJung`

Rustup

r? `@ghost`

changelog: none

Don't suggest `suboptimal_flops` unavailable in nostd

Fixes rust-lang#10634

changelog: Enhancement: [`suboptimal_flops`]: Do not suggest `{f32,f64}::abs()` or `{f32,f64}::mul_add()` in a `no_std`-environment.

use `is_inside_const_context` for `in_constant` util fn

Fixes rust-lang#10452.

This PR improves the `in_constant` util function to detect more cases of const contexts. Previously this function would not detect cases like expressions in array length position or expression in an inline const block `const { .. }`.

changelog: [`bool_to_int_with_if`]: recognize array length operand as being in a const context and don't suggest `usize::from` there

Run various queries from other queries instead of explicitly in phases

These are just legacy leftovers from when rustc didn't have a query system. While there are more cleanups of this sort that can be done here, I want to land them in smaller steps.

This phased order of query invocations was already a lie, as any query that looks at types (e.g. the wf checks run before) can invoke e.g. const eval which invokes borrowck, which invokes typeck, ...

split test into 2

changelog: none

…e_lints`

This reverts commit 22d435b.

…check, r=llogiq

Remove check for `lib.register_*` and `src/docs*` in `cargo dev update_lints`

The transition period has well passed

changelog: none

* applying
* binding
* complex
* constituent
* demonstrate
* desugaring
* exact
* expression
* for
* functionalities
* github
* implementation
* infers
* multiple conflicting traits
* mutable
* necessarily
* nightly
* nonexistent
* optional
* parameter
* reassignments
* resources
* substitution
* suggestion
* that
* that array is
* using the

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>

New lint: detect `if` expressions with simple boolean assignments to the same target

Closes rust-lang#10430

changelog: [`needless_bool_assign`] new lint to detect simple boolean assignment to the same target in `if` branches

Spelling

This PR corrects misspellings identified by the [check-spelling action](https://github.com/marketplace/actions/check-spelling).

The misspellings have been reported at https://github.com/jsoref/rust-clippy/actions/runs/4710771873#summary-12776860721

The action reports that the changes in this PR would make it happy: https://github.com/jsoref/rust-clippy/actions/runs/4710771874#summary-12776860722

changelog: none

Ignore `shadow` warns in code from macro expansions

This PR fixes rust-lang/rust-clippy#9757

I am in doubt if just looking for `pat.span.from_expansion()` would be sufficient instead of looking for both `pat.span.desugaring_kind().is_some()` or `pat.span.from_expansion()`. The tests (including the new one) passes if I leave the only `if pat.span.from_expansion()`. Any feedbacks?

Also, this is my first PR here, sorry for anything and thanks for the patience!

changelog: [`shadow_same`, `shadow_reuse`, `shadow_unrelated`]: avoiding warns in macro-generated code

Fix false positive in `allow_attributes`

This would emit a warning if used in a proc-macro with the feature `lint_reasons` enabled. This is now fixed.

changelog: [`allow_attributes`]: Don't lint if in external macro

…t, r=Manishearth

check for `..` pattern in `redundant_pattern_matching`

The `redundant_pattern_matching` lint currently checks for `if let Some(_) = ...`, but not for `if let Some(..) = ...`.
This PR makes sure to also check for the `..` pattern in tuple structs.
It also found one such instance in clippy itself so that shows it's worth checking for this pattern as well 😅

changelog: [`redundant_pattern_matching`]: check for `..` pattern in tuple structs

…lp_message, r=Manishearth

Improve the help message + add a help span

This would close rust-lang#10410, because it applies the general consensus achieved in that issue (that replacing `let _ = ...` to `_ = ...` doesn't present any benefits).

I also added a little help message span.

changelog:[`let_underscore_untyped`]: Fix the help message confusion + add a help message span.

Update Clippy

r? `@Manishearth`

A few days late, I was on a business trip, sorry.

…r=giraffate

Don't apply `string_lit_as_bytes` if in macro expansion

The following code will emit a warning on both w! and h!, despite there being nothing the user (or library author) could do about it:
```rust
#![warn(clippy::string_lit_as_bytes)]

use windows::w;
use windows::h;

fn main() {
    let _w = w!("example");
    let _h = h!("example");
}
```
This is because windows-rs will create a binding `const INPUT: &[u8] = $s.as_bytes()`, and changing this to b"$s" is, well, suboptimal. I don't know enough about Rust to know if this is something that can be detected though if it can be I'm happy with closing this in favor of implementing that.

I'm not sure whether this is how it should be done though, as this simply tells clippy to not invoke this even if it's applicable (this also affects the other string lints, but didn't cause any tests to fail).

changelog: [`string_lit_as_bytes`]: Don't lint if in external macro

…y) 😅

Catching, stray, commas, (I'll, never, learn, to, use, them, correctly)  😅

Roses are red,
Violets are blue,
Fixing commas,
Is the completed todo.

(It's always impressive, that the poems are getting worse)

---

Follow-up from: rust-lang/rust-clippy#10668

changelog: none

…ts, r=llogiq

Document that `cargo clippy --fix` implies `--all-targets`

In [`cargo fix`'s documentation](https://doc.rust-lang.org/cargo/commands/cargo-fix.html) they indicate that `fix` implies `--all-targets` if no target is supplied. As Clippy uses Cargo under the hood, this also applies to Clippy, but we didn't document that behaviour.

This PR changes that

Fixes rust-lang#10690
changelog: Add to documentation that `--fix` implies `--all-targets`

…tem-bounds, r=compiler-errors

Switch to `EarlyBinder` for `explicit_item_bounds`

Part of the work to finish rust-lang#105779.

This PR adds `EarlyBinder` to the return type of the `explicit_item_bounds` query and removes `bound_explicit_item_bounds`.

r? `@compiler-errors` (hope it's okay to request you, since you reviewed rust-lang#110299 and rust-lang#110498 😃)

Add configuration for `semicolon_block` lints

Does exactly what it says on the tin, suggests moving a block's final semicolon inside if it's multiline and outside if it's singleline.

I don't really like how this is implemented so I'm not too sure if this is ready yet. Alas, it might be ok.

---

fixes rust-lang#10654

changelog: Enhancement: [`semicolon_inside_block`]: Added `semicolon-inside-block-ignore-singleline` as a new config value.
[rust-lang#10656](rust-lang/rust-clippy#10656)
changelog: Enhancement: [`semicolon_outside_block`]: Added `semicolon-outside-block-ignore-multiline` as a new config value.
[rust-lang#10656](rust-lang/rust-clippy#10656)
<!-- changelog_checked -->

Using `default` to construct a unit struct increases code complexity and
adds a function call. This can be avoided by simply removing the call to
`default` and simply construct by name.

fix new lints link

install nightly rust-docs

run linkcheck without nightly toolchain

remove nightly toolchain, add rust-docs component

Test Remark

Update basics.md

Update basics.md

Update basics.md

update workflow

add rust docs toolchain

Update remark.yml

workflow test

manual test

update book path

add linkcheck book to CI

Update lint_passes.md

run linkcheck in clippy ci

fixes rust-lang#10711

changelog: Run [linkcheck.sh](https://github.com/rust-lang/rust/blob/master/src/tools/linkchecker/linkcheck.sh) from rustc repo in Remark.yml to check Clippy book.

…rted_modules, r=Alexendoo

Fix `items_after_test_module`: Ignore imported modules

Fixes rust-lang#10713. It does a little bit of dark magic, but intention is what really counts.
changelog:[`items_after_test_module`]: Ignore imported modules (`mod foo;`) with no body.