Only store a LocalDefId in some HIR nodes
Some HIR nodes are guaranteed to be HIR owners: Item, TraitItem, ImplItem, ForeignItem and MacroDef.
As a consequence, we do not need to store the `HirId`'s `local_id`, and we can directly store a `LocalDefId`.
This allows to avoid a bit of the dance with `tcx.hir().local_def_id` and `tcx.hir().local_def_id_to_hir_id` mappings.
validation: fix invalid-fn-ptr error message
https://github.com/rust-lang/rust/pull/82061 changed the code here to print an `ImmTy` instead of a `ScalarMaybeUninit`; that was an accident. So go back to printing a `ScalarMaybeUninit`.
r? ```@oli-obk```
avoid full-slicing slices
If we already have a slice, there is no need to get another full-range slice from that, just use the original.
clippy::redundant_slicing
Fix ES5 errors (IE11)
rustdoc is supposed to run on IE11 but someone reported me that it wasn't. I just confirmed it by using `es-check` with the `es5` option like this:
```
$ es-check es5 src/librustdoc/html/static/*.js
```
The PR fixes those issues and add CI checks to prevent regressions.
`@Mark-Simulacrum:` I added checks in the CI, but not sure if it's the correct way to do it. Any help on that side would be very appreciated!
r? `@Nemo157`
New lint: default_numeric_fallback
fixes#6064
r? `@flip1995`
As we discussed in [here](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Issue.20.236064/near/224647188) and [here](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Issue.20clippy.236064/near/224746333), I start implementing this lint from the strictest version.
In this PR, I'll allow the below two cases to pass the lint to reduce FPs.
1. Appearances of unsuffixed numeric literals in `Local` if `Local` has a type annotation, for example:
```rust
// Good.
let x: i32 = 1;
// Also good.
let x: (i32, i32) = if cond {
(1, 2)
} else {
(2, 3)
};
```
2. Appearances of unsuffixed numeric literals in args of `Call` or `MethodCall` if corresponding arguments of their signature have concrete types, for example:
```rust
fn foo_mono(x: i32) -> i32 {
x
}
fn foo_poly<T>(t: T) -> t {
t
}
// Good.
let x = foo_mono(13);
// Still bad.
let x: i32 = foo_poly(13);
```
changelog: Added restriction lint: `default_numeric_fallback`
more lintcheck updates
* do some refactoring and renaming here and there
* add comments to functions
* fix bug where git repos would not get checked out to the proper commits (cmd was not actually run in repo directory 😅 )
* print warnings if we can't clone or check out a git repo
* filter out noise from cargo-metadata errors and lint messages that contained absolute file paths (these would change with every pinned-nightly bump, polluting the logs)
changelog: more lintcheck refactoring and fixes for git crates
It can be useful to do some computation in `assert!` format arguments, in order to get better error messages. For example:
```rust
assert!(
some_condition,
"The state is invalid. Details: {}",
expensive_call_to_get_debugging_info(),
);
```
It seems like `assert!` only evaluates the format arguments if the assertion fails, which is useful but doesn't appear to be documented anywhere. This PR documents the behavior and adds some tests.
Ensures `make` tests run under /bin/dash (if available), like CI, and fixes a Makefile
Note: This cherrypicks #81688 (`@pnkfelix)`
Updates `tools.mk` to explicitly require `SHELL := /bin/dash`, since CI uses `dash` but other environments (including developer local machines) may default to `bash`.
Replaces bash-specific shell command in one Makefile with a dash-compatible alternative, and re-enables the affected Makefile test.
Removes apparently redundant definition of `UNAME`.
Also see: [zulip discussion thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/how.20to.20run.2Fbless.20src.2Ftest.2Frun-make-fulldeps.2Fcoverage.20.3F)
r? `@pnkfelix`
FYI: `@wesleywiser` `@tmandry`
