| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #112632 (Implement PartialOrd for `Vec`s over different allocators)
- #112759 (Make closure_saved_names_of_captured_variables a query. )
- #112772 (Add a fully fledged `Clause` type, rename old `Clause` to `ClauseKind`)
- #112790 (Syntactically accept `become` expressions (explicit tail calls experiment))
- #112830 (More codegen cleanups)
- #112844 (Add retag in MIR transform: `Adt` for `Unique` may contain a reference)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Syntactically accept `become` expressions (explicit tail calls experiment)
This adds `ast::ExprKind::Become`, implements parsing and properly gates the feature.
cc `@scottmcm`
|
|
Add a fully fledged `Clause` type, rename old `Clause` to `ClauseKind`
Does two basic things before I put up a more delicate set of PRs (along the lines of #112714, but hopefully much cleaner) that migrate existing usages of `ty::Predicate` to `ty::Clause` (`predicates_of`/`item_bounds`/`ParamEnv::caller_bounds`).
1. Rename `Clause` to `ClauseKind`, so it's parallel with `PredicateKind`.
2. Add a new `Clause` type which is parallel to `Predicate`.
* This type exposes `Clause::kind(self) -> Binder<'tcx, ClauseKind<'tcx>>` which is parallel to `Predicate::kind` 😸
The new `Clause` type essentially acts as a newtype wrapper around `Predicate` that asserts that it is specifically a `PredicateKind::Clause`. Turns out from experimentation[^1] that this is not negative performance-wise, which is wonderful, since this a much simpler design than something that requires encoding the discriminant into the alignment bits of a predicate kind, or something else like that...
r? ``@lcnr`` or ``@oli-obk``
[^1]: https://github.com/rust-lang/rust/pull/112714#issuecomment-1595653910
|
|
Make `{Arc,Rc,Weak}::ptr_eq` ignore pointer metadata
FCP completed in https://github.com/rust-lang/rust/issues/103763#issuecomment-1362267967
Closes #103763
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mmap/munmap/mremamp shims
This adds basic support for `mmap`/`mremap`/`munmap`, with the specific goal of testing allocators targeting Linux under Miri.
This supports `mmap` with `MAP_PRIVATE|MAP_ANONYMOUS`, and `PROT_READ|PROT_WRITE`, and explicitly does not support `MAP_SHARED` (because that's asking for MMIO) as well as any kind of file mapping (because it seems like nobody does `MAP_PRIVATE` on files even though that would be very sensible). And (officially) we don't support `MAP_FIXED`, so we always ignore the `addr` argument.
This supports `mremap` only when the implementation is allowed to move the mapping (so no `MREMAP_FIXED`, no `MREMAP_DONTUNMAP`, and required `MREMAP_MAYMOVE`), and also when the entirety of a region previously mapped by `mmap` is being remapped.
This supports `munmap` but only when the entirety of a region previously mapped by `mmap` is unmapped.
|
|
|
|
|
|
|
|
update rustfmt
changes described in https://github.com/rust-lang/rustfmt/blob/master/CHANGELOG.md#153-2023-06-20
r? `@ghost`
cc `@rust-lang/rustfmt`
|
|
|
|
Fix python linting errors
These were flagged by `ruff`, run using the config in https://github.com/rust-lang/rust/pull/112482
|
|
Better error for non const `PartialEq` call generated by `match`
Resolves #90237
|
|
Treat TAIT equation as always ambiguous in coherence
Not sure why we weren't treating all TAIT equality as ambiguous -- this behavior combined with `DefineOpaqueTypes::No` leads to coherence overlap failures, since we incorrectly consider impls as not overlapping because the obligation `T: From<Foo>` doesn't hold.
Fixes #112765
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
cleanup azure leftovers
Continuation of #97756
|
|
|
|
|
|
Move WF/ConstEvaluatable goal to clause
It can show up in a param-env, so I think it needs to be a clause kind.
r? ```@lcnr``` or ```@oli-obk```
|
|
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #110805 (Github action to periodically `cargo update` to keep dependencies current)
- #112435 (Allow overwriting the sysroot compile flag via --rustc-args)
- #112610 (Bump stdarch)
- #112619 (Suggest bumping download-ci-llvm-stamp if the build config for llvm changes)
- #112738 (make ice msg "Unknown runtime phase" a bit nicer)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Allow overwriting the sysroot compile flag via --rustc-args
Hi.
As discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/How.20to.20overwrite.20sysroot.20in.20x.2Epy.20test/near/364272269), this is a solution to allow the codegens to overwrite the sysroot as part of their test suite.
Thanks for the review.
|
|
Remove `box_free` lang item
This PR removes the `box_free` lang item, replacing it with `Box`'s `Drop` impl. Box dropping is still slightly magic because the contained value is still dropped by the compiler.
|
|
|
|
|
|
|
|
Add `AliasKind::Weak` for type aliases.
`type Foo<T: Debug> = Bar<T>;` does not check `T: Debug` at use sites of `Foo<NotDebug>`, because in contrast to a
```rust
trait Identity {
type Identity;
}
impl<T: Debug> Identity for T {
type Identity = T;
}
<NotDebug as Identity>::Identity
```
type aliases do not exist in the type system, but are expanded to their aliased type immediately when going from HIR to the type layer.
Similarly:
* a private type alias for a public type is a completely fine thing, even though it makes it a bit hard to write out complex times sometimes
* rustdoc expands the type alias, even though often times users use them for documentation purposes
* diagnostics show the expanded type, which is confusing if the user wrote a type alias and the diagnostic talks about another type that they don't know about.
For type alias impl trait, these issues do not actually apply in most cases, but sometimes you have a type alias impl trait like `type Foo<T: Debug> = (impl Debug, Bar<T>);`, which only really checks it for `impl Debug`, but by accident prevents `Bar<T>` from only being instantiated after proving `T: Debug`. This PR makes sure that we always check these bounds explicitly and don't rely on an implementation accident.
To not break all the type aliases out there, we only use it when the type alias contains an opaque type. We can decide to do this for all type aliases over an edition.
Or we can later extend this to more types if we figure out the back-compat concerns with suddenly checking such bounds.
As a side effect, easily allows fixing https://github.com/rust-lang/rust/issues/108617, which I did.
fixes https://github.com/rust-lang/rust/issues/108617
|
