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

Remove the pipes compiler #8170

Closed
wants to merge 1 commit into from
Closed

Remove the pipes compiler #8170

wants to merge 1 commit into from

Conversation

brson
Copy link
Contributor

@brson brson commented Aug 1, 2013

The pipes compiler produced data types that encoded efficient and safe
bounded message passing protocols between two endpoints. It was also
capable of producing unbounded protocols.

It was useful research but was arguably done before its proper time.

I am removing it for the following reasons:

  • In practice we used it only for producing the oneshot protcol and
    the unbounded stream protocol and all communication in Rust use those.
  • The interface between the proto! macro and the standard library
    has a large surface area and was difficult to maintain through
    language and library changes.
  • It is now written in an old dialect of Rust and generates code
    which would likely be considered non-idiomatic.
  • Both the compiler and the runtime are difficult to understand,
    and likewise the relationship between the generated code and
    the library is hard to understand. Debugging is difficult.
  • The new scheduler implements stream and oneshot by hand
    in a way that will be significantly easier to maintain.

This shouldn't be taken as an indication that 'channel protocols'
for Rust are not worth pursuing again in the future.

Concerned parties may include: @graydon, @pcwalton, @eholk, @bblum

The most likely candidates for closing are #7666, #3018, #3020, #7021, #7667, #7303, #3658, #3295.

@bblum
Copy link
Contributor

bblum commented Aug 1, 2013

This is fine with me. I should like to see it re-implemented in a more idiomatic way post-1.0.

(Though, the send_any/send_all convenience wrapper issues are still relevant without protocols.)

@graydon
Copy link
Contributor

graydon commented Aug 1, 2013

I'm ok with this, at this point. It's been 10 months since we last revisited this and we haven't seen any new uses for the full proto system, just ongoing maintenance burden while trying to redo IO. Sad but IMO reasonable at this point. If we can get @eholk interested in reviving / retargeting the things that have changed since its initial construction, it might well live again as an external syntax extension.

The pipes compiler produced data types that encoded efficient and safe
bounded message passing protocols between two endpoints. It was also
capable of producing unbounded protocols.

It was useful research but was arguably done before its proper time.

I am removing it for the following reasons:

* In practice we used it only for producing the `oneshot` and `stream`
  unbounded protocols and all communication in Rust use those.
* The interface between the proto! macro and the standard library
  has a large surface area and was difficult to maintain through
  language and library changes.
* It is now written in an old dialect of Rust and generates code
  which would likely be considered non-idiomatic.
* Both the compiler and the runtime are difficult to understand,
  and likewise the relationship between the generated code and
  the library is hard to understand. Debugging is difficult.
* The new scheduler implements `stream` and `oneshot` by hand
  in a way that will be significantly easier to maintain.

This shouldn't be taken as an indication that 'channel protocols'
for Rust are not worth pursuing again in the future.
bors added a commit that referenced this pull request Aug 1, 2013
The pipes compiler produced data types that encoded efficient and safe
bounded message passing protocols between two endpoints. It was also
capable of producing unbounded protocols.

It was useful research but was arguably done before its proper time.

I am removing it for the following reasons:

* In practice we used it only for producing the `oneshot` protcol  and
  the unbounded `stream` protocol and all communication in Rust use those.
* The interface between the proto! macro and the standard library
  has a large surface area and was difficult to maintain through
  language and library changes.
* It is now written in an old dialect of Rust and generates code
  which would likely be considered non-idiomatic.
* Both the compiler and the runtime are difficult to understand,
  and likewise the relationship between the generated code and
  the library is hard to understand. Debugging is difficult.
* The new scheduler implements `stream` and `oneshot` by hand
  in a way that will be significantly easier to maintain.

This shouldn't be taken as an indication that 'channel protocols'
for Rust are not worth pursuing again in the future.

Concerned parties may include: @graydon, @pcwalton, @eholk, @bblum

The most likely candidates for closing are #7666, #3018, #3020, #7021, #7667, #7303, #3658, #3295.
@bors bors closed this Aug 1, 2013
@huonw huonw mentioned this pull request Nov 10, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Dec 30, 2021
new lint: `init-numbered-fields`

This fixes rust-lang#7985.

r? `@xFrednet`

---

changelog: new lint: [`init_numbered_fields`]
flip1995 pushed a commit to flip1995/rust that referenced this pull request Jan 13, 2022
Remove in_macro from clippy_utils

changelog: none

Previously done in rust-lang#7897 but reverted in rust-lang#8170. I'd like to keep `in_macro` out of utils because if a span is from expansion in any way (desugaring or macro), we should not proceed without understanding the nature of the expansion IMO.

r? `@llogiq`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants