never patterns: lower never patterns to `Unreachable` in MIR
This lowers a `!` pattern to "goto Unreachable". Ideally I'd like to read from the place to make it clear that the UB is coming from an invalid value, but that's tricky so I'm leaving it for later.
r? `@compiler-errors` how do you feel about a lil bit of MIR lowering
Implement lldb formatter for "clang encoded" enums (LLDB 18.1+) (V3)
This is a redo of PR (#124458) which was approved previously but force-pushed out. Then a V2 (#124745) failed `debuginfo\msvc-pretty-enums.rs` test during merge.
I've fixed the test and checked it to pass on Windows with `.\x.ps1 test .\tests\debuginfo\msvc-pretty-enums.rs`
Below is the original summary:
## Summary:
fixes#79530
I landed a fix last year to enable `DW_TAG_variant_part` encoding in LLDBs (https://reviews.llvm.org/D149213). This PR is a corresponding fix in synthetic formatters to decode that information.
This is in no way perfect implementation but at least it improves the status quo. But most types of enums will be visible and debuggable in some way.
I've also updated most of the existing tests that touch enums and re-enabled test cases based on LLDB for enums.
## Test Plan:
ran tests `./x test tests/debuginfo/`. Also tested manually in LLDB CLI and LLDB VSCode
## Other Thoughs:
A better approach would probably be adopting [formatters from codelldb](https://github.com/vadimcn/codelldb/blob/master/formatters/rust.py). There is some neat hack that hooks up summary provider via synthetic provider which can ultimately fix more display issues for Rust types and enums too. But getting it to work well might take more time that I have right now.
Adjust dbg.value/dbg.declare checks for LLVM update
https://github.com/llvm/llvm-project/pull/89799 changes llvm.dbg.value/declare intrinsics to be in a different, out-of-instruction-line representation. For example
call void `@llvm.dbg.declare(...)`
becomes
#dbg_declare(...)
Update tests accordingly to work with both the old and new way.
https://github.com/llvm/llvm-project/pull/89799 changes llvm.dbg.value/declare intrinsics to be in a different, out-of-instruction-line representation. For example
call void @llvm.dbg.declare(...)
becomes
#dbg_declare(...)
Update tests accordingly to work with both the old and new way.
borrowck: prepopulate opaque storage more eagerly
otherwise we ICE due to ambiguity when normalizing while computing implied bounds.
r? ``@compiler-errors``
Record impl args in the proof tree in new solver
Rather than rematching them during select.
Also use `ImplSource::Param` instead of `ImplSource::Builtin` for alias-bound candidates, so we don't ICE in `Instance::resolve`.
r? lcnr
Rollup of 4 pull requests
Successful merges:
- #124520 (Document that `create_dir_all` calls `mkdir`/`CreateDirW` multiple times)
- #124724 (Prefer lower vtable candidates in select in new solver)
- #124771 (Don't consider candidates with no failing where clauses when refining obligation causes in new solver)
- #124808 (Use `super_fold` in `RegionsToStatic` visitor)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't consider candidates with no failing where clauses when refining obligation causes in new solver
Improves error messages when we have param-env candidates that don't deeply unify (i.e. after alias-bounds).
r? lcnr
Prefer lower vtable candidates in select in new solver
Also, adjust the select visitor to only winnow when the *parent* goal is `Certainty::Yes`. This means that we won't winnow in cases when we have any ambiguous inference guidance from two candidates.
r? lcnr
Add constants for f16 and f128
- Commit 1 adds associated constants for `f16`, excluding NaN and infinities as these are implemented using arithmetic for `f32` and `f64`.
- Commit 2 adds associated constants for `f128`, excluding NaN and infinities.
- Commit 3 adds constants in `std::f16::consts`.
- Commit 4 adds constants in `std::f128::consts`.
Migrate `run-make/rustdoc-error-lines` to new `rmake.rs`
Part of https://github.com/rust-lang/rust/issues/121876.
There was a weird naming inconsistency with `input`/`output`. A few tests write `.arg("-o").arg(path)` and the `output` method was actually the command output. So instead, I renamed the original `output` into `command_output` so that I could create the `output` method with the expected effect (and updated the tests to use it too).
EDIT: The first two commits come from https://github.com/rust-lang/rust/pull/124711. Some weird things happened recently pparently. ^^'
r? `@jieyouxu`
Casting to `*const ()` or `*mut ()` just bloats the MIR, so let's not.
If ACP#362 goes through we can keep calling `ptr::from_raw_parts(_mut)` in these also without the cast, but that hasn't had any libs-api attention yet, so I'm not waiting on it.
Improve check-cfg CLI errors with more structured diagnostics
This PR improve check-cfg CLI errors with more structured diagnostics.
In particular it now shows the statement where the error occurred, what kind lit it is, as well as pointing users to the doc for more details.
`@rustbot` label +F-check-cfg
Summary:
I landed a fix last year to enable `DW_TAG_variant_part` encoding in LLDBs (https://reviews.llvm.org/D149213). This PR is a corresponding fix in synthetic formatters to decode that information.
This is in no way perfect implementation but at least it improves the status quo. But most types of enums will be visible and debuggable in some way.
I've also updated most of the existing tests that touch enums and re-enabled test cases based on LLDB for enums.
Test Plan:
ran tests `./x test tests/debuginfo/`. Also tested manually in LLDB CLI and LLDB VSCode
Other Thoughs
A better approach would probably be adopting [formatters from codelldb](https://github.com/vadimcn/codelldb/blob/master/formatters/rust.py). There is some neat hack that hooks up summary provider via synthetic provider which can ultimately fix more display issues for Rust types and enums too. But getting it to work well might take more time that I have right now.
This change constructs the search form HTML using JavaScript, instead of plain HTML. It uses a custom element because
- the [parser]'s insert algorithm runs the connected callback synchronously, so we won't get layout jank
- it requires very little HTML, so it's a real win in size
[parser]: https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token
This shrinks the standard library by about 60MiB, by my test.
Rollup of 6 pull requests
Successful merges:
- #124148 (rustdoc-search: search for references)
- #124668 (Fix bootstrap panic when build from tarball)
- #124736 (compiler: upgrade time from 0.3.34 to 0.3.36)
- #124748 (Fix unwinding on 32-bit watchOS ARM (v2))
- #124749 (Stabilize exclusive_range_pattern (v2))
- #124750 (Document That `f16` And `f128` Hardware Support is Limited (v2))
r? `@ghost`
`@rustbot` modify labels: rollup
Remove suggestion about iteration count in coerce
Fixes#122561
The iteration count-centric suggestion was implemented in PR #100094, but it was based on the wrong assumption that the type mismatch error depends on the number of times the loop iterates. As it turns out, that is not true (see this comment for details: https://github.com/rust-lang/rust/pull/122679#issuecomment-2017432531)
This PR attempts to remedy the situation by changing the suggestion from the one centered on iteration count to a simple suggestion to add a return value.
It should also fix#100285 by simply making it redundant.
Implement `do_not_recommend` in the new solver
Put the test into `diagnostic_namespace` test folder even though it's not in the diagnostic namespace, because it should be soon.
r? lcnr
cc `@weiznich`
Update Cargo specific diagnostics in check-cfg
This PR updates the Cargo specific diagnostics for check-cfg/`unexpected_cfgs` lint.
Specifically it update to new url and use the double-column (instead of one) in the Cargo directive suggestion.
`@rustbot` label +F-check-cfg
cc `@weihanglo`
