Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 8 pull requests #108027

Closed
wants to merge 29 commits into from
Closed

Conversation

Dylan-DPC
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

joboet and others added 29 commits December 31, 2022 11:00
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 rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 14, 2023
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Feb 14, 2023
@Dylan-DPC
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Feb 14, 2023

📌 Commit b8d1547 has been approved by Dylan-DPC

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 14, 2023
@bors
Copy link
Contributor

bors commented Feb 14, 2023

⌛ Testing commit b8d1547 with merge 541986d1a381d4a880930d6d8e14c11b7fc952cc...

@rust-log-analyzer
Copy link
Collaborator

The job test-various failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
test [ui] tests/ui/async-await/issues/issue-67893.rs ... ok
test [ui] tests/ui/async-await/multiple-lifetimes/hrtb.rs ... ok
test [ui] tests/ui/async-await/move-part-await-return-rest-tuple.rs ... ok
test [ui] tests/ui/async-await/multiple-lifetimes/ret-ref.rs ... ok
test [ui] tests/ui/async-await/multiple-lifetimes/member-constraints-min-choice-issue-63033.rs ... ok
test [ui] tests/ui/async-await/mutually-recursive-async-impl-trait-type.rs#drop_tracking ... ok
test [ui] tests/ui/async-await/mutually-recursive-async-impl-trait-type.rs#drop_tracking_mir ... ok
test [ui] tests/ui/async-await/nested-in-impl.rs ... ok
test [ui] tests/ui/async-await/no-async-const.rs ... ok
---
test [ui] tests/ui/nll/maybe-initialized-drop-with-uninitialized-fragments.rs ... ok
test [ui] tests/ui/nll/member-constraints/min-choice.rs ... ok
test [ui] tests/ui/nll/maybe-initialized-drop.rs ... ok
test [ui] tests/ui/nll/issue-57960.rs ... ok
test [ui] tests/ui/nll/member-constraints/min-choice-reject-ambiguous.rs ... ok
test [ui] tests/ui/nll/mir_check_cast_closure.rs ... ok
test [ui] tests/ui/nll/mir_check_cast_reify.rs ... ok
test [ui] tests/ui/nll/mir_check_cast_unsafe_fn.rs ... ok
test [ui] tests/ui/nll/member-constraints/nested-impl-trait-fail.rs ... ok
---
---- [ui] tests/ui/consts/const-eval/issue-91827-extern-types.rs stdout ----

error: test run failed!
status: exit status: 101
command: cd "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/consts/const-eval/issue-91827-extern-types" && RUST_TEST_THREADS="16" "/node-v15.14.0-linux-x64/bin/node" "/checkout/src/etc/wasm32-shim.js" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/consts/const-eval/issue-91827-extern-types/a.wasm"
stdout: none
--- stderr -------------------------------
RuntimeError: unreachable
    at __rust_start_panic (<anonymous>:wasm-function[53]:0x3d2e)
    at rust_panic (<anonymous>:wasm-function[49]:0x3bf6)
    at _ZN3std9panicking20rust_panic_with_hook17hdc2587369679a530E (<anonymous>:wasm-function[48]:0x3bc6)
    at _ZN3std9panicking19begin_panic_handler28_$u7b$$u7b$closure$u7d$$u7d$17h0d4e0c9153aed5a0E (<anonymous>:wasm-function[38]:0x32bc)
    at _ZN3std10sys_common9backtrace26__rust_end_short_backtrace17h113db0e4489a8b83E (<anonymous>:wasm-function[37]:0x31e6)
    at rust_begin_unwind (<anonymous>:wasm-function[43]:0x381d)
    at _ZN4core9panicking9panic_fmt17hcce51f70ea30a952E (<anonymous>:wasm-function[100]:0x45cb)
    at _ZN4core9panicking19assert_failed_inner17h8b898611f8bae466E (<anonymous>:wasm-function[116]:0x5053)
    at _ZN4core9panicking13assert_failed17h3b91ff5265d27903E (<anonymous>:wasm-function[7]:0x41f)
    at _ZN24issue_91827_extern_types4main17h66dc0d1f7a8dbae7E (<anonymous>:wasm-function[8]:0x45c)
    at _ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17h44fcb5436bc621cdE (<anonymous>:wasm-function[0]:0x1b4)
    at _ZN3std2rt10lang_start28_$u7b$$u7b$closure$u7d$$u7d$17hfb493f38d7fe943fE (<anonymous>:wasm-function[1]:0x1d6)
    at _ZN3std2rt19lang_start_internal17h14be199975ac12b5E (<anonymous>:wasm-function[35]:0x30e9)
    at main (<anonymous>:wasm-function[9]:0x495)
    at Object.<anonymous> (/checkout/src/etc/wasm32-shim.js:20:20)
    at Module._compile (node:internal/modules/cjs/loader:1092:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1121:10)
    at Module.load (node:internal/modules/cjs/loader:972:32)
    at Function.Module._load (node:internal/modules/cjs/loader:813:14)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:76:12)
Some tests failed in compiletest suite=ui mode=ui host=x86_64-unknown-linux-gnu target=wasm32-unknown-unknown



failures:

@bors
Copy link
Contributor

bors commented Feb 14, 2023

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 14, 2023
@Dylan-DPC Dylan-DPC closed this Feb 14, 2023
@Dylan-DPC Dylan-DPC deleted the rollup-ihsi05t branch February 14, 2023 18:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.