Add a new test ui/incoherent-inherent-impls/no-other-unrelated-errors to check E0116 does not cause unrelated errors
rustc xxx (we do not know) to 1.82.0 emits unrelated errors when E0116 is present (see #125814).
We do not know what caused and fixed it, but add a test to confirm rustc does not cause the same error in the future.
No need to create placeholders for GAT args in confirm_object_candidate
We no longer need this logic to add placeholders for GAT args since with the removal of the `gat_extended` feature gate (https://github.com/rust-lang/rust/pull/133768) we no longer allow GATs in dyn trait anyways.
r? oli-obk
Rename `core_pattern_type` and `core_pattern_types` lib feature gates to `pattern_type_macro`
That's what the gates are actually gating, and the single char difference in naming was not helpful either
fixes#128987
Update books
## rust-lang/book
12 commits in e16dd73690a6cc3ecdc5f5d94bbc3ce158a42e16..614c19cb4025636eb2ba68ebb3d44e3bd3a5e6e4
2024-12-02 16:22:15 UTC to 2024-11-26 21:15:51 UTC
- Fix more inverted uses of “shadowed” (rust-lang/book#4122)
- Fix a couple inverted uses of “shadowed” (rust-lang/book#4121)
- Fix confusion between variable `hello` and string `"hello"` (rust-lang/book#4118)
- Ch. 17: fix some wording issues (rust-lang/book#4117)
- Rephrase for clarity (rust-lang/book#3809)
- Link to tests section of rustc book for `cargo test -- --help` docs (rust-lang/book#4116)
- Drop a pedantry-triggering sentence about IEEE-754 (rust-lang/book#4114)
- Very small clarification on if let (rust-lang/book#4113)
- Ch17-05: Typos (rust-lang/book#4099)
- Ch20-01: Fix typos (rust-lang/book#4105)
- Add a short paragraph on editors and IDEs in installation (rust-lang/book#4112)
- Rust 2024: update Ch. 20 for new `unsafe` rules (rust-lang/book#4111)
## rust-lang/reference
8 commits in 5c86c739ec71b8bc839310ff47fa94e94635bba9..ede56d1bbe132bac476b5029cd6d7508ca9572e9
2024-11-25 17:23:35 +0000 to 2024-12-03 22:26:55 +0000
- Claim to follow Unicode 16 for lexing identifiers. (rust-lang/reference#1688)
- Clarify rules for on_unimplemented warnings (rust-lang/reference#1680)
- Enable triagebot merge-conflict notifications (rust-lang/reference#1682)
- Update default edition to 2024 for code examples (rust-lang/reference#1684)
- Fix weak keywords (rust-lang/reference#1685)
- `const` expression can borrow static items (rust-lang/reference#1610)
- Update function-pointer.md for stabilization of `extended_varargs_abi_support` (rust-lang/reference#1687)
- fix inconsistent spacing in example (rust-lang/reference#1686)
## edition-guide
1 commits in f48b0e842a3911c63240e955d042089e9e0894c7..128669297c8a7fdf771042eaec18b8adfaeaf0cd
2024-11-25 16:20:27 +0000 to 2024-12-03 22:02:43 +0000
- Fix `if_let_rescope` applicability (rust-lang/edition-guide#339)
## rust-lang/rustc-dev-guide
6 commits in 787b4166ccc67bd8f72a6e3ef6685ce9ce82909a..b21d99b770f9aceb0810c843847c52f86f45d2ed
2024-12-02 04:45:30 UTC to 2024-11-27 10:31:58 UTC
- Spell out `git submodule deinit -f --all` (rust-lang/rustc-dev-guide#2153)
- Explain how to deal with exploded git submodules (rust-lang/rustc-dev-guide#2152)
- Update `//@ proc-macro` aux build directive docs (rust-lang/rustc-dev-guide#2149)
- Remove `pretty-expanded` as it no longer exists (rust-lang/rustc-dev-guide#2147)
- Fix trivial typo (rust-lang/rustc-dev-guide#2148)
- Remove -Zfuel. (rust-lang/rustc-dev-guide#2032)
Add lint against function pointer comparisons
This is kind of a follow-up to https://github.com/rust-lang/rust/pull/117758 where we added a lint against wide pointer comparisons for being ambiguous and unreliable; well function pointer comparisons are also unreliable. We should IMO follow a similar logic and warn people about it.
-----
## `unpredictable_function_pointer_comparisons`
*warn-by-default*
The `unpredictable_function_pointer_comparisons` lint checks comparison of function pointer as the operands.
### Example
```rust
fn foo() {}
let a = foo as fn();
let _ = a == foo;
```
### Explanation
Function pointers comparisons do not produce meaningful result since they are never guaranteed to be unique and could vary between different code generation units. Furthermore different function could have the same address after being merged together.
----
This PR also uplift the very similar `clippy::fn_address_comparisons` lint, which only linted on if one of the operand was an `ty::FnDef` while this PR lints proposes to lint on all `ty::FnPtr` and `ty::FnDef`.
```@rustbot``` labels +I-lang-nominated
~~Edit: Blocked on https://github.com/rust-lang/libs-team/issues/323 being accepted and it's follow-up pr~~
Implement diagnostics in all places left: generics (predicates, defaults, const params' types), fields, and type aliases.
Unfortunately this results in a 20mb addition in `analysis-stats .` due to many type methods returning an addition diagnostics result now (even if it's `None` in most cases). I'm not sure if this can be improved.
An alternative strategy that can prevent the memory usage growth is to never produce diagnostics in hir-ty methods. Instead, lower all types in the hir crate when computing diagnostics from scratch (with diagnostics this time). But this has two serious disadvantages:
1. This can cause code duplication (although it can probably be not that bad, it will still mean a lot more code).
2. I believe we eventually want to compute diagnostics for the *entire* workspace (either on-type or on-save or something alike), so users can know when they have diagnostics even in inactive files. Choosing this approach will mean we lose all precomputed salsa queries. For one file this is fine, for the whole workspace this will be very slow.
The diagnostic implemented is a simple one (E0109). It serves as a test for the new foundation.
This commit only implements diagnostics for type in bodies and body-carrying signatures; the next commit will include diagnostics in the rest of the things.
Also fix one weird bug that was detected when implementing this that caused `Fn::(A, B) -> C` (which is a valid, if bizarre, alternative syntax to `Fn(A, B) -> C` to lower incorrectly.
And also fix a maybe-bug where parentheses were sneaked into a code string needlessly; this was not detected until now because the parentheses were removed (by the make-AST family API), but with a change in this commit they are now inserted. So fix that too.
Most paths are types and therefore already are in the source map, but the trait in impl trait and in bounds are not.
We do this by storing them basically as `TypeRef`s. For convenience, I created a wrapper around `TypeRefId` called `PathId` that always stores a path, and implemented indexing from the types map to it.
Fortunately, this change impacts memory usage negligibly (adds 2mb to `analysis-stats .`, but that could be just fluff). Probably because there aren't that many trait bounds and impl traits, and this also shrinks `TypeBound` by 8 bytes.
I also added an accessor to `TypesSourceMap` to get the source code, which will be needed for diagnostics.
We add union fields access (in both expressions and patterns) and inline assembly.
That completes the unsafe check (there are some other unsafe things but they are unstable), and so also opens the door to reporting unused unsafe without annoying people about their not-unused unsafe blocks.
When a glob import overriding the visibility of a previous glob import was not properly resolved when the items are only available in the next fixpoint iteration.
The bug was hidden until #18390.
Only in calls, because to support them in bounds we need support from Chalk. However we don't yet report error from bounds anyway, so this is less severe.
The returned future is shown in its name within inlay hints instead of as a nicer `impl Future`, but that can wait for another PR.
