change the type of the argument of `drop_in_place` lang item to `&mut _`
We used to special case `core::ptr::drop_in_place` when computing LLVM argument attributes with this hack:
https://github.com/rust-lang/rust/blob/db5e2dc248fe5bb26f70d7baec46a3bca9fa3e1d/compiler/rustc_ty_utils/src/abi.rs#L383-L392
This is because even though `drop_in_place` takes a `*mut T` it is semantically a `&mut T` (remember how `&mut Self` is passed to `Drop::drop`). This is apparently relevant for perf.
This PR replaces this hack with a simpler solution -- it makes `drop_in_place` a thin wrapper around newly added `core::ptr::drop_glue`, which is the actual lang item and takes a `&mut T`:
https://github.com/rust-lang/rust/blob/d2563d5003bbecff1efc40c1f5673ceec603825b/library/core/src/ptr/mod.rs#L810-L833
------
The rest of the PR is blessing tests and cleaning up things which are not necessary after this change.
One thing that is a bit awkward is that now that `drop_glue` is the actual lang item, a lot of the comments referring to `drop_in_place` are outdated. Should I try fixing that?
I've also changed `async_drop_in_place` to take a `&mut T`, and it simplified the code handling it a bit. (since it's unstable we don't need to introduce a wrapper)
-------
cc @RalfJung
Closes https://github.com/rust-lang/rust/issues/154274
tests/ui: allow spaces in hashbrown src normalization
If one's home directory contains a space, the default location for the hashbrown source location also contains a space, and so the UI test normalization in issue-21763 fails to normalize as expected.
While this new regex does not handle all valid paths, such as those beginning with `\\?\` or `\\name\`, this handles most absolute UNIX and Windows paths. Relative paths don't seem to be applicable.
Don't return dummy MacroData in `get_macro`
I was experimenting with tool attributes and ast manipulation, and wasted some time figuring out that this was happening. AFAIK all users of `get_macro` are expecting an actual macro (and none were reading the dummy MacroData) so there should be no change in behavior.
Improve caching by introducing `TypingMode::ErasedNotCoherence`
r? @lcnr
This introduces `TypingMode::ErasedNotCoherence`. Most typing modes contain a list of opaque types, which are quite often unused during canonicalization. With this change, any time we try canonicalization, we replace whichever typing mode we're currently in with `ErasedNotcoherence`, attempt to canonicalize, and if that fails *retry* in the original typing mode. If erased mode succeeds, this is beneficial because that way the opaque types don't end up in the cache key, allowing more cache reuse.
This seems to have a small (0.5%) slowdown on most programs, but a dramatic (>60%) speedup in specific cases like the rustc-perf `wg-grammar` benchmark. Some more improvements are expected with "eager normalization", which is work that's under way right now.
add known-bug test for coroutine 'static-yields-non-'static unsoundness (#144442)
Add a `known-bug` regression test for [#144442 ("Unsoundness due to 'static coroutines that yield non-'static values").](https://github.com/rust-lang/rust/issues/144442)
Existing known-bug tests:
```
- tests/ui/closures/static-closures-with-nonstatic-return.rs
- tests/ui/implied-bounds/dyn-erasure-tait.rs
- tests/ui/implied-bounds/dyn-erasure-no-tait.rs
```
Verified in Darwin: running the compiled binary segfaults on current main, so the bug is still present.
Always use `ConstFn` context for `const` closures
fixesrust-lang/rust#155803
Since https://github.com/rust-lang/rust/commit/e8a46117795f82f35e2f4087516a8743e28ba174, `hir_body_const_context()` returned the parent's const context for a `const` closure. But a `const` closure can escape its enclosing body via a `fn`-pointer-typed const item or an opaque return type and be invoked at runtime, so it must be const-checked under the most restrictive `ConstFn` context like a regular `const fn`.
r? oli-obk (since you authored the commit mentioned above, feel free to reroll)
generic_const_args: allow paths to non type consts
tracking issue: https://github.com/rust-lang/rust/issues/151972
Non type consts should be usable in the type system in `feature(generic_const_args)`. These are directly plugged into the constant evaluator, unlike type consts, which are attempted to be reasoned about by the type system.
Inherent associated constants are not supported at this time, due to complications around how generic arguments are represented for them (it's currently a mess). The mess is being cleaned up (e.g. https://github.com/rust-lang/rust/pull/154758), so instead of trying to hack support in before the refactoring is done, let's just wait to be able to implement it more cleanly.
r? @BoxyUwU
fix: more descriptive error message for enum to integer
Fixesrust-lang/rust#151116
A more descriptive error message when casting an enum to an Integer. Please review issue linked above.
If one's home directory contains a space, the default location for the
hashbrown source location also contains a space, and so the UI test
normalization in issue-21763 fails to normalize as expected.
While this new regex does not handle all valid paths, such as those
beginning with `\\?\` or `\\name\`, this handles most absolute UNIX and
Windows paths. Relative paths don't seem to be applicable.
tests: mark import UI tests as check-pass
These import and extern-prelude UI tests only exercise checking behavior, so they do not need codegen or linking.
Mark them as check-pass and remove the old FIXME(62277) markers.
Add a `doc_cfg` regression test to ensure foreign types impls are working as expected
Fixes https://github.com/rust-lang/rust/issues/150268.
This is the last case mentioned in the issue that wasn't tested. With this, the issue can be closed.
r? @Urgau
Relax `T: Sized` bound on `try_as_dyn` / `try_as_dyn_mut`
`trait_info_of` already returns `None` for unsized types, so allowing `T: ?Sized` is sound and lets callers in generic contexts use these functions without a separate `Sized` bound. For unsized `T`, the function always returns `None`.
Tracking issue: rust-lang/rust#144361
## Motivation
Currently, it is not possible to use `try_as_dyn` as "specialization-like" dispatch in
blanket impls with `?Sized` type.
```rust
// Cannot add ?Sized now.
impl<T: 'static /* + ?Sized */, S: Serializer + 'static> Serialize<S> for T {
fn serialize(&self, serializer: &mut S) -> Result<S::Ok, S::Error> {
if let Some(spec) = try_as_dyn::<_, dyn SpecializedSer<S>>(self) {
spec.specialized_serialize(serializer)
} else {
// fall back to compile-time reflection via TypeId
...
}
}
}
```
Fix E0040 suggestion for explicit `Drop::drop` UFCS calls
`Drop::drop(&mut f)` now correctly suggests `drop(f)` instead of the bare `drop` with no argument.
Fix: rust-lang/rust#156017
Improve `&pin` reference-pattern suggestions
This fills in the `pin_ergonomics` FIXME in `borrow_pat_suggestion` by making the diagnostic prefix account for both `Pinnedness` and `Mutability`.
Previously, the type-position suggestion path used ordinary reference spelling, which can spell `&` and `&mut` but cannot correctly spell pinned reference-pattern suggestions such as `&pin const` and `&pin mut`.
This is a diagnostic-only change. It adds focused UI coverage for both pinned const and pinned mut reference-pattern suggestions.
c-variadic: gate `va_arg` on `c_variadic_experimental_arch`
tracking issue: https://github.com/rust-lang/rust/issues/44930
Just gating `...` is insufficient because we make the types available everywhere, and you could still define and export functions that used va_arg for targets where we don't want to stably support it.
r? joshtriplett
`Drop::drop(&mut f)` now correctly suggests `drop(f)` instead of
the bare `drop` with no argument.
Signed-off-by: Usman Akinyemi <usmanakinyemi202@gmail.com>
Regression test for trait-system-refactor#7
Adds a regression test for [`AliasRelate` hides info in transitive cases](https://github.com/rust-lang/trait-system-refactor-initiative/issues/7).
The example previously errored under the new solver but compiles cleanly now thanks to eager normalization (post-rust-lang/rust#119106). Verified on both the `old` and `next` revisions.
The issue body has an older TODO suggesting a goal-proving variant test; per lcnr's recent note in `#t-types/trait-system-refactor` ("this isn't an issue as we eagerly normalize"), the underlying mechanism is now resolved across both inference and goal-proving paths, so this single regression test is sufficient. Closing the upstream issue manually after merge.
r? @lcnr
Just gating `...` is insufficient because we make the types available
everywhere, and you could still define and export functions that used
va_arg for targets where we don't want to stably support it.
Add `const_param_ty_unchecked` gate
Add `const_param_ty_unchecked` internal feature gate to skip `ConstParamTy_` trait enforcement on type. Provides an escape hatch for writing tests and examples that use const generics without needing to ensure all fields implement `ConstParamTy_`.
r? BoxyUwU
bors