| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Related to #96399
|
|
Optimize `mk_region`
PR #107869 avoiding some interning under `mk_ty` by special-casing `Ty` variants with simple (integer) bodies. This PR does something similar for regions.
r? `@compiler-errors`
|
|
Remove save-analysis.
Most tests involving save-analysis were removed, but I kept a few where the `-Zsave-analysis` was an add-on to the main thing being tested, rather than the main thing being tested.
Closes https://github.com/rust-lang/rust/issues/43606
|
|
Rollup of 6 pull requests
Successful merges:
- #106372 (Use id-based thread parking on SOLID)
- #108050 (Fix index out of bounds ICE in `point_at_expr_source_of_inferred_type`)
- #108084 (Constify `RangeBounds`, `RangeX::contains` and `RangeX::is_empty` (where applicable).)
- #108101 (don't clone types that are copy)
- #108102 (simplify some refs)
- #108103 (be nice and don't slice)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
be nice and don't slice
These are already slices, no need to slice them again
|
|
simplify some refs
|
|
don't clone types that are copy
|
|
Constify `RangeBounds`, `RangeX::contains` and `RangeX::is_empty` (where applicable).
cc `@fee1-dead`
`@rustbot` label +T-libs-api -T-libs
Tracking issue: #108082
|
|
Fix index out of bounds ICE in `point_at_expr_source_of_inferred_type`
There might be more type params than args to a method call, which leads to an index out of bounds panic.
I'm not familiar with this code at all, so unsure whether this is the right fix, but at least this patch fixes #108042 for me (I hit the same issue with similar code)
|
|
Use id-based thread parking on SOLID
By using the [`slp_tsk`/`wup_tsk`](https://cs.uwaterloo.ca/~brecht/courses/702/Possible-Readings/embedded/uITRON-4.0-specification.pdf) system functions instead of an event-flag structure, `Parker` becomes cheaper to construct and SOLID can share the implementation used by NetBSD and SGX.
ping ``@kawadakk``
r? ``@m-ou-se``
``@rustbot`` label +T-libs
|
|
Most tests involving save-analysis were removed, but I kept a few where
the `-Zsave-analysis` was an add-on to the main thing being tested,
rather than the main thing being tested.
For `x.py install`, the `rust-analysis` target has been removed.
For `x.py dist`, the `rust-analysis` target has been kept in a
degenerate form: it just produces a single file `reduced.json`
indicating that save-analysis has been removed. This is necessary for
rustup to keep working.
Closes #43606.
|
|
Enable CopyProp
r? `@tmiasko`
`@rustbot` label +A-mir-opt
|
|
Rollup of 10 pull requests
Successful merges:
- #107034 (Migrating rustc_infer to session diagnostics (part 4))
- #107972 (Fix unintentional UB in ui tests)
- #108010 (Make `InferCtxt::can_eq` and `InferCtxt::can_sub` return booleans)
- #108021 (make x look for x.py if shell script does not exist)
- #108047 (Use `target` instead of `machine` for mir interpreter integer handling.)
- #108049 (Don't suggest `#[doc(hidden)]` trait methods with matching return type)
- #108066 (Better names for illegal impl trait positions)
- #108076 (rustdoc: Use more let chain)
- #108088 (clarify correctness of `black_box`)
- #108094 (Demonstrate I/O in File examples)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
These are already slices, no need to slice them again
|
|
|
|
|
|
Don't ICE in `might_permit_raw_init` if reference is polymorphic
Emitting optimized MIR for a polymorphic function may require computing layout of a type that isn't (yet) known. This happens in the instcombine pass, for example. Let's fail gracefully in that condition.
cc `@saethlin`
fixes #107999
|
|
Demonstrate I/O in File examples
I've noticed that some Rust novices unnecessarily reinvent `std::fs::{read,write}`, presumably because they search for equivalents of `fopen` + `fwrite`. I've added links to `std::fs::{read,write}` in the docs.
The `File` examples were only showing how to open a file, but not how to use the opened handle, unnecessarily leaving out the next step. I've added a variety of different uses of file handles to their examples in docs.
|
|
clarify correctness of `black_box`
Resolves #107957, as described in the related issue.
No code changes, just documentation.
|
|
rustdoc: Use more let chain
Got the idea after yesterday's review.
r? `@notriddle`
|
|
r=petrochenkov
Better names for illegal impl trait positions
Just some wording tweaks, no behavior changes.
|
|
Don't suggest `#[doc(hidden)]` trait methods with matching return type
Fixes #107983, addressing the bad suggestion.
The test can probably be made more specific to this case, but I'm unsure how.
`@rustbot` label +A-diagnostics
|
|
Use `target` instead of `machine` for mir interpreter integer handling.
The naming of `machine` only makes sense from a mir interpreter internals perspective, but outside users talk about the `target` platform. As per https://github.com/rust-lang/rust/pull/108029#issuecomment-1429791015
r? `@RalfJung`
|
|
make x look for x.py if shell script does not exist
Fixes #107907
Manually tested by doing the following after changes were made:
1. `cargo install --path src/tools/x`
2. checked out old version: commit hash `775c3c0` from https://github.com/rust-lang/rust/pull/99992
3. Ran `x --help` and it works. Previously, it was giving the error `x.py not found`
|
|
Make `InferCtxt::can_eq` and `InferCtxt::can_sub` return booleans
Nobody matches on the result, nor does the result return anything useful...
|
|
Fix unintentional UB in ui tests
`@matthiaskrgr` found UB in a bunch of the ui tests. This PR fixes a batch of miscellaneous tests I didn't think needed reviewers from a particular part of the project.
|
|
Migrating rustc_infer to session diagnostics (part 4)
`@rustbot` label +A-translation
r? rust-lang/diagnostics
cc https://github.com/rust-lang/rust/issues/100717
|
|
|
|
|
|
|
|
|
|
|
|
Avoid accessing HIR when it can be avoided
Experiment to see if it helps some incremental cases.
Will be rebased once https://github.com/rust-lang/rust/pull/107942 gets merged.
r? `@ghost`
|
|
|
|
|
|
|
|
|
|
The naming of `machine` only makes sense from a mir interpreter internals perspective, but outside users talk about the `target` platform
|
|
Rollup of 7 pull requests
Successful merges:
- #105300 (rework min_choice algorithm of member constraints)
- #107163 (Remove some superfluous type parameters from layout.rs.)
- #107173 (Suggest the correct array length on mismatch)
- #107411 (Handle discriminant in DataflowConstProp)
- #107968 (Enable `#[thread_local]` on armv6k-nintendo-3ds)
- #108032 (Un📦ing the Resolver)
- #108060 (Revert to using `RtlGenRandom` as a fallback)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
bump up x version
Refactor code
|
|
Revert to using `RtlGenRandom` as a fallback
This is required due to `BCryptGenRandom` failing to load a dll it depends on.
Fixes #108059
|
|
Un📦ing the Resolver
r? `@petrochenkov`
pulled out of https://github.com/rust-lang/rust/pull/105462
|
|
r=Nilstrieb
Enable `#[thread_local]` on armv6k-nintendo-3ds
Since [libctru 2.1.2](https://github.com/devkitPro/libctru/releases/tag/v2.1.2) was released we should now be able to use real `#[thread_local]` without corruption issues on the 3DS target.
CC `@Meziu` `@AzureMarker` `@Techie-Pi`
https://github.com/rust3ds/ctru-rs/issues/91#issuecomment-1426821450
|
|
Handle discriminant in DataflowConstProp
cc ``@jachris``
r? ``@JakobDegen``
This PR attempts to extend the DataflowConstProp pass to handle propagation of discriminants. We handle this by adding 2 new variants to `TrackElem`: `TrackElem::Variant` for enum variants and `TrackElem::Discriminant` for the enum discriminant pseudo-place.
The difficulty is that the enum discriminant and enum variants may alias each another. This is the issue of the `Option<NonZeroUsize>` test, which is the equivalent of https://github.com/rust-lang/unsafe-code-guidelines/issues/84 with a direct write.
To handle that, we generalize the flood process to flood all the potentially aliasing places. In particular:
- any write to `(PLACE as Variant)`, either direct or through a projection, floods `(PLACE as OtherVariant)` for all other variants and `discriminant(PLACE)`;
- `SetDiscriminant(PLACE)` floods `(PLACE as Variant)` for each variant.
This implies that flooding is not hierarchical any more, and that an assignment to a non-tracked place may need to flood a tracked place. This is handled by `for_each_aliasing_place` which generalizes `preorder_invoke`.
As we deaggregate enums by putting `SetDiscriminant` last, this allows to propagate the value of the discriminant.
This refactor will allow to make https://github.com/rust-lang/rust/pull/107009 able to handle discriminants too.
|
|
Suggest the correct array length on mismatch
Fixes #107156
I wasn't able to find a way to get the `Span` for the actual array size unfortunately, so this suggestion can't be applied automatically.
``@rustbot`` label +A-diagnostics
|
|
Remove some superfluous type parameters from layout.rs.
Specifically remove V, which can always be VariantIdx, and F, which can always be Layout.
|
|
rework min_choice algorithm of member constraints
See [this comment](https://github.com/rust-lang/rust/pull/105300#issuecomment-1384312743) for the description of the new algorithm.
Fixes #63033
Fixes #104639
This uses a more general algorithm than #89056 that doesn't treat `'static` as a special case. It thus accepts more code. For example:
```rust
async fn test2<'s>(_: &'s u8, _: &'_ &'s u8, _: &'_ &'s u8) {}
```
I claim it's more correct as well because it fixes #104639.
cc ``@nikomatsakis`` ``@lqd`` ``@tmandry`` ``@eholk`` ``@chenyukang`` ``@oli-obk``
r? types
|
|
r=compiler-errors
use semantic equality for const param type equality assertion
Fixes #107898
See added test for what caused this ICE
---
The current in assertion in `relate.rs` is rather inadequate when keeping in mind future expansions to const generics:
- it will ICE when there are infer vars in a projection in a const param ty
- it will spurriously return false when either ty has infer vars because of using `==` instead of `infcx.at(..).eq`
- i am also unsure if it would be possible with `adt_const_params` to craft a situation where the const param type is not wf causing `normalize_erasing_regions` to `bug!` when we would have emitted a diagnostic.
This impl feels pretty Not Great to me although i am not sure what a better idea would be.
- We have to have the logic behind a query because neither `relate.rs` or `combine.rs` have access to trait solving machinery (without evaluating nested obligations this assert will become _far_ less useful under lazy norm, which consts are already doing)
- `relate.rs` does not have access to canonicalization machinery which is necessary in order to have types potentially containing infer vars in query arguments.
We could possible add a method to `TypeRelation` to do this assertion rather than a query but to avoid implementing the same logic over and over we'd probably end up with the logic in a free function somewhere in `rustc_trait_selection` _anyway_ so I don't think that would be much better.
We could also just remove this assertion, it should not actually be necessary for it to be present. It has caught some bugs in the past though so if possible I would like to keep it.
r? `@compiler-errors`
|
|
|
|
|
