| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Co-authored-by: gh-tr <troach@qnx.com>
|
|
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
|
|
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`
|
|
Rollup of 9 pull requests
Successful merges:
- #107573 (Update the minimum external LLVM to 14)
- #107626 (Fix `x fix` on the standard library itself)
- #107673 (update ICU4X to 1.1.0)
- #107733 (Store metrics from `metrics.json` to CI PGO timer)
- #108007 (Use `is_str` instead of string kind comparison)
- #108033 (add an unstable `#[rustc_coinductive]` attribute)
- #108039 (Refactor refcounted structural_impls via functors)
- #108040 (Use derive attributes for uninteresting traversals)
- #108044 (interpret: rename Pointer::from_addr → from_addr_invalid)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
This is required due to `BCryptGenRandom` failing to load the necessary dll on some systems.
|
|
interpret: rename Pointer::from_addr → from_addr_invalid
This function corresponds to `ptr::invalid` in the standard library; the previous name was not clear enough IMO.
|
|
r=oli-obk
Use derive attributes for uninteresting traversals
It appears that visiting and folding was implemented on `BitMatrix` solely so that the derive macros could be used on `GeneratorLayout`, however such implementation would not necessarily be correct for other uses (if there were any). Adding attributes to the derive macro is more correct and potentially more generally useful.
r? ``@oli-obk``
|
|
Refactor refcounted structural_impls via functors
The mapping of values in refcounted types can be extracted as a functor, simplifying the implementations in the type library (whose structural folding impls now all use such functors). This functor could also prove more generally useful elsewhere.
|
|
add an unstable `#[rustc_coinductive]` attribute
useful to test coinduction, especially in the new solver.
as this attribute should remain permanently unstable I don't think this needs any official approval. cc ``@rust-lang/types``
had to weaken the check for stable query results in the solver to prevent an ICE if there's a coinductive cycle with constraints.
r? ``@compiler-errors``
|
|
Use `is_str` instead of string kind comparison
Split out from #107939
|
|
Store metrics from `metrics.json` to CI PGO timer
With this change, we'll be able to easily see how long does it take to compile LLVM vs `rustc`.
r? ```@Mark-Simulacrum```
|
|
update ICU4X to 1.1.0
This patch updates the ICU4X crates to version 1.1.0 and regenerates the static data for `rustc_baked_icu_data`.
This is mostly an internal and bugfix update. It notably includes https://github.com/unicode-org/icu4x/pull/2834 to fix the future compatibility warning for [`BYTE_SLICE_IN_PACKED_STRUCT_WITH_DERIVE`](https://github.com/rust-lang/rust/issues/107457).
[full changelog](https://github.com/unicode-org/icu4x/blob/icu%401.1.0/CHANGELOG.md)
|
|
Fix `x fix` on the standard library itself
Fixes https://github.com/rust-lang/rust/issues/107501
|
|
Update the minimum external LLVM to 14
With this change, we'll have stable support for LLVM 14 through 16 (pending release).
For reference, the previous increase to LLVM 13 was #100460.
|
|
Rollup of 10 pull requests
Successful merges:
- #103478 ( Suggest fix for misplaced generic params on fn item #103366 )
- #107739 (Check for overflow in evaluate_canonical_goal)
- #108003 (Avoid ICE when the generic_span is empty)
- #108016 ("Basic usage" is redundant for there is just one example)
- #108023 (Shrink size of array benchmarks)
- #108024 (add message to update Cargo.toml when x is changed)
- #108025 (rustdoc: add more tooltips to intra-doc links)
- #108029 (s/eval_usize/eval_target_usize/ for clarity)
- #108035 (Avoid using a dead email address as the main email address)
- #108038 (Remove needless supertrait constraints from Interner projections)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove needless supertrait constraints from Interner projections
These associated types are already all constrained to implement `Ord`, so specifically requiring its supertraits `Eq`, `PartialEq` and `PartialOrd` is superfluous.
|
|
r=Mark-Simulacrum
Avoid using a dead email address as the main email address
This caused highfive to welcome me as a new contributor on every PR, because it couldn't find any commits of mine.
|
|
s/eval_usize/eval_target_usize/ for clarity
r? `@nnethercote`
as discussed in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.60Const.60.20and.20.60usize.60.2F.60u64.60 it is unclear what `usize` means and why we use a `u64` for something talking about `usize`. This renaming should make it clear that we're talking about `usize`s on the target platform, irrespective of the compiler host platform.
|
|
r=GuillaumeGomez
rustdoc: add more tooltips to intra-doc links
This commit makes intra-doc link tooltips consistent with generated links in function signatures and item tables, with the format `itemtype foo::bar::baz`. This way, you can tell if a link points at a trait or a type (for example) by mousing over it.
See also https://github.com/rust-lang/rust/pull/39697
Partially solves https://internals.rust-lang.org/t/rustdoc-suggestion-highlight-links-fn-s-mod-s-type-s-etc-appropriately-within-and-documentation/17931 (though the Internals thread asks for color-coding, while this PR adds a tooltip instead, it's accomplishing the same thing).
Before:
<img width="950" alt="image" src="https://user-images.githubusercontent.com/1593513/218653059-911cea01-7231-438a-ad98-be98ab73783f.png">
After:
<img width="432" alt="image" src="https://user-images.githubusercontent.com/1593513/218653201-34ca3aa7-18f1-4cb1-be68-a1411bbe797e.png">
|
|
add message to update Cargo.toml when x is changed
`@jyn514` Is this correct?
As mentioned in #108021
|
|
Shrink size of array benchmarks
Might've overdone it with the size of these benchmarks, as there's no need for them to be quite as large.
Fixes #108011
|
|
"Basic usage" is redundant for there is just one example
|
|
Avoid ICE when the generic_span is empty
Fixes #107998
r? ```@TaKO8Ki```
|
|
r=lcnr
Check for overflow in evaluate_canonical_goal
r? `@lcnr`
|
|
Suggest fix for misplaced generic params on fn item #103366
fixes #103366
This still has some work to go, but works for 2/3 of the initial base cases described in #1033366
simple fn:
```
error: expected identifier, found `<`
--> shreys/test_1.rs:1:3
|
1 | fn<T> id(x: T) -> T { x }
| ^ expected identifier
|
help: help: place the generic parameter list after the function name:
|
1 | fn id<T>(x: T) -> T { x }
| ~~~~
```
Complicated bounds
```
error: expected identifier, found `<`
--> spanishpear/test_2.rs:1:3
|
1 | fn<'a, B: 'a + std::ops::Add<Output = u32>> f(_x: B) { }
| ^ expected identifier
|
help: help: place the generic parameter list after the function name:
|
1 | fn f<'a, B: 'a + std::ops::Add<Output = u32>>(_x: B) { }
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Opening a draft PR for comments on approach, particularly I have the following questions:
- [x] Is it okay to be using `err.span_suggestion` over struct derives? I struggled to get the initial implementation (particularly the correct suggestion message) on struct derives, although I think given what I've learned since starting, I could attempt re-doing it with that approach.
- [x] in the case where the snippet cannot be obtained from a span, is the `help` but no suggestion okay? I think yes (also, when does this case occur?)
- [x] are there any red flags for the generalisation of this work for relevant item kinds (i.e. `struct`, `enum`, `trait`, and `union`). My basic testing indicates it does work for those types except the help tip is currently hardcoded to `after the function name` - which should change dependent on the item.
- [x] I am planning to not show the suggestion if there is already a `<` after the item identifier, (i.e. if there are already generics, as after a function name per the original issue). Any major objections?
- [x] Is the style of error okay? I wasn't sure if there was a way to make it display nicer, or if thats handled by span_suggestion
These aren't blocking questions, and I will keep working on:
- check if there is a `<` after the ident (and if so, not showing the suggestion)
- generalize the help message
- figuring out how to write/run/etc ui tests (including reading the docs for them)
- logic cleanups
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fix: Unexpected trait bound not satisfied in HRTB and Associated Type
fix https://github.com/rust-lang/rust/issues/103563
|
|
|
|
|
|
rustc/rustdoc: Perform name resolver cleanups enabled by #94857
Unblocks https://github.com/rust-lang/rust/pull/105462.
r? `@oli-obk`
|
