Remove unnecessary `get_unchecked`
My benchmarking did not show any issue with using the safe method instead so I assume this isn't an issue any more. But let's do a perf run to be sure.
Short-circuit `calculate_fallback_to_f32` when no float vars
Sharing a small fix.
When no unresolved variable is a `float_vid`, no f32 fallback can apply,
so we can skip `from_float_for_f32_root_vids` (which walks the proof tree
of every pending obligation under the new solver — O(N × M) on crates
with many large obligations).
On ReShell: stage1 wall-clock 2m35s → 1m46s (-49s, ~31%).
Context + profile breakdown will be linked at
rust-lang/trait-system-refactor-initiative#254 after this PR opens.
r? @lcnr
refactor using ExprParenthesesNeeded where possible
Found multiple instances where the equivalent of `ExprParenthesesNeeded` was done 'manually'.
Replaced them with an `ExprParenthesesNeeded::surrounding` call.
Regression test for trait-system-refactor#7
Adds a regression test for [`AliasRelate` hides info in transitive cases](https://github.com/rust-lang/trait-system-refactor-initiative/issues/7).
The example previously errored under the new solver but compiles cleanly now thanks to eager normalization (post-rust-lang/rust#119106). Verified on both the `old` and `next` revisions.
The issue body has an older TODO suggesting a goal-proving variant test; per lcnr's recent note in `#t-types/trait-system-refactor` ("this isn't an issue as we eagerly normalize"), the underlying mechanism is now resolved across both inference and goal-proving paths, so this single regression test is sufficient. Closing the upstream issue manually after merge.
r? @lcnr
std: implement `clear` via `truncate`
This gets rid of some `unsafe`. `truncate(0)` is even documented to be equivalent to `clear`, this makes that equivalence even more obvious.
Several printing functions (e.g. `short_string`) take a liftable
parameter. This commit changes the call sites to do the lifting instead.
This simplifies the type signatures and puts the `lift` calls inside
`tls::with` calls which is where they usually appear, and the minor cost
of having more `lift` call sites.
found multiple instances where the equivalent of ExprParenthesesNeeded
was done 'manually'.
replaced them with a `ExprParenthesesNeeded::surrounding` call
Add `const_param_ty_unchecked` gate
Add `const_param_ty_unchecked` internal feature gate to skip `ConstParamTy_` trait enforcement on type. Provides an escape hatch for writing tests and examples that use const generics without needing to ensure all fields implement `ConstParamTy_`.
r? BoxyUwU
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#156073 ([rustdoc] Fix `doc_cfg` feature on reexports)
- rust-lang/rust#152216 (Fix 'assign to data in an index of' collection suggestions)
- rust-lang/rust#155433 (Rip out rustc_layout_scalar_valid_range_* attribute support)
- rust-lang/rust#156098 (Hand-implement `impl Debug for NumBuffer` to avoid constraining `T` or printing MaybeUninit)
Hand-implement `impl Debug for NumBuffer` to avoid constraining `T` or printing MaybeUninit
The derived implementation requires `T: Debug`, and doesn't need to.
Fix 'assign to data in an index of' collection suggestions
fixes https://github.com/rust-lang/rust/issues/150001
fixes https://github.com/rust-lang/rust-analyzer/issues/16076
fixes https://github.com/rust-lang/rust/issues/134917
The issues are threefold and linked:
1. Assigning data to a ~~collection~~BTreeMap/HashMap suggests 3 solutions all marked as `MachineApplicable`
2. The suggestions are slightly wrong with regards to their borrowing needs.
3. The suggestions are not guaranteed to produce code that is valid, and suggestion number two is equivalent to an update, not an insertion.
This PR:
- splits the large triple suggestion into three
- sets them to `MaybeIncorrect`
- automatically determines the required borrowing to use.
I think this solution may not be very elegant, expecially the key typechecking / borrowing part, but it works. I am however very open to any improvement/change :)
edit: edited to replace 'collection' with BTreeMap/HashMap'
[rustdoc] Fix `doc_cfg` feature on reexports
Part of rust-lang/rust#150268.
I don't mark the issue as fixed as I need to check the third case described in the issue. First commit comes from https://github.com/rust-lang/rust/pull/156020, will need to rebase this PR once the original is merged.
r? @Urgau
change field `tools` on `AttributeParser` to hold `&'tcx RegisteredTools`
Makes tools actually stored, and not just tool names
this was originally part of rust-lang/rust#155691 but was split out to make that PR smaller.
r? @petrochenkov
cc @JonathanBrouwer
Remove unused spans from AttributeKind
Recently I noticed some spans in diagnostic attributes were never used. I went through and checked the other variants too.
refactor rustc_on_unimplemented's filtering
Previously when you had a
```rust
pub struct Directive {
pub is_rustc_attr: bool,
pub condition: Option<OnUnimplementedCondition>,
pub subcommands: ThinVec<Directive>,
pub message: Option<(Span, FormatString)>,
...
}
```
that condition would control the emission of the message, label, notes etc. I've changed that to
```rust
pub struct Directive {
pub is_rustc_attr: bool,
pub filters: ThinVec<(Filter, Directive)>,
pub message: Option<(Span, FormatString)>,
...
```
so that the message etc is always emitted, and there's a vec of tuples with (filter, directive) where the filter controls whether that directive is even emitted, which i think is much clearer. That also makes it easier to not have to do the reverse iteration thing and this makes it so that notes are emitted in declaration order (with nonfiltered options always last).
The rename is because I plan on making it available to other diagnostic attributes at some point (very wip) so `OnUnimplementedCondition` and the like would have to be renamed anyway.
Validate source snippet when format input is raw string
Fixesrust-lang/rust#114865
The issue occurred because the user's proc macro respanned the format arg to an unrelated multi-byte string and we ICE'd by landing in the middle of a multi-byte char.
This PR adds validation that prevents the parser from trying to walk such obviously wrong snippets. Such validation already existed for non-raw strings. This PR adds it for raw strings as well.
Guillaume Gomez