Remove `body_def_id` from `Inherited`
We can just use the body id from the obligation cause.
Follow-up to #108945, only my commit is relevant.
r? `@cjgillot` cc `@spastorino`
Document the resulting values produced when using `From<bool>` on floats
Have the documentation of the implementation of `From<bool>` on `f32` and `f64` indicate the output values (`0.0` for `false` and `1.0` for `true`).
closes#108939
Unconstrained terms should account for infer vars being equated
Follow-up from the canonicalization PR, wanted to break this one out so I can approve the other PR.
r? `@lcnr`
Rollup of 8 pull requests
Successful merges:
- #106915 (Only load one CSS theme by default)
- #108294 (Place binder correctly for arbitrary trait bound suggestion)
- #108778 (x fmt: Don't print all modified files if there's more than 10)
- #108854 (feat/refactor: improve errors in case of ident with number at start)
- #108870 (Fix invalid inlining of reexport of reexport of private item)
- #108917 (Consider target_family as pal)
- #108922 (Add auto notification for changes to stable mir)
- #108929 (Fix typo in span_map.rs)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add auto notification for changes to stable mir
Adds a new entry to the triagebot configuration file to notify subscribers about changes to the stable MIR. I added myself and `@oli-obk` for now.
r?oli-obk
Consider target_family as pal
Currently, tidy does not consider code in target_family as platform-specific. This is erroneous and should be fixed.
r? `@workingjubilee`
Fix invalid inlining of reexport of reexport of private item
Fixes https://github.com/rust-lang/rust/issues/108679.
The problem is that a reexport is always resolving to the end type, so if the end type is private, the reexport inlines. Except that if you reexport a public reexport (which reexports the private item), then it should not be inlined again.
r? `@notriddle`
feat/refactor: improve errors in case of ident with number at start
Improve parser code when we parse a integer (or float) literal but expect an identifier. We emit an error message saying that identifiers can't begin with numbers. This PR just improves that code and expands it to all identifiers. Note that I haven't implemented error recovery (this didn't exist before anyway), I might do that in a follow up PR.
Rollup of 8 pull requests
Successful merges:
- #108754 (Retry `pred_known_to_hold_modulo_regions` with fulfillment if ambiguous)
- #108759 (1.41.1 supported 32-bit Apple targets)
- #108839 (Canonicalize root var when making response from new solver)
- #108856 (Remove DropAndReplace terminator)
- #108882 (Tweak E0740)
- #108898 (Set `LIBC_CHECK_CFG=1` when building Rust code in bootstrap)
- #108911 (Improve rustdoc-gui/tester.js code a bit)
- #108916 (Remove an unused return value in `rustc_hir_typeck`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Do not consider `&mut *x` as mutating `x` in `CopyProp`
This PR removes an unfortunate overly cautious case from the current implementation.
Found by https://github.com/rust-lang/rust/pull/105274 cc `@saethlin`
Set `LIBC_CHECK_CFG=1` when building Rust code in bootstrap
Downstream forks of the Rust compiler might want to use a custom `libc` to add support for targets that are not yet available upstream. Adding a patch to replace `libc` with a custom one would cause compilation errors though, because Cargo would interpret the custom `libc` as part of the workspace, and apply the check-cfg lints on it.
Since https://github.com/rust-lang/libc/pull/3037, the `libc` build script emits check-cfg flags only when the `LIBC_CHECK_CFG` environment variable is set, so this PR allows the use of custom `libc`s.
Canonicalize root var when making response from new solver
During trait solving, if we equate two inference variables `?0` and `?1` but don't equate them with any rigid types, then `InferCtxt::probe_ty_var` will return `Err` for both of these. The canonicalizer code will then canonicalize the variables independently(!), and the response will not reflect the fact that these two variables have been made equal.
This hinders inference and I also don't think it's sound? I haven't thought too much about it past that, so let's talk about it.
r? ``@lcnr``
Retry `pred_known_to_hold_modulo_regions` with fulfillment if ambiguous
Fixes#108721
The problem here is that when we're checking `is_sized_raw` during codegen on some type that has a lot of opaques in it, something emits several nested obligations that are individually ambiguous, but when processed together in a loop then apply modulo regions. Since the `evaluate_predicates_recursively` inner loop doesn't process predicates until they stop changing, we return `EvaluatedToAmbig`, which makes the sized check return false incorrectly. See:
f15f0ea739/compiler/rustc_trait_selection/src/traits/select/mod.rs (L596-L606)
... Compared to the analogous loop in the new solver:
f15f0ea739/compiler/rustc_trait_selection/src/solve/mod.rs (L481-L512)
To fix this, if we get ambiguous during `pred_known_to_hold_modulo_regions`, just retry the obligation in a fulfillment context.
--
Unfortunately... I don't have a test for this. I've only tested this locally. Pending minimization :/
r? types
Rename `MapInPlace` as `FlatMapInPlace`.
After removing the `map_in_place` method, which isn't much use because modifying every element in a collection such as a `Vec` can be done trivially with iteration.
r? ``@lqd``
