Rollup of 8 pull requests #108027
Closed
Rollup of 8 pull requests #108027
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
See the inline comments for the description of the new algorithm.
Specifically remove V, which can always be VariantIdx, and F, which can always be Layout.
--wip-- [skip ci] get the generic text and put it int he suggestion, but suggestion not working on derive subdiagnostic refactor away from derives and use span_suggestion() instead. Show's the correct(?) generic contents, but overwrites the fn name :( x fmt drop commented code and s/todo/fixme get the correct diagnostic for functions, at least x fmt remove some debugs remove format remove debugs remove useless change remove useless change remove legacy approach correct lookahead + error message contains the ident name fmt refactor code tests add tests remoev debug remove comment
Co-authored-by: Takayuki Maeda <takoyaki0316@gmail.com>
…66_fix, r=TaKO8Ki Suggest fix for misplaced generic params on fn item rust-lang#103366 fixes rust-lang#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
rework min_choice algorithm of member constraints See [this comment](rust-lang#105300 (comment)) for the description of the new algorithm. Fixes rust-lang#63033 Fixes rust-lang#104639 This uses a more general algorithm than rust-lang#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 rust-lang#104639. cc `@nikomatsakis` `@lqd` `@tmandry` `@eholk` `@chenyukang` `@oli-obk` r? types
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
Remove some superfluous type parameters from layout.rs. Specifically remove V, which can always be VariantIdx, and F, which can always be Layout.
…oli-obk 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 rust-lang/unsafe-code-guidelines#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 rust-lang#107009 able to handle discriminants too.
…rister 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.
…mpiler-errors Avoid ICE when the generic_span is empty Fixes rust-lang#107998 r? `@TaKO8Ki`
…orkingjubilee 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 rust-lang#108011
rustbot
added
the
S-waiting-on-review
rustbot
added
T-compiler
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
⌛ Testing commit b8d1547 with merge 541986d1a381d4a880930d6d8e14c11b7fc952cc... |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
fnitem #103366 )Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup