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

Add `eprint!` and `eprintln!` macros to the prelude. #41192

Merged
merged 4 commits into from May 11, 2017

Conversation

Projects
None yet
@zackw
Contributor

zackw commented Apr 10, 2017

These are exactly the same as print! and println! except that they write to stderr instead of stdout. Issues #39228 and #40528; previous PR #39229; accepted RFC rust-lang/rfcs#1869; proposed revision to The Book rust-lang/book#615.

I have not revised this any since the original submission; I will do that later this week. I wanted to get this PR in place since it's been quite a while since the RFC was merged.

Known outstanding review comments:

  • @steveklabnik requested a new chapter for the unstable version of The Book -- please see if the proposed revisions to the second edition cover it.
  • @nodakai asked if it were possible to merge the internal methods _print and _eprint - not completely, since they both refer to different internal globals which we don't want to expose, but I will see if some duplication can be factored out.

Please let me know if I missed anything.

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Apr 10, 2017

Collaborator

r? @aturon

(rust_highfive has picked a reviewer for you, use r? to override)

Collaborator

rust-highfive commented Apr 10, 2017

r? @aturon

(rust_highfive has picked a reviewer for you, use r? to override)

Show outdated Hide outdated src/libstd/macros.rs
/// Macro for printing to the standard error.
///
/// Equivalent to the `print!` macro, except that output goes to
/// `io::stderr()` instead of `io::stdout()`. See `print!` for

This comment has been minimized.

@steveklabnik

steveklabnik Apr 10, 2017

Member

we don't use () after function names

@steveklabnik

steveklabnik Apr 10, 2017

Member

we don't use () after function names

This comment has been minimized.

@zackw

zackw Apr 13, 2017

Contributor

Fixed.

@zackw

zackw Apr 13, 2017

Contributor

Fixed.

Show outdated Hide outdated src/libstd/macros.rs
///
/// # Panics
///
/// Panics if writing to `io::stderr()` fails.

This comment has been minimized.

@steveklabnik

steveklabnik Apr 10, 2017

Member

in general, it'd be good to link up all the stuff here:

  • print!
  • io::stderr
  • io::stdout
  • io::stderr
@steveklabnik

steveklabnik Apr 10, 2017

Member

in general, it'd be good to link up all the stuff here:

  • print!
  • io::stderr
  • io::stdout
  • io::stderr

This comment has been minimized.

@zackw

zackw Apr 13, 2017

Contributor

Could you be more specific? I don't understand what you have in mind, besides some degree of cross-reference hyperlinks.

@zackw

zackw Apr 13, 2017

Contributor

Could you be more specific? I don't understand what you have in mind, besides some degree of cross-reference hyperlinks.

Show outdated Hide outdated src/libstd/macros.rs
///
/// # Panics
///
/// Panics if writing to `io::stderr()` fails.

This comment has been minimized.

@steveklabnik

steveklabnik Apr 10, 2017

Member

same comments here

@steveklabnik

steveklabnik Apr 10, 2017

Member

same comments here

This comment has been minimized.

@zackw

zackw Apr 13, 2017

Contributor

Also fixed

@zackw

zackw Apr 13, 2017

Contributor

Also fixed

@alexcrichton alexcrichton added the T-libs label Apr 11, 2017

Show outdated Hide outdated src/libstd/io/stdio.rs
// 2. If the local stderr is currently in use (e.g. we're in the middle of
// already printing) then accessing again would cause a panic.
//
// If, however, the actual I/O causes an error, we do indeed panic.

This comment has been minimized.

@alexcrichton

alexcrichton Apr 12, 2017

Member

Instead of line-for-line copying the comment above in _print, can this and _print bove either share an implementation or reduce duplication?

@alexcrichton

alexcrichton Apr 12, 2017

Member

Instead of line-for-line copying the comment above in _print, can this and _print bove either share an implementation or reduce duplication?

This comment has been minimized.

@zackw

zackw Apr 13, 2017

Contributor

Yes, the implementation can be factored out.

@zackw

zackw Apr 13, 2017

Contributor

Yes, the implementation can be factored out.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Apr 13, 2017

Member

@bors: r+

Thanks @zackw!

Member

alexcrichton commented Apr 13, 2017

@bors: r+

Thanks @zackw!

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 13, 2017

Contributor

📌 Commit 1d00098 has been approved by alexcrichton

Contributor

bors commented Apr 13, 2017

📌 Commit 1d00098 has been approved by alexcrichton

Show outdated Hide outdated src/libstd/io/mod.rs
@@ -290,6 +290,8 @@ pub use self::util::{copy, sink, Sink, empty, Empty, repeat, Repeat};
pub use self::stdio::{stdin, stdout, stderr, _print, Stdin, Stdout, Stderr};
#[stable(feature = "rust1", since = "1.0.0")]
pub use self::stdio::{StdoutLock, StderrLock, StdinLock};
#[unstable(feature = "eprint", issue="40528")]

This comment has been minimized.

@ollie27

ollie27 Apr 13, 2017

Contributor

This should probably be feature = "eprint_internal".

@ollie27

ollie27 Apr 13, 2017

Contributor

This should probably be feature = "eprint_internal".

This comment has been minimized.

@zackw

zackw Apr 13, 2017

Contributor

I believe that is incorrect. See how _print, immediately above, is marked stable, not unstable(print_internal)?

@zackw

zackw Apr 13, 2017

Contributor

I believe that is incorrect. See how _print, immediately above, is marked stable, not unstable(print_internal)?

This comment has been minimized.

@ollie27

ollie27 Apr 13, 2017

Contributor

Well strictly speaking the import for _print shouldn't be marked stable but I don't think stability attributes on imports have any effect anyway so I guess it doesn't really matter.

@ollie27

ollie27 Apr 13, 2017

Contributor

Well strictly speaking the import for _print shouldn't be marked stable but I don't think stability attributes on imports have any effect anyway so I guess it doesn't really matter.

This comment has been minimized.

@alexcrichton

alexcrichton Apr 13, 2017

Member

Stability on pub use is ignored, it's just advisory for readers.

@alexcrichton

alexcrichton Apr 13, 2017

Member

Stability on pub use is ignored, it's just advisory for readers.

Show outdated Hide outdated src/libstd/macros.rs
///
/// Panics if writing to `io::stderr` fails.
#[macro_export]
#[unstable(feature = "eprint", issue="40528")]

This comment has been minimized.

@ollie27

ollie27 Apr 13, 2017

Contributor

I'm pretty sure stability attributes don't apply the macro_rules macros so these should be stable.

@ollie27

ollie27 Apr 13, 2017

Contributor

I'm pretty sure stability attributes don't apply the macro_rules macros so these should be stable.

This comment has been minimized.

@zackw

zackw Apr 13, 2017

Contributor

I dunno if the compiler can enforce it, but it seems worthwhile for documentation reasons anyway?

@zackw

zackw Apr 13, 2017

Contributor

I dunno if the compiler can enforce it, but it seems worthwhile for documentation reasons anyway?

This comment has been minimized.

@ollie27

ollie27 Apr 13, 2017

Contributor

If you can use these marcos in stable rust then why would you want the documentation to say otherwise?

@ollie27

ollie27 Apr 13, 2017

Contributor

If you can use these marcos in stable rust then why would you want the documentation to say otherwise?

This comment has been minimized.

@alexcrichton

alexcrichton Apr 13, 2017

Member

@zackw the test you added has #![feature(eprint)], is that not necessary? (I assumed it was)

If not, let's change this to #[stable] to reflect the (unforutnate) reality.

@alexcrichton

alexcrichton Apr 13, 2017

Member

@zackw the test you added has #![feature(eprint)], is that not necessary? (I assumed it was)

If not, let's change this to #[stable] to reflect the (unforutnate) reality.

Show outdated Hide outdated src/libstd/macros.rs
macro_rules! eprintln {
() => (eprint!("\n"));
($fmt:expr) => (eprint!(concat!($fmt, "\n")));
($fmt:expr, $($arg:tt)*) => (eprint!(concat!($fmt, "\n"), $($arg)*));

This comment has been minimized.

@ollie27

ollie27 Apr 13, 2017

Contributor

This suffers from #30143 just like println and writeln. Maybe the aim was to copy println bug for bug but in case it wasn't, these last two rules can be replaced with ($($arg:tt)*) => (eprint!("{}\n", format_args!($($arg)*))); to get sensible behaviour.

@ollie27

ollie27 Apr 13, 2017

Contributor

This suffers from #30143 just like println and writeln. Maybe the aim was to copy println bug for bug but in case it wasn't, these last two rules can be replaced with ($($arg:tt)*) => (eprint!("{}\n", format_args!($($arg)*))); to get sensible behaviour.

This comment has been minimized.

@zackw

zackw Apr 13, 2017

Contributor

The aim is, in fact, bug-for-bug equivalence with println. If this is to be changed, it should be changed via #30143, for all of the printing macros at once.

@zackw

zackw Apr 13, 2017

Contributor

The aim is, in fact, bug-for-bug equivalence with println. If this is to be changed, it should be changed via #30143, for all of the printing macros at once.

This comment has been minimized.

@ollie27

ollie27 Apr 13, 2017

Contributor

I disagree. The reason println and writeln were not fixed was to avoid breaking existing programs. That isn't a concern here.

@ollie27

ollie27 Apr 13, 2017

Contributor

I disagree. The reason println and writeln were not fixed was to avoid breaking existing programs. That isn't a concern here.

This comment has been minimized.

@alexcrichton

alexcrichton Apr 13, 2017

Member

Thanks for pointing this out @ollie27, @zackw I agree that we should fix this bug while we can, it's always backwards compatible to take the currently implemented strategy.

@alexcrichton

alexcrichton Apr 13, 2017

Member

Thanks for pointing this out @ollie27, @zackw I agree that we should fix this bug while we can, it's always backwards compatible to take the currently implemented strategy.

This comment has been minimized.

@zackw

zackw Apr 20, 2017

Contributor

@ollie27's suggested change to the macro does work, but I am surprised that it works - it appears to be a type error. I am reluctant to do something that may only work by accident. It also appears to have double formatting overhead, which is not desirable. (It is disappointing that macro_rules! macros have no direct way to specify that a particular token tree should be a string literal. Freaking CPP can do this.)

But more importantly, I really do think eprintln should be bug-for-bug compatible with println, because people should be able to go through existing programs and change println to eprintln where appropriate, without thinking about it apart from "should this properly go to stderr?" Again, if this is to be changed, it should be changed for both println and eprintln at the same time.

@zackw

zackw Apr 20, 2017

Contributor

@ollie27's suggested change to the macro does work, but I am surprised that it works - it appears to be a type error. I am reluctant to do something that may only work by accident. It also appears to have double formatting overhead, which is not desirable. (It is disappointing that macro_rules! macros have no direct way to specify that a particular token tree should be a string literal. Freaking CPP can do this.)

But more importantly, I really do think eprintln should be bug-for-bug compatible with println, because people should be able to go through existing programs and change println to eprintln where appropriate, without thinking about it apart from "should this properly go to stderr?" Again, if this is to be changed, it should be changed for both println and eprintln at the same time.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Apr 13, 2017

Member

@bors: r-

( active comments )

Member

alexcrichton commented Apr 13, 2017

@bors: r-

( active comments )

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 20, 2017

Contributor

☔️ The latest upstream changes (presumably #41411) made this pull request unmergeable. Please resolve the merge conflicts.

Contributor

bors commented Apr 20, 2017

☔️ The latest upstream changes (presumably #41411) made this pull request unmergeable. Please resolve the merge conflicts.

@zackw

This comment has been minimized.

Show comment
Hide comment
@zackw

zackw Apr 20, 2017

Contributor

Fixed up the merge conflicts and the stability annotations. For now, have not changed the eprintln! macro - see response to @ollie27 in "outdated review comments" above.

Contributor

zackw commented Apr 20, 2017

Fixed up the merge conflicts and the stability annotations. For now, have not changed the eprintln! macro - see response to @ollie27 in "outdated review comments" above.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Apr 20, 2017

Member

I still personally feel that we should fix #30143 if we can for eprint/eprintln. @ollie27's suggestion works and I believe not accidentally so, so it should be fine to insert. I also don't really think performance is much of an issue here, eprintln! is doing unbuffered writes to stderr which is far more costly than one extra virtual dispatch.

I also disagree that this should have the same bug to make transitioning easier. It's highly unlikely to exhibit #30143 anyway and it's an opportunity to make it more idiomatic Rust by using a format string.

Member

alexcrichton commented Apr 20, 2017

I still personally feel that we should fix #30143 if we can for eprint/eprintln. @ollie27's suggestion works and I believe not accidentally so, so it should be fine to insert. I also don't really think performance is much of an issue here, eprintln! is doing unbuffered writes to stderr which is far more costly than one extra virtual dispatch.

I also disagree that this should have the same bug to make transitioning easier. It's highly unlikely to exhibit #30143 anyway and it's an opportunity to make it more idiomatic Rust by using a format string.

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 23, 2017

Contributor

☔️ The latest upstream changes (presumably #41437) made this pull request unmergeable. Please resolve the merge conflicts.

Contributor

bors commented Apr 23, 2017

☔️ The latest upstream changes (presumably #41437) made this pull request unmergeable. Please resolve the merge conflicts.

@arielb1

This comment has been minimized.

Show comment
Hide comment
@arielb1

arielb1 Apr 25, 2017

Contributor

@zackw & @alexcrichton - is there a decision on the #30143 question?

Contributor

arielb1 commented Apr 25, 2017

@zackw & @alexcrichton - is there a decision on the #30143 question?

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Apr 25, 2017

Member

@zackw do you feel firmly this should be bug-for-bug compatible? If so I can bring this up with the libs team to see what they think as well.

Member

alexcrichton commented Apr 25, 2017

@zackw do you feel firmly this should be bug-for-bug compatible? If so I can bring this up with the libs team to see what they think as well.

@zackw

This comment has been minimized.

Show comment
Hide comment
@zackw

zackw Apr 25, 2017

Contributor

@alexcrichton

It is my considered opinion that either we should implement the bug in eprintln!, or we should fix the bug in println! immediately -- not waiting for 2.0. My logic is thus:

If we believe that the bug in println! cannot be fixed before 2.0, then we believe that there are a nontrivial number of existing programs that depend on the bug. Some unknown fraction of the println! calls in those programs should be calls to eprintln!. People going through those programs to fix up inappropriate printing to stdout should not have to make any other changes at the same time, both for their own sanity and to facilitate code review. Therefore, eprintln! should also exhibit the bug.

On the other hand, if we believe that there is no need for eprintln! to exhibit the bug, then we believe that people going through existing programs to fix up inappropriate printing to stdout will not encounter any println! calls that need changing that rely on the bug. This is only plausible to me if there are, in fact, no println! calls at all that rely on the bug -- and in that case there is no reason not to fix the bug.

Contributor

zackw commented Apr 25, 2017

@alexcrichton

It is my considered opinion that either we should implement the bug in eprintln!, or we should fix the bug in println! immediately -- not waiting for 2.0. My logic is thus:

If we believe that the bug in println! cannot be fixed before 2.0, then we believe that there are a nontrivial number of existing programs that depend on the bug. Some unknown fraction of the println! calls in those programs should be calls to eprintln!. People going through those programs to fix up inappropriate printing to stdout should not have to make any other changes at the same time, both for their own sanity and to facilitate code review. Therefore, eprintln! should also exhibit the bug.

On the other hand, if we believe that there is no need for eprintln! to exhibit the bug, then we believe that people going through existing programs to fix up inappropriate printing to stdout will not encounter any println! calls that need changing that rely on the bug. This is only plausible to me if there are, in fact, no println! calls at all that rely on the bug -- and in that case there is no reason not to fix the bug.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Apr 26, 2017

Member

Ok, in that case let's get some more opinions!

cc @rust-lang/libs

Member

alexcrichton commented Apr 26, 2017

Ok, in that case let's get some more opinions!

cc @rust-lang/libs

@BurntSushi

This comment has been minimized.

Show comment
Hide comment
@BurntSushi

BurntSushi Apr 26, 2017

Member

Even if we don't fix the bug in println!, I don't think we should purposefully reproduce it with eprintln!.

Member

BurntSushi commented Apr 26, 2017

Even if we don't fix the bug in println!, I don't think we should purposefully reproduce it with eprintln!.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Apr 27, 2017

Member

I'm ambivalent, mostly because this seems like a very minor issue. (I personally don't really have a problem with the current println! behavior).

Given that, as far as I know, there aren't any footguns here, I'd personally lean toward matching the "bug" in the new macros. (I have yet to see a compelling argument that this "bug" is problematic, aside from being inconsistent with print!, which we could change to allow arbitrarily literals.)

Member

aturon commented Apr 27, 2017

I'm ambivalent, mostly because this seems like a very minor issue. (I personally don't really have a problem with the current println! behavior).

Given that, as far as I know, there aren't any footguns here, I'd personally lean toward matching the "bug" in the new macros. (I have yet to see a compelling argument that this "bug" is problematic, aside from being inconsistent with print!, which we could change to allow arbitrarily literals.)

@aturon aturon added the I-nominated label May 5, 2017

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon May 5, 2017

Member

Nominating for discussion at the next libs triage (next Tuesday). Sorry for the delay!

Member

aturon commented May 5, 2017

Nominating for discussion at the next libs triage (next Tuesday). Sorry for the delay!

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson May 9, 2017

Contributor

Even if we think the existing println! behavior is undesirable, my inclination is to keep the behavior consistent between println! and eprintln! to reduce the possibility for surprises.

Contributor

brson commented May 9, 2017

Even if we think the existing println! behavior is undesirable, my inclination is to keep the behavior consistent between println! and eprintln! to reduce the possibility for surprises.

@aturon aturon removed the I-nominated label May 9, 2017

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon May 9, 2017

Member

The libs team discussed this at triage, and we are happy for eprint! to mimic print! in this respect. (In general, no one had a clear reason we didn't want this behavior even for print!)

Member

aturon commented May 9, 2017

The libs team discussed this at triage, and we are happy for eprint! to mimic print! in this respect. (In general, no one had a clear reason we didn't want this behavior even for print!)

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton May 9, 2017

Member

@zackw want to rebase the PR and we'll r+?

Member

alexcrichton commented May 9, 2017

@zackw want to rebase the PR and we'll r+?

zackw added some commits Jan 21, 2017

Add `eprint!` and `eprintln!` macros to the prelude.
These are exactly the same as `print!` and `println!` except that
they write to stderr instead of stdout.  Issue #39228.
Revise the eprint(ln)! feature.
 * Factor out the nigh-identical bodies of `_print` and `_eprint` to a helper
   function `print_to` (I was sorely tempted to call it `_doprnt`).
 * Update the issue number for the unstable `eprint` feature.
 * Add entries to the "unstable book" for `eprint` and `eprint_internal`.
 * Style corrections to the documentation.
@zackw

This comment has been minimized.

Show comment
Hide comment
@zackw

zackw May 10, 2017

Contributor

@alexcrichton Rebased now. Let me know if you also want it squashed.

Contributor

zackw commented May 10, 2017

@alexcrichton Rebased now. Let me know if you also want it squashed.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton May 10, 2017

Member

@bors: r+

Thanks @zackw!

Member

alexcrichton commented May 10, 2017

@bors: r+

Thanks @zackw!

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors May 10, 2017

Contributor

📌 Commit 4ab3bcb has been approved by alexcrichton

Contributor

bors commented May 10, 2017

📌 Commit 4ab3bcb has been approved by alexcrichton

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors May 10, 2017

Contributor

⌛️ Testing commit 4ab3bcb with merge 9e9f527...

Contributor

bors commented May 10, 2017

⌛️ Testing commit 4ab3bcb with merge 9e9f527...

bors added a commit that referenced this pull request May 10, 2017

Auto merge of #41192 - zackw:eprintln, r=alexcrichton
Add `eprint!` and `eprintln!` macros to the prelude.

These are exactly the same as `print!` and `println!` except that they write to stderr instead of stdout.  Issues #39228 and #40528; previous PR #39229; accepted RFC rust-lang/rfcs#1869; proposed revision to The Book rust-lang/book#615.

I have _not_ revised this any since the original submission; I will do that later this week.  I wanted to get this PR in place since it's been quite a while since the RFC was merged.

Known outstanding review comments:

* [x] @steveklabnik requested a new chapter for the unstable version of The Book -- please see if the proposed revisions to the second edition cover it.
* [x] @nodakai asked if it were possible to merge the internal methods `_print` and `_eprint` - not completely, since they both refer to different internal globals which we don't want to expose, but I will see if some duplication can be factored out.

Please let me know if I missed anything.
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors May 10, 2017

Contributor

💔 Test failed - status-travis

Contributor

bors commented May 10, 2017

💔 Test failed - status-travis

@zackw

This comment has been minimized.

Show comment
Hide comment
@zackw

zackw May 10, 2017

Contributor

Looks like the new test is failing on emscripten only; there's not enough detail for me to be sure, but I suspect the problem is emscripten doesn't actually have a stderr. Any objection to skipping the test there?

Contributor

zackw commented May 10, 2017

Looks like the new test is failing on emscripten only; there's not enough detail for me to be sure, but I suspect the problem is emscripten doesn't actually have a stderr. Any objection to skipping the test there?

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton May 10, 2017

Member

Oh I think it's just that emscripten can't spawn new processes, you'll probably just want to ignore the test on emscripten

Member

alexcrichton commented May 10, 2017

Oh I think it's just that emscripten can't spawn new processes, you'll probably just want to ignore the test on emscripten

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton May 10, 2017

Member

er didn't mean to close

Member

alexcrichton commented May 10, 2017

er didn't mean to close

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton
Member

alexcrichton commented May 10, 2017

@bors: r+

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors May 10, 2017

Contributor

📌 Commit 72588a2 has been approved by alexcrichton

Contributor

bors commented May 10, 2017

📌 Commit 72588a2 has been approved by alexcrichton

frewsxcv added a commit to frewsxcv/rust that referenced this pull request May 11, 2017

Rollup merge of #41192 - zackw:eprintln, r=alexcrichton
Add `eprint!` and `eprintln!` macros to the prelude.

These are exactly the same as `print!` and `println!` except that they write to stderr instead of stdout.  Issues #39228 and #40528; previous PR #39229; accepted RFC rust-lang/rfcs#1869; proposed revision to The Book rust-lang/book#615.

I have _not_ revised this any since the original submission; I will do that later this week.  I wanted to get this PR in place since it's been quite a while since the RFC was merged.

Known outstanding review comments:

* [x] @steveklabnik requested a new chapter for the unstable version of The Book -- please see if the proposed revisions to the second edition cover it.
* [x] @nodakai asked if it were possible to merge the internal methods `_print` and `_eprint` - not completely, since they both refer to different internal globals which we don't want to expose, but I will see if some duplication can be factored out.

Please let me know if I missed anything.

bors added a commit that referenced this pull request May 11, 2017

Auto merge of #41901 - frewsxcv:rollup, r=frewsxcv
Rollup of 10 pull requests

- Successful merges: #41192, #41684, #41724, #41843, #41863, #41864, #41873, #41877, #41889, #41900
- Failed merges:

frewsxcv added a commit to frewsxcv/rust that referenced this pull request May 11, 2017

Rollup merge of #41192 - zackw:eprintln, r=alexcrichton
Add `eprint!` and `eprintln!` macros to the prelude.

These are exactly the same as `print!` and `println!` except that they write to stderr instead of stdout.  Issues #39228 and #40528; previous PR #39229; accepted RFC rust-lang/rfcs#1869; proposed revision to The Book rust-lang/book#615.

I have _not_ revised this any since the original submission; I will do that later this week.  I wanted to get this PR in place since it's been quite a while since the RFC was merged.

Known outstanding review comments:

* [x] @steveklabnik requested a new chapter for the unstable version of The Book -- please see if the proposed revisions to the second edition cover it.
* [x] @nodakai asked if it were possible to merge the internal methods `_print` and `_eprint` - not completely, since they both refer to different internal globals which we don't want to expose, but I will see if some duplication can be factored out.

Please let me know if I missed anything.

bors added a commit that referenced this pull request May 11, 2017

Auto merge of #41905 - frewsxcv:rollup, r=frewsxcv
Rollup of 5 pull requests

- Successful merges: #41192, #41724, #41873, #41877, #41889
- Failed merges:
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors May 11, 2017

Contributor

⌛️ Testing commit 72588a2 with merge 24ea08e...

Contributor

bors commented May 11, 2017

⌛️ Testing commit 72588a2 with merge 24ea08e...

@bors bors merged commit 72588a2 into rust-lang:master May 11, 2017

1 of 2 checks passed

homu Testing commit 72588a2 with merge 24ea08e...
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@zackw zackw deleted the zackw:eprintln branch May 11, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment