error: Potential incomplete link
┌─ fuzzing.md:41:122
│
41 │ > error: internal compiler error: compiler/rustc_middle/src/ty/normalize_erasing_regions.rs:195:90: Failed to normalize <[closure@src/main.rs:36:25: 36:28] as std::ops::FnOnce<(Emplacable<()>,)>>::Output, maybe try to call `try_normalize_erasing_regions` instead
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Did you forget to define a URL for `closure@src/main.rs:36:25: 36:28`?
`declare_lint_pass` for `INLINE_ALWAYS_MISMATCHING_TARGET_FEATURES`
The `INLINE_ALWAYS_MISMATCHING_TARGET_FEATURES` lint was missing from this causing it to be an unknown lint when attempting to allow it.
r? ``@davidtwco``
Add a sanity check in case of any duplicate nodes
A simple check in case compiler tries to encode a dep node twice like in rust-lang/rust#141540.
Also if we'd try to mark a red node as green as it may then create a bad `DepNodeIndex` like in rust-lang/rust#148295.
If it prevents rust-lang/rust#141540 from emitting a faulty `dep-graph.bin` file via panic then it means you will be able to temporarily fix it by simply restarting cargo or rust-analyzer without cleaning up incremental cache.
bootstrap: Don't pass an unused `--color` to compiletest
- Follow-up to https://github.com/rust-lang/rust/pull/149850
---
This flag was an artifact of compiletest's old libtest-based test executor, and currently doesn't influence compiletest's output at all.
A follow-up commit also inlines `force_coloring_in_ci` into its only remaining caller, and updates its comment.
Weak for Arc pointer is marked as DynSend/DynSync
`std::sync::Weak` (weak pointer for Arc) added to DynSend and DynSync (looks like it was missed to add there when implemented).
Fix: Prevent macro-expanded extern crates from shadowing extern arguments
prevents an ICE by fixing a logic bug in `build_reduced_graph.rs`.
the bug caused the compiler to correctly detect and report a shadowing error for a macro-expanded `extern crate` but then continue processing the invalid item, corrupting the resolver's internal state (`extern_prelude`) and leading to a crash in later resolution passes the fix adds an early return after the shadowing error is reported to ensure the invalid item is not added to the resolution graph.
Fixesrust-lang/rust#149821
Add proper suggestion for associated function with unknown field
Fixesrust-lang/rust#149038
The first commit is changing the old suggestion to verbose,
the second commit is a new added suggestion.
r? ``@estebank``
Update `rustc_codegen_gcc` rotate operation document
## Description
This PR resolves a TODO comment in the `rustc_codegen_gcc` backend by documenting that the rotate operations (`rotate_left` and `rotate_right`) already implement the optimized branchless algorithm from comment.
The existing implementation already uses the optimal branchless rotation pattern:
- For left rotation: `(x << n) | (x >> (-n & (width-1)))`
- For right rotation: `(x >> n) | (x << (-n & (width-1)))`
This pattern avoids branches and generates efficient machine code across different platforms, which was the goal mentioned in the original TODO.
## Changes
- Removed the TODO comment that suggested implementing the algorithm from https://blog.regehr.org/archives/1063
MGCA: Syntactically distinguish anon const const args
r? oli-obk
tracking issue: rust-lang/rust#132980
This PR requires that when `feature(min_generic_const_args)` is enabled, anon const const args are *syntactically* distinguishable from other kinds of args. We use `const { ... }` in const argument position to denote an anon const:
```rust
#![feature(min_generic_const_args)]
// no longer allowed as `1 + 1` is represented via an anon const and
// there is no syntactic marker
type Foo = [(); 1 + 1];
// allowed, `const { ... }` indicates an anon const representation
type Foo = [(); const { 1 + 1 }];
```
This restriction is only placed when mgca is enabled. There should be no effect on stable. This restriction is not enforced for unbraced literals which we continue to implicitly wrap in an anon const: `tests/ui/const-generics/mgca/explicit_anon_consts_literals_hack.rs`
This restriction allows us to create `DefId`s for anon consts only when actually required. When it is syntactically ambiguous whether a const argument is an anon const or not we are forced to conservatively create a `DefId` for every const argument even if it doesn't wind up needing one.
This works fine on stable but under `mgca` we can wind up with anon consts nested inside non-anon-const const arguments resulting in a broken `DefId` tree. See rust-lang/rust#148838 where an anon const arg inside of a path arg winds up with a parent of a conservatively created `DefId` that doesn't actually correspond to an anon const, resulting in an ICE.
With rust-lang/rust#149114 every field initialiser in a const argument would become a place where there could *possibly* be an anon const. This would also get worse once we support tuple constructors- now every function argument is a place where there could possibly be an anon const.
We introduce this restriction to avoid creating massive amounts of unused `DefId`s that make the parent tree significantly more complicated, and to avoid having to paper over this issue in things like `generics_of`.
Fixesrust-lang/rust#148838
It also must be syntactically clear from context whether `'_` means an inference lifetime or an elided lifetime parameter. This restriction will allow us to properly resolve `'_` in const arguments in mgca. This PR doesn't actually fix handle this, but we could do so trivially after this lands.
If there are too many suggestions for malformed attribute, do not suggest them
Part of https://github.com/rust-lang/rust/issues/149865.
This not only covers for doc attributes but for all attributes, so don't hesitate to tell me if you want it to be limited to only doc attributes (although I think it's actually a nice improvement overall).
Also, I picked 3 as the maximum number of suggestions before it becomes noise, but it's very much open to debate.
r? `@JonathanBrouwer`
