Discourage overuse of mem::forget
Some uses of `mem::forget` have been replaced by better methods of `Box`, so I've removed obsoleted use-cases from these docs.
I've removed emphasis on leaking, because it's not obvious `mem::forget` does not guarantee leaking of memory: memory of stack-allocated objects and values partially moved out of `Box` will still be freed. That's a potential error when used to pass objects to FFI, so it's better to direct users to `Box::into_raw` instead.
Use optimized SmallVec implementation
This PR replaces current SmallVec implementation with the one from the Servo project.
Closes https://github.com/rust-lang/rust/issues/51640
r? @Mark-Simulacrum
Feature gate where clauses on associated type impls
Fixes#52913. This doesn't address the core problem, which is tracked by https://github.com/rust-lang/rust/issues/47206. However, it fixes the stable-to-stable regression: you now have to enable `#![feature(generic_associated_types)]` to trigger the weird behaviour.
- Original cycle error diagnostics PR'd against this issue caught
panic-causing error while resolving std::mem::transmute calls
- Now, catch invalid use case of not providing a concrete sized type
behind existential type in definining use case.
- Update relevant test to reflect this new error
52985: revert normalize query changes
- PR 53588 invalidates 53316, causing a correct cycle error to occur
with a good span.
- Don't need to revert the whole merge as the test files are
still fine, just need to revert the normalize query changes.
- It should now be correct that infinite recursion detected during
normalize query type folding is a bug, should have been caught earlier
(when resolving the existential type's defining use cases).
52985: code review impl
- Only cause cycle error if anonymous type resolves to anonymous type
that has the same def id (is the same type) as the original (parent)
type.
- Add test case to cover this case for existential types.
52985: remove Ty prefix from TyAnon
- To align with changes per commit 6f637da50c
Allow panicking with string literal messages inside constants
r? @eddyb
cc https://github.com/rust-lang/rust/issues/51999
we can't implement things like `panic!("foo: {}", x)` right now because we can't call trait methods (most notably `Display::fmt`) inside constants. Also most of these impls probably have loops and conditions, so it's messy anyway.
But hey `panic!("foo")` works at least.
cc @japaric got any test ideas for `#![no_std]`?
Rollup of 10 pull requests
Successful merges:
- #53418 (Mark some suggestions as MachineApplicable)
- #53431 (Moved some feature gate ui tests to correct location)
- #53442 (Update version of rls-data used with save-analysis)
- #53504 (Set applicability for more suggestions.)
- #53541 (Fix missing impl trait display as ret type)
- #53544 (Point at the trait argument when using unboxed closure)
- #53558 (Normalize source line and column numbers.)
- #53562 (Lament the invincibility of the Turbofish)
- #53574 (Suggest direct raw-pointer dereference)
- #53585 (Remove super old comment on function that parses items)
Failed merges:
- #53472 (Use FxHash{Map,Set} instead of the default Hash{Map,Set} everywhere in rustc.)
- #53563 (use String::new() instead of String::from(""), "".to_string(), "".to_owned() or "".into())
r? @ghost
Rename TyVariants and variants
- Rename `TypeVariants` to `TyKind`.
- Remove the `Ty` prefix from each one of its variants (plus the identically-named variants of `PrimTy`).
- Rename `ty::Slice` to `ty::List`.
The new names look cleaner.
r? @eddyb
Remove super old comment on function that parses items
This comment was added more than 5 years ago in ab03c1e422. As far as anyone reading this comment today needs to know, the function has never parsed items from inside an extern crate.
Suggest direct raw-pointer dereference
People often come looking for some kind of `as_ref_unchecked` method on
raw pointers that would give them `&T` and not `Option<&T>` when they
are sure the pointer is not NULL.
There's no such method, but taking a reference of the dereferenced
pointer accomplishes the same thing. Therefore, suggest using that, at
the `as_ref` site ‒ it's a place people are likely going to look into.
Lament the invincibility of the Turbofish
Here a test case is added to ensure that any others attempting to drive the Turbofish to extinction have second thoughts. Previously the [entire test suite would succeed](https://github.com/rust-lang/rust/pull/53511) if generic arguments were accepted without disambiguation, making for [confusing and heartbreaking circumstances](https://github.com/rust-lang/rfcs/pull/2527).
Fix missing impl trait display as ret type
I need to convert a `TraitPredicate` into a `TraitBound` to get the returned impl trait. So far, didn't find how or even if it was the good way to do it.
cc @eddyb @oli-obk (since you're the one behind the change apparently 😉)
Set applicability for more suggestions.
Converts a couple more calls to `span_suggestion_with_applicability` (#50723). To be on the safe side, I marked suggestions that depend on the intent of the user or that are potentially lossy conversions as MaybeIncorrect.
r? @estebank
fix array drop glue: properly turn raw ptr into reference
Discovered while working on https://github.com/rust-lang/rust/pull/53424: The generated drop glue uses an assignment `ptr = cur` where `ptr` is a reference and `cur` a raw pointer. This is not well-formed MIR.
Do we have MIR sanity checks that run on the drop glue and should have caught this?
r? @eddyb
Buffer LLVM's object output stream
In some profiling on OSX I saw the `write` syscall as quite high up on
the profiling graph, which is definitely not good! It looks like we're
setting the output stream of an object file as directly to a file
descriptor which means that we run the risk of doing lots of little
writes rather than a few large writes.
This commit fixes this issue by adding a buffered stream on the output,
causing the `write` syscall to disappear from the profiles on OSX.
CTFE engine refactor
* Value gets renamed to `Operand`, so that now `interpret::{Place, Operand}` are the "dynamic" versions of `mir::{Place, Operand}`.
* `Operand` and `Place` share the data for their "stuff is in memory"-base in a new type, `MemPlace`. This also makes it possible to give some more precise types in other areas. Both `Operand` and `MemPlace` have methods available to project into fields (and other kinds of projections) without causing further allocations.
* The type for "a `Scalar` or a `ScalarPair`" is called `Value`, and again used to give some more precise types.
* All of these have versions with an attached layout, so that we can more often drag the layout along instead of recomputing it. This lets us get rid of `PlaceExtra::Downcast`. `MPlaceTy` and `PlaceTy` can only be constructed in place.rs, making sure the layout is handled properly. (The same should eventually be done for `ValTy` and `OpTy`.)
This is used to check, when copying an operand to a place, that the sizes match (which caught a bunch of bugs).
* All the high-level functions to write typed memory take a `Place`, and live in `place.rs`. All the high-level typed functions to read typed memory take an `Operand`, and live in `operands.rs`.
* Remove `cur_frame` and handling of signedess from memory (catching a bug in the float casting code).
* [Only functional change] Enable sanity check to recurse below dyn traits and slices.
r? @oli-obk
Cc @eddyb
