| Age | Commit message (Collapse) | Author | Lines |
|
minor changes to make method lookup diagnostic code easier to read
The end result of around 4 days of trying to understand this 1000+ line long function- a bunch of tiny nitpicks
r? `@compiler-errors`
|
|
Improve use of ErrorGuaranteed and code cleanup
Part of #103874
|
|
|
|
|
|
|
|
This reverts commit a6b5f95fb028f9feb4a2957c06b35035be2c6155.
|
|
|
|
|
|
Remove tuple candidate, nothing special about it
r? `@lcnr` you mentioned this during the talk you gave i think
|
|
|
|
|
|
|
|
fee1-dead-contrib:const_trait_impl-assoc-caller-bounds, r=oli-obk
make projection bounds with const bounds satisfy const
Fixes #101982.
|
|
|
|
|
|
|
|
This reverts commit c75817b0a75d4b6b01ee10900ba5d01d4915e6a8.
|
|
|
|
Deny return-position `impl Trait` in traits for object safety
Fixes #101667
|
|
Implement `std::marker::Tuple`
Split out from #99943 (https://github.com/rust-lang/rust/pull/99943#pullrequestreview-1064459183).
Implements part of rust-lang/compiler-team#537
r? `@jackh726`
|
|
|
|
|
|
|
|
|
|
|
|
This PR will fix some typos detected by [typos].
I only picked the ones I was sure were spelling errors to fix, mostly in
the comments.
[typos]: https://github.com/crate-ci/typos
|
|
|
|
|
|
|
|
|
|
Initial implementation of transmutability trait.
*T'was the night before Christmas and all through the codebase, not a miri was stirring — no hint of `unsafe`!*
This PR provides an initial, **incomplete** implementation of *[MCP 411: Lang Item for Transmutability](https://github.com/rust-lang/compiler-team/issues/411)*. The `core::mem::BikeshedIntrinsicFrom` trait provided by this PR is implemented on-the-fly by the compiler for types `Src` and `Dst` when the bits of all possible values of type `Src` are safely reinterpretable as a value of type `Dst`.
What this PR provides is:
- [x] [support for transmutations involving primitives](https://github.com/jswrenn/rust/tree/transmute/src/test/ui/transmutability/primitives)
- [x] [support for transmutations involving arrays](https://github.com/jswrenn/rust/tree/transmute/src/test/ui/transmutability/arrays)
- [x] [support for transmutations involving structs](https://github.com/jswrenn/rust/tree/transmute/src/test/ui/transmutability/structs)
- [x] [support for transmutations involving enums](https://github.com/jswrenn/rust/tree/transmute/src/test/ui/transmutability/enums)
- [x] [support for transmutations involving unions](https://github.com/jswrenn/rust/tree/transmute/src/test/ui/transmutability/unions)
- [x] [support for weaker validity checks](https://github.com/jswrenn/rust/blob/transmute/src/test/ui/transmutability/unions/should_permit_intersecting_if_validity_is_assumed.rs) (i.e., `Assume::VALIDITY`)
- [x] visibility checking
What isn't yet implemented:
- [ ] transmutability options passed using the `Assume` struct
- [ ] [support for references](https://github.com/jswrenn/rust/blob/transmute/src/test/ui/transmutability/references.rs)
- [ ] smarter error messages
These features will be implemented in future PRs.
|
|
|
|
|
|
This initial implementation handles transmutations between types with specified layouts, except when references are involved.
Co-authored-by: Igor null <m1el.2027@gmail.com>
|
|
|
|
|
|
|
|
|
|
Revert "Highlight conflicting param-env candidates"
This reverts #98794, commit 08135254dcf22be0d5661ea8f75e703b29a83514.
Seems to have caused an incremental compilation bug. The root cause of the incr comp bug is somewhat unrelated but is triggered by this PR, so I don't feel comfortable with having this PR in the codebase until it can be investigated further. Fixes #99233.
|
|
trait obligations for binops.
|
|
This reverts commit 08135254dcf22be0d5661ea8f75e703b29a83514.
|
|
|
|
|
|
|
|
don't succeed `evaluate_obligation` query if new opaque types were registered
fixes #98608
fixes #98604
The root cause of all this is that in type flag computation we entirely ignore nongeneric things like struct fields and the signature of function items. So if a flag had to be set for a struct if it is set for a field, that will only happen if the field is generic, as only the generic parameters are checked.
I now believe we cannot use type flags to handle opaque types. They seem like the wrong tool for this.
Instead, this PR replaces the previous logic by adding a new variant of `EvaluatedToOk`: `EvaluatedToOkModuloOpaqueTypes`, which says that there were some opaque types that got hidden types bound, but that binding may not have been legal (because we don't know if the opaque type was in its defining scope or not).
|
|
|
|
sure we don't accidentally mark something as ok-modulo-regions if there are opaque types involved
|
|
|
|
|
|
|