| Age | Commit message (Collapse) | Author | Lines |
|
r=compiler-errors
Refactor: remove unnecessary string searchings
This patch removes unnecessary string searchings for checking if function arguments have `&` and `&mut`.
|
|
TaKO8Ki:suggest-adding-reference-to-trait-assoc-item, r=cjgillot
Suggest adding a reference to a trait assoc item
fixes #100289
|
|
|
|
remove unnecessary string searchings for checking if function arguments have `&` and `&mut`
|
|
|
|
|
|
|
|
|
|
Revert "Rollup merge of #97346 - JohnTitor:remove-back-compat-hacks, …
…r=oli-obk"
This reverts commit c703d11dccb4a895c7aead3b2fcd8cea8c483184, reversing
changes made to 64eb9ab869bc3f9ef3645302fbf22e706eea16cf.
it didn't apply cleanly, so now it works the same for RPIT and for TAIT instead of just working for RPIT, but we should keep those in sync anyway. It also exposed a TAIT bug (see the feature gated test that now ICEs).
r? `@pnkfelix`
fixes #99536
|
|
|
|
|
|
|
|
|
|
Delay span bug when failing to normalize negative coherence impl subject due to other malformed impls
Fixes #100191
r? ``@spastorino``
|
|
|
|
orphan check: rationalize our handling of constants
cc `@rust-lang/types` `@rust-lang/project-const-generics` on whether you agree with this reasoning.
r? types
|
|
to other malformed impls
|
|
|
|
|
|
|
|
Keep going if normalized projection has unevaluated consts in `QueryNormalizer`
#100312 was the wrong approach, I think this is the right one.
When normalizing a type, if we see that it's a projection, we currently defer to `tcx.normalize_projection_ty`, which normalizes the projections away but doesn't touch the unevaluated constants. So now we just continue to fold the type if it has unevaluated constants so we make sure to evaluate those too, if we can.
Fixes #100217
Fixes #83972
Fixes #84669
Fixes #86710
Fixes #82268
Fixes #73298
|
|
|
|
consider unnormalized types for implied bounds
extracted, and slightly modified, from #98900
The idea here is that generally, rustc is split into things which can assume its inputs are well formed[^1], and things which have verify that themselves.
Generally most predicates should only deal with well formed inputs, e.g. a `&'a &'b (): Trait` predicate should be able to assume that `'b: 'a` holds. Normalization can loosen wf requirements (see #91068) and must therefore not be used in places which still have to check well formedness. The only such place should hopefully be `WellFormed` predicates
fixes #87748 and #98543
r? `@jackh726` cc `@rust-lang/types`
[^1]: These places may still encounter non-wf inputs and have to deal with them without causing an ICE as we may check for well formedness out of order.
|
|
r=lcnr,notriddle,camelid
Don't document impossible to call default trait items on impls
Closes #100176
This only skips documenting _default_ trait items on impls, not ones that are written inside the impl block. This is a conservative approach, since I think we should document all items written in an impl block (I guess unless hidden or whatever), but the existence of this new query I added makes this easy to extend to other rustdoc cases.
|
|
this allows us to soundly use unnormalized projections for wf
|
|
|
|
|
|
|
|
|
|
|
|
Some `FulfillmentContext`-related cleanups
Use `ObligationCtxt` in some places, remove some `FulfillmentContext`s in others...
r? types
|
|
More EarlyBinder cleanups
Each commit is independent
r? types
|
|
|
|
It spawns up a trait engine, registers the single obligation, then fully
solves it
|
|
|
|
need_migrate_deref_output_trait_object
|
|
|
|
compiler-errors:delay-specialization-normalize-error, r=spastorino
Delay a bug when failed to normalize trait ref during specialization
The error messages still kinda suck here but they don't ICE anymore...
Fixes #45814
Fixes #43037
r? types
|
|
Use `TraitEngine` in more places that don't specifically need `FulfillmentContext::new_in_snapshot`
Not sure if this change is worthwhile, but couldn't hurt re: chalkification
r? types
|
|
|
|
|
|
|
|
remove `commit_unconditionally`
`commit_unconditionally` is a noop unless we somehow inspect the current state of our snapshot. The only thing which does that is the leak check which was only used in one place where `commit_if_ok` is probably at least as, or even more, correct.
r? rust-lang/types
|
|
|
|
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.
|
|
Rollup of 7 pull requests
Successful merges:
- #99987 (Always include a position span in `rustc_parse_format::Argument`)
- #100005 (Remove Clean trait for ast::Attribute and improve Attributes::from_ast)
- #100025 (Remove redundant `TransferWrapper` struct)
- #100045 (Properly reject the `may_unwind` option in `global_asm!`)
- #100052 (RISC-V ASM test: relax label name constraint.)
- #100053 (move [`assertions_on_result_states`] to restriction)
- #100057 (Remove more Clean trait implementations)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Always include a position span in `rustc_parse_format::Argument`
Moves the spans from the `Position` enum to always be included in the `Argument` struct. Doesn't make any changes to use it in rustc, but it will be useful for some upcoming Clippy lints
|
|
make `PlaceholderConst` not store the type of the const
Currently the `Placeholder` variant on `ConstKind` is 28 bytes when with this PR its 8 bytes, i am not sure this is really useful at all rn since `Unevaluated` and `Value` variants are huge still but eventually it should be possible to get both down to 16 bytes :thinking:. Mostly opening this to see if this change has any perf impact when done before it can make `ConstKind`/`ConstS` smaller
|
|
`codegen_fulfill_obligation` expect erased regions
it's a query, so by erasing regions before calling it, we get better caching.
This doesn't actually change anything as its already the status quo.
|
|
|