We store argument indexes on VarDebugInfo. Unlike the previous method of
relying on the variable index to know whether a variable is an argument,
this survives MIR inlining.
We also no longer check if var.source_info.scope is the outermost scope.
When a function gets inlined, the arguments to the inner function will
no longer be in the outermost scope. What we care about though is
whether they were in the outermost scope prior to inlining, which we
know by whether we assigned an argument index.
rustc_middle: Document which exactly `DefId`s don't have `DefKind`s
I don't currently have time to investigate when and how to create these missing HIR nodes, but if someone else could do that it would be great.
Clear with drain
Fixes#10572: both the original intent of the issue (extending `clear_with_drain`) and the false negative for `collection_is_never_read` I found in the process are fixed by this PR.
changelog: [`clear_with_drain`]: extend to 5 other types of containers. [`collection_is_never_read`]: fix false negative for `String`s.
This functionality is already tested in `hash-item-expansion.goml`,
and was implemented twice:
* First, in code that ran at load time and at hash change:
917cdd295d
* Later, the hash change event handler was itself run at load time,
and the code handling both cases diverged in implementation,
though their behavior still matches pretty well:
f66a331335
Add suggestion to remove `derive()` if invoked macro is non-derive
Adds to the existing `expected derive macro, found {}` error message:
```
help: remove the surrounding "derive()":
--> $DIR/macro-path-prelude-fail-4.rs:1:3
|
LL | #[derive(inline)]
| ^^^^^^^ ^
```
This suggestion will either fix the issue, in the case that the macro was valid, or provide a better error message if not
Not ready for merge yet, as the highlighted span is only valid for trivial formatting. Is there a nice way to get the parent span of the macro path within `smart_resolve_macro_path`?
Closes#109589
These builders aren't particularly high on overall average CPU usage and finish in typically around
30 minutes. Cutting their core counts will hopefully not significantly increase wall-time while
cutting costs, allowing us to shift some of the wins into our slower builders.
Improve the floating point parser in dec2flt.
Greetings everyone,
I've benn studying the rust floating point parser recently and made the following tweaks:
* Remove all remaining traces of `unsafe`. The parser is now 100% safe Rust.
* The trick in which eight digits are processed in parallel is now in a loop.
* Parsing of inf/NaN values has been reworked.
On my system, the changes result in performance improvements for some input values.
remove unusued `#![feature(drain_filter)]`
The unstable feature does not appear to be used and its presence blocks work in https://github.com/rust-lang/rust/pull/104455
changelog: none
The panic test is now counted as an error test; we encounter a Terminate
terminator, and emit an interpreter error, as opposed to just
terminating due to a panic. So this test should have broken with
https://github.com/rust-lang/rust/pull/102906 but wasn't because the Miri
test suite is currently broken in rust-lang/rust:
https://github.com/rust-lang/rust/issues/110102
Rollup of 6 pull requests
Successful merges:
- #109724 (prioritize param env candidates if they don't guide type inference)
- #110021 (Fix a couple ICEs in the new `CastKind::Transmute` code)
- #110044 (Avoid some manual slice length calculation)
- #110115 (compiletest: Use remap-path-prefix only in CI)
- #110121 (Fix `x check --stage 1` when download-rustc is enabled)
- #110124 (Some clippy fixes in the compiler)
Failed merges:
- #109752 (Stall auto trait assembly in new solver for int/float vars)
r? `@ghost`
`@rustbot` modify labels: rollup
compiletest: Use remap-path-prefix only in CI
This makes jump-to-definition work in most IDEs, as well as being easier to understand for contributors.
Fixes https://github.com/rust-lang/rust/issues/109725. cc `@TimNN`
Fix a couple ICEs in the new `CastKind::Transmute` code
Check the sizes of the immediates, rather than the overall types, when deciding whether we can convert types without going through memory.
Fixes#110005Fixes#109992Fixes#110032
cc `@matthiaskrgr`
prioritize param env candidates if they don't guide type inference
intended to supersede #109579. We disable the prioritization during coherence to maintain completeness.
Long term we can hopefully replace this hack with adding OR to external constraints at which point the only relevant part when merging responses is whether they guide type inference in the same way.
Reuses `try_merge_responses` for assembly and the cleanest way to impl that was to actually split that so that `try_merge_responses` returns `None` if we fail to merge them and then add `flounder` which is used afterwards which is allowed to lower the certainty of our responses.
If, in the future, we add the ability to merge candidates `YES: ?0 = Vec<u32>` and `YES: ?0 = Vec<i32>` to `AMBIG: ?0 = Vec<?1>`, this should happen in `flounder`.
r? `@compiler-errors` `@BoxyUwU`
