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

Swap return value order in pipes::oneshot #4496

Closed
brson opened this issue Jan 15, 2013 · 8 comments
Closed

Swap return value order in pipes::oneshot #4496

brson opened this issue Jan 15, 2013 · 8 comments
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@brson
Copy link
Contributor

brson commented Jan 15, 2013

oneshot returns (ChanOne, PortOne) while stream returns (Port, Chan). I prefer the port to be first.

@nickdesaulniers
Copy link

I'd like to try my hand at this, as my first contribution.

@brson
Copy link
Contributor Author

brson commented Jan 15, 2013

@nickdesaulniers Great!

@nickdesaulniers
Copy link

So I'm not too sure about this test:
https://github.com/mozilla/rust/blob/master/src/libcore/pipes.rs#L1259
@pcwalton was unsure where init came from, due to this syntax (which fully eludes me):
https://github.com/mozilla/rust/blob/master/src/libcore/pipes.rs#L1183

I've modified the order in the function declaration, and am still working through the resulting regressions, but I feel like this is a relic that should get fixed with this bug. EDIT: where can I find the init function of the oneshot module to modify it?

@brson
Copy link
Contributor Author

brson commented Jan 16, 2013

The init function is generated by the pipes protocol compiler, specifically the gen_init method.

I would consider these two separate issues (oneshot vs. init) as modifying the codegen for init will run into self-hosting issues, forcing you to come up with a scheme to transition from the old definition to the new. The problem you will hit is that the snapshot (stage0) compiler will generate code that calls into core::pipes and code in core::pipes will call into code generated by the protocol compiler, but because you are modifying core::pipes the two will not agree on the definitions in use. Please do take a crack at it and see what kind of problems you run into - I can help you come up with a transition strategy.

For what it's worth I use two basic strategies for working around self-hosting problems:

  • Leave the old definitions and duplicate them with a new definition; make a snapshot; remove the old definition; duplicate the new definition with the name of the old definition; make a snapshot; delete the duplicate definition
  • Add #[cfg(stage0)], #[cfg(stage1)], etc. attributes to code to make it compile differently in each stage of compilation; snapshot; remove the #[cfg(stage0)] definition

There's some outdated information about the bootstrapping process here: https://github.com/mozilla/rust/wiki/Note-compiler-snapshots

@nickdesaulniers
Copy link

Should I make that a separate issue and post line numbers containing all incorrect references? I have them all from $ ack --type-add=rust=.rs,.rc oneshot::init

@brson
Copy link
Contributor Author

brson commented Jan 16, 2013

Yes, that would be great. Thanks.

@nickdesaulniers
Copy link

tests are green. Pull request inbound

brson added a commit that referenced this issue Jan 16, 2013
Swap return value order in pipes::oneshot Issue #4496
@brson
Copy link
Contributor Author

brson commented Jan 16, 2013

Fixed!

@brson brson closed this as completed Jan 16, 2013
flip1995 added a commit to flip1995/rust that referenced this issue Aug 11, 2020
…flip1995

Handle mapping to Option in `map_flatten` lint

Fixes rust-lang#4496

The existing [`map_flatten`](https://rust-lang.github.io/rust-clippy/master/index.html#map_flatten) lint suggests changing `expr.map(...).flatten()` to `expr.flat_map(...)` when `expr` is `Iterator`. This PR changes suggestion to `filter_map` instead of `flat_map` when mapping to `Option`, because it is more natural

Also here are some questions:
* If expression has type which implements `Iterator` trait (`match_trait_method(cx, expr, &paths::ITERATOR) == true`), how can I get type of iterator elements? Currently I use return type of closure inside `map`, but probably it is not good way
* I would like to change suggestion range to cover only `.map(...).flatten()`, that is from:
```
    let _: Vec<_> = vec![5_i8; 6].into_iter().map(|x| 0..x).flatten().collect();
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try using `flat_map` instead: `vec![5_i8; 6].into_iter().flat_map
```
to
```
    let _: Vec<_> = vec![5_i8; 6].into_iter().map(|x| 0..x).flatten().collect();
                                             ^^^^^^^^^^^^^^^^^^^^^^^^ help: try using `flat_map` instead: `.flat_map(|x| 0..x)`
```
Is it ok?
* Is `map_flatten` lint intentionally in `pedantic` category, or could it be moved to `complexity`?

changelog: Handle mapping to Option in [`map_flatten`](https://rust-lang.github.io/rust-clippy/master/index.html#map_flatten) lint
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

2 participants