static eval: Do not ICE on layout size overflow
Layout size overflow and typeck eval errors are reported. Trigger a bug
only when the eval error is strictly labeled as TooGeneric.
Fixes: #56762
Add DoubleEndedIterator::nth_back
As suggested by #54054. This doesn't fix that issue, as this doesn't add enough implementations to optimise that specific use case, but it adds the method and a few (relatively) trivial overrides to work as an initial implementation.
It's probably going to be a lot of work adding `nth_back` implementations everywhere, and I don't have the time to include it all in this commit. But, it's a start. :)
Use compiletest timestamp to check if the tests should be rerun.
An attempt to fix #56280 by checking if timestamps of compile test files are older than the timestamp of the stamp file.
?r nagisa
This commit modifies the wording of the warning for
backwards-incompatible changes in migrate mode. The warning messages are
changed to be lowercase and not include line-breaks in order to be
consistent with other compiler diagnostics.
Short-circuit DefIdForest::intersection()
If the forest is already empty, there is no point in intersecting further.
Also handle the first element separately, so we don't compute an unnecessary intersection between the full forest and the first element, which is always equal to the first element.
This is the second try at fixing #57028, as the previous attempt only recovered part of the regression. I checked locally that this drops time spent in ty::inhabitedness for syn-check a lot, though not to zero.
r? @varkor
If the forest is already empty, there is no point in intersecting
further.
Also handle the first element separately, so we don't compute an
unnecessary intersection between the full forest and the first
element, which is always equal to the first element.
stop treating trait objects from #[fundamental] traits as fundamental
This is a [breaking-change] to code that exploits this functionality (which should be limited to code using `#![feature(fundamental)]`.
Fixes#56503.
r? @nikomatsakis
Add unstable VecDeque::rotate_{left|right}
Like the ones on slices, but more efficient because vecdeque is a circular buffer.
Issue that proposed this: https://github.com/rust-lang/rust/issues/56686
~~💣 Please someone look very carefully at the `unsafe` in this! The `wrap_copy` seems to be exactly what this method needs, and the `len` passed to it is never more than half the length of the deque, but I haven't managed to prove to myself that it's correct 💣~~ I think I proved that this code meets the requirement of the unsafe code it's calling; please double-check, of course.
Remove pin::Unpin reexport and add Unpin to the prelude.
Change Pin associated functions to methods.
Rename get_mut_unchecked_ to get_unchecked_mut
Remove impl Unpin for Pin
Mark Pin repr(transparent)
Stabilize `Rc`, `Arc` and `Pin` as method receivers
Replaces #55880
Closes #55786
r? @nikomatsakis
cc @withoutboats @cramertj
This lets you write methods using `self: Rc<Self>`, `self: Arc<Self>`, `self: Pin<&mut Self>`, `self: Pin<Box<Self>`, and other combinations involving `Pin` and another stdlib receiver type, without needing the `arbitrary_self_types`. Other user-created receiver types can be used, but they still require the feature flag to use.
This is implemented by introducing a new trait, `Receiver`, which the method receiver's type must implement if the `arbitrary_self_types` feature is not enabled. To keep composed receiver types such as `&Arc<Self>` unstable, the receiver type is also required to implement `Deref<Target=Self>` when the feature flag is not enabled.
This lets you use `self: Rc<Self>` and `self: Arc<Self>` in stable Rust, which was not allowed previously. It was agreed that they would be stabilized in #55786. `self: Pin<&Self>` and other pinned receiver types do not require the `arbitrary_self_types` feature, but they cannot be used on stable because `Pin` still requires the `pin` feature.
Remove "visited" set from inhabitedness checking (fix perf regression)
Now that references are no longer recursively checked, this should no longer be necessary, and it's a major performance bottleneck.
This should fix#57028.
r? @varkor
On musl targets assume certain symbols exist (like pipe2 and accept4).
This fixes#56675.
I don't know if this is the best solution, or if I should also add some tests so I'm waiting for some feedback.
Thanks!
When the feature has been added back (#55148) the feature gate has not
been adjusted accordingly. We have it enabled for 1.32.0, currently in
Beta, so adjust it.
Refs: #44431.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Instead disable creation of assumptions during inlining using an
LLVM opt flag.
The -Z arg-align-attributes option which previously controlled this
behavior is removed.
I was assuming that https://github.com/rust-lang/rust/pull/56792 would
have resulted in compiletest tests being executed in CI. However, I
couldn't find any mentions of the unit test names in any CI logs.
This adds the compiletest test execution to the checktools.sh script.
Rework treatment of `$crate` in procedural macros
Important clarification: `$crate` below means "processed `$crate`" or "output `$crate`". In the input of a decl macro `$crate` is just two separate tokens, but in the *output of a decl macro* `$crate` is a single keyword identifier (https://github.com/rust-lang/rust/issues/55640#issuecomment-435692791).
First of all, this PR removes the `eliminate_crate_var` hack.
`$crate::foo` is no longer replaced with `::foo` or `::crate_name::foo` in the input of derive proc macros, it's passed to the macro instead with its precise span and hygiene data, and can be treated as any other path segment keyword (like `crate` or `self`) after that. (Note: `eliminate_crate_var` was never used for non-derive proc macros.)
This creates an annoying problem - derive macros still may stringify their input before processing and expect `$crate` survive that stringification and refer to the same crate (the Rust 1.15-1.29 way of doing things).
Moreover, the input of proc macro attributes and derives (but not fn-like proc macros) also effectively survives stringification before being passed to the macro (also for legacy implementation reasons).
So we kind of resurrect the `eliminate_crate_var` hack in reduced form, but apply it only to AST pretty-printing.
If an AST fragment is pretty-printed, the resulting *text* will have `$crate` replaced with `crate` or `::crate_name`. This should be enough to keep all the legacy cases working.
Closes https://github.com/rust-lang/rust/issues/55640
Closes https://github.com/rust-lang/rust/issues/56622
r? @ghost
