Select obligations before processing wf obligation in `compare_method_predicate_entailment`
We need to select obligations before processing the WF obligation for the `IMPLIED_BOUNDS_ENTAILMENT` lint, since it skips over type variables.
Fixes#114783
r? `@jackh726`
TAITs do not constrain generic params
Fixes#108425
Not sure if I should rework those two failing tests. I guess `tests/ui/type-alias-impl-trait/coherence.rs` could just have the type parameter removed from it? IDK what `tests/ui/type-alias-impl-trait/coherence_generalization.rs` is even testing, though.
r? `@aliemjay`
cc `@lcnr` `@oli-obk` (when he's back from 🌴)
coverage: Store BCB counter info externally, not directly in the BCB graph
When deciding how to instrument the underlying MIR for coverage, the `InstrumentCoverage` pass builds a simplified “Basic Counter Block” graph, and then allocates coverage counters/expressions to various nodes/edges in the BCB graph as necessary. Those counters/expressions are then injected into the function's MIR.
The awkward thing here is that the code for doing this needs `&mut` access to the graph, in order to associate coverage info with individual nodes, even though it isn't making any structural changes to the graph itself. That makes it harder to understand and modify the instrumentation code.
In addition, the graph alone can't hold all the information that is needed. There ends up being an extra vector of “intermediate expressions” that needs to be passed around separately anyway.
---
This PR simplifies things by instead storing all of that temporary coverage information in a number of side-tables inside `CoverageCounters`.
This makes it easier to see all of the information produced by the make-counters step, and how it is used by the inject-into-mir step.
---
Looking at the combined changes is possible, but I recommend reviewing the commits individually, because the big changes are mostly independent of each other (despite being conceptually related).
Extract a create_wrapper_function for use in allocator shim writing
This deduplicates some logic and makes it easier to follow what wrappers are produced. In the future it may allow moving the code to determine which wrappers to create to cg_ssa.
All of them are not exported from rustc_interface and used only during
global_ctxt(). Inlining them makes it easier to follow the order of
queries and slightly reduces line count.
Also consider `mem::transmute` with the `invalid_reference_casting` lint
This PR extend the `invalid_reference_casting` lint with regard to the `std::mem::transmute` function.
```
error: casting `&T` to `&mut T` is undefined behavior, even if the reference is unused, consider instead using an `UnsafeCell`
--> $DIR/reference_casting.rs:27:16
|
LL | let _num = &mut *std::mem::transmute::<_, *mut i32>(&num);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
*I encourage anyone reviewing this PR to do so [without whitespaces](https://github.blog/2011-10-21-github-secrets/#whitespace).*
rustc: Move `features` from `Session` to `GlobalCtxt`
Removes one more piece of mutable state.
Follow up to #114622.
The rule I used for passing feature in function signatures:
- if a crate already depends on `rustc_middle`, then `Session` is replaced with `TyCtxt`
- otherwise session and features are passed as a pair `sess: &Session, features: &Features`
The code in `rustc_lint` is ultimately used for implementing a trait from `rustc_expand`, so it also doesn't use tcx despite the dependency on `rustc_middle`.
normalize in `trait_ref_is_knowable` in new solver
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/51
Alternatively we could avoid normalizing the self type and do this at the end of the `assemble_candidates_via_self_ty` stack by splitting candidates into:
- applicable without normalizing self type
- applicable for aliases, even if they can be normalized
- applicable for stuff which cannot get normalized further
I don't think this would have any significant benefits and it also seems non-trivial to avoid normalizing only the self type in `trait_ref_is_knowable`.
r? `@compiler-errors`
Storing coverage counter information in `CoverageCounters` has a few advantages
over storing it directly inside BCB graph nodes:
- The graph doesn't need to be mutable when making the counters, making it
easier to see that the graph itself is not modified during this step.
- All of the counter data is clearly visible in one place.
- It becomes possible to use a representation that doesn't correspond 1:1 to
graph nodes, e.g. storing all the edge counters in a single hashmap instead of
several.
remove builtin `Copy` and `Clone` impl for float and int infer
it's only change is whether `{integer}: Copy` is ambiguous, this has the following properties
- these goals get proven earlier, potentially resulting in slightly better perf
- it causes inconsistent behavior and ICE if there do not exist impls for all integers, causing issues when using `#[no_core]`
- it means `Clone` has user-facing differences from other traits from `core` with the new solver because it can potentially guide inference there
- it's just very sus™ to have a builtin impl which applies during type inference but not afterwards
Rollup of 7 pull requests
Successful merges:
- #94455 (Partially stabilize `int_roundings`)
- #114132 (Better Debug for Vars and VarsOs)
- #114584 (E0277 nolonger points at phantom `.await`)
- #114667 (Record binder for bare trait object in LifetimeCollectVisitor)
- #114692 (downgrade `internal_features` to warn)
- #114703 (Cover ParamConst in smir)
- #114734 (Mark oli as "on vacation")
r? `@ghost`
`@rustbot` modify labels: rollup
Respect `#[expect]` the same way `#[allow]` is with the `dead_code` lint
This PR makes the `#[expect]` attribute being respected in the same way the `#[allow]` attribute is with the `dead_code` lint.
The fix is much more involved than I would have liked (and it's not because I didn't tried!), because the implementation took advantage of the fact that firing a lint in a allow context is a nop (for the user, as the lint is suppressed) to not fire-it at all.
And will it's fine for `#[allow]`, it definitively isn't for `#[expect]`, as the presence and absence of the lint is significant. So a big part of the PR is just adding the context information of whenever an item is on the worklist because of an `[allow]`/`#[expect]` or not.
Fixes https://github.com/rust-lang/rust/issues/114557
downgrade `internal_features` to warn
Not sure if this requires an FCP or whatever. By having the lint as deny I need to modify test cases when testing them outside of the test suite as the test suite implicitly allows the lint. This takes maybe 10 to 20 seconds per test, but given just how frequently I end up copying tests to different repos it's a significant annoyance.
r? `@Nilstrieb`
make `typeid::typeid_itanium_cxx_abi::transform_ty` evaluate length in array types
the ICE in https://github.com/rust-lang/rust/issues/114275 was caused by `transform_ty`
in compiler/rustc_symbol_mangling/src/typeid/typeid_itanium_cxx_abi.rs encountering an unevaluated const, while expecting it to already be evaluated.
