Question:
The crater run for merged doctests () detected a large number of regressions due to tests examining the process arguments. (I don't have an exact number, but let's say ~50 projects.) Previously, there were no arguments, but now it gets arguments like which the user's CLI parsing code isn't expecting. For example, using something like  will now fail. It seems to be fairly common to have objects whose default constructor will parse the arguments from the command line. I'm not sure if or how we should resolve that. One idea is to use a different mechanism for passing in the test information (like via an environment variable).
I vaguely remember that using environment variables was discussed but can't find anything except mentioning it . Maybe it'd be a better approach indeed. Let me send a PR so we can make a crater run on it.

use std::path::PathBuf; pub static BINARY_PATH: OnceLock<PathBuf> = OnceLock::new(); <del> pub const RUN_OPTION: &str = "*doctest-inner-test"; pub const BIN_OPTION: &str = "*doctest-bin-path"; </del> <ins> pub const RUN_OPTION: &str = "RUSTDOC_DOCTEST_RUN_NB_TEST"; </ins> #[allow(unused)] pub fn doctest_path() -> Option<&'static PathBuf> {{


Question:
The crater run for merged doctests () detected a large number of regressions due to tests examining the process arguments. (I don't have an exact number, but let's say ~50 projects.) Previously, there were no arguments, but now it gets arguments like which the user's CLI parsing code isn't expecting. For example, using something like  will now fail. It seems to be fairly common to have objects whose default constructor will parse the arguments from the command line. I'm not sure if or how we should resolve that. One idea is to use a different mechanism for passing in the test information (like via an environment variable).
I vaguely remember that using environment variables was discussed but can't find anything except mentioning it . Maybe it'd be a better approach indeed. Let me send a PR so we can make a crater run on it.

#[allow(unused)] pub fn doctest_runner(bin: &std::path::Path, test_nb: usize) -> Result<(), String> {{ let out = std::process::Command::new(bin) <del> .arg(self::RUN_OPTION) .arg(test_nb.to_string()) </del> <ins> .env(self::RUN_OPTION, test_nb.to_string()) .args(std::env::args().skip(1).collect::<Vec<_>>()) </ins> .output() .expect("failed to run command"); if !out.status.success() {{


Question:
The crater run for merged doctests () detected a large number of regressions due to tests examining the process arguments. (I don't have an exact number, but let's say ~50 projects.) Previously, there were no arguments, but now it gets arguments like which the user's CLI parsing code isn't expecting. For example, using something like  will now fail. It seems to be fairly common to have objects whose default constructor will parse the arguments from the command line. I'm not sure if or how we should resolve that. One idea is to use a different mechanism for passing in the test information (like via an environment variable).
I vaguely remember that using environment variables was discussed but can't find anything except mentioning it . Maybe it'd be a better approach indeed. Let me send a PR so we can make a crater run on it.

#[rustc_main] fn main() -> std::process::ExitCode {{ const TESTS: [test::TestDescAndFn; {nb_tests}] = [{ids}]; <del> let bin_marker = std::ffi::OsStr::new(__doctest_mod::BIN_OPTION); </del> let test_marker = std::ffi::OsStr::new(__doctest_mod::RUN_OPTION); let test_args = &[{test_args}]; <ins> const ENV_BIN: &'static str = "RUSTDOC_DOCTEST_BIN_PATH"; </ins> <del> let mut args = std::env::args_os().skip(1); while let Some(arg) = args.next() {{ if arg == bin_marker {{ let Some(binary) = args.next() else {{ panic!("missing argument after `{{}}`", __doctest_mod::BIN_OPTION); }}; if crate::__doctest_mod::BINARY_PATH.set(binary.into()).is_err() {{ panic!("`{{}}` option was used more than once", bin_marker.to_string_lossy()); }} return std::process::Termination::report(test::test_main(test_args, Vec::from(TESTS), None)); }} else if arg == test_marker {{ let Some(nb_test) = args.next() else {{ panic!("missing argument after `{{}}`", __doctest_mod::RUN_OPTION); }}; if let Some(nb_test) = nb_test.to_str().and_then(|nb| nb.parse::<usize>().ok()) {{ if let Some(test) = TESTS.get(nb_test) {{ if let test::StaticTestFn(f) = test.testfn {{ return std::process::Termination::report(f()); }} </del> <ins> if let Ok(binary) = std::env::var(ENV_BIN) {{ let _ = crate::__doctest_mod::BINARY_PATH.set(binary.into()); unsafe {{ std::env::remove_var(ENV_BIN); }} return std::process::Termination::report(test::test_main(test_args, Vec::from(TESTS), None)); }} else if let Ok(nb_test) = std::env::var(__doctest_mod::RUN_OPTION) {{ if let Ok(nb_test) = nb_test.parse::<usize>() {{ if let Some(test) = TESTS.get(nb_test) {{ if let test::StaticTestFn(f) = test.testfn {{ return std::process::Termination::report(f()); </ins> }} }} <del> panic!("Unexpected value after `{{}}`", __doctest_mod::RUN_OPTION); </del> }} <ins> panic!("Unexpected value for `{{}}`", __doctest_mod::RUN_OPTION); </ins> }} <del> eprintln!("WARNING: No argument provided so doctests will be run in the same process"); </del> <ins> eprintln!("WARNING: No rustdoc doctest environment variable provided so doctests will be run in  the same process"); </ins> std::process::Termination::report(test::test_main(test_args, Vec::from(TESTS), None)) }}", nb_tests = self.nb_tests,


Question:
In <https://rust- identified the root cause of (unnecessary stage 1 cargo rebuilds) being The other instance of this is As (thank you so much) pointed out: I tried to limit application of to and binary wrappers in themselves, and unfortunately this leads to two cargo test failures: <details<summaryPrevious history</summaryI'm putting up a PR () to remove conditionally adding , and as we expect two cargo tests to be broken with if that is unconditionally passed to bootstrap. I don't know if this breaks someone's workflow regarding to piping cargo tool tests, but in the interest of not making everyone rebuild stage1 cargo on every single invocation of , I'm considering this as "known breakage" for the time being. As suggested: </details
cc team in case anyone has any advice regarding these two tests.
cc if you have any advice since this was in for (it didn't occur to me that adding would cause build cache invalidation problems), presumably to workaround the cargo test failures.
Thanks for the ping. Unfortunately I currently do not have the time to look into this.
No worries that is fine, pinged just in case you had immediate context or advice.
Maybe we should only run those two tests in rust-lang/cargo CI?
Can you give some more context? What are the benefits and drawbacks of ? What does that look like to the user of and ? I don't quite understand . It looks like it regresses something, but I'm not clear what. If it is breaking cargo tests, how is it possible for that PR to land? It seems like removing would be regressing whatever issue it was to fix in the first place, but I don't know what that is.
The linked PR does not break Cargo tests, it possibly breaks someone's contributor workflow that relies on bootstrap implicitly setting . Bootstrap can't implicitly set that flag for everything, or it breaks Cargo's tests. The bug here is that none of the numerous people who looked at the original PR (including me) noticed that the right thing to do here is not set the flag at all, because inconsistent flag-setting creates spurious rebuilds.
Yeah sorry I didn't know how to word the issue title accurately (please rename this issue if there's an more accurate description), will remove conditionally passed flags passed to cargo from bootstrap, which might break someone's workflow related to running cargo tool tests through bootstrap if they wanted to do something like (AFAICT) because now we don't pass at all, but unconditionally setting will cause the aforementioned test failures. EDIT: I tried to fixup the issue description and title to be more accurate.
Sorry, I'm still not clear what is being changed or what is being proposed. Also, sorry for many questions, but I don't have context on what is going on. What happens after when someone does ? What happened before? Is the concern after specifically about , or is it all bootstrap commands? Some of them? Does change the dist artifacts? If so, how? How much of this is specific to using versus using and ? Is there an original issue related to bootstrap workflows that initiated the introduction of ? Who is asking for a different behavior? Looking at , it seems like this stems back to . How does rustc now handle sigpipe? My naive thinking is that removing causes that to regress, but it doesn't seem like that is what you are proposing, and clearly no tests are being broken. But I don't see how all these pieces fit together.
only affects the entry point. Setting it on libraries is useless. I think could be used to add flags that only effect the final build and not any dependency.
... Actually thanks for asking these questions, it seems that simply removing these flags to fix rebuilds will regress rustc (and probably rustdoc) behavior with respect to broken pipes. rustc will ICE locally (e.g. , i.e. reintroduces ) without being built with that flag being set. The context is that I was trying to make not have to rebuild stage1 cargo even if nothing changed, because was not universally applied to tool builds (specifically excluding cargo), which causes tool build cache invalidation because stage1 cargo has to be rebuilt due to the differing flags. I will revert , investigate why regression test for rustc doesn't catch the broken pipe ICE, and reinvestigate what is going on with .
Apparently it does, I'm putting up a revert now. This unfortunately affects how itself is built. This was originally related to where we changed from the in-source attribute of UI to a command-line UI , so they were in an attempt to preserve the existing behavior of kill process if pipe is broken, instead of panicking (and possibly leading to an ICE for rustc specifically). Apparently through that flag when the main binary is being built. AFAICT your suspicions are correct, and indeed removing the flag will regress that. I don't know why no tests are being broken, which probably means no tests were actually exercising this behavior.
I tried to do some digging, and here's what I came up with. Note: the following investigation is to the best of my understanding and most likely contains inaccuracies and misleading representations, reader discretion is required In , the UI of changed to become an unstable rustc flag (cf. stabilization comment ). corresponds to . Not setting will default to . Note that this default behavior will lead to panic in Rust programs if the pipe is broken (e.g in a simple program ). For rustc binary it means the unexpected panic will be caught by the ICE handler manifesting in an ICE . For other tools like rustdoc or cargo it depends on how unexpected panics are handled, but nothing good. removed from rustc and rustdoc (i.e. from their binaries), and set to preserve kill-process-on-broken-pipe behavior to not have the panics and ICEs. Before was available, was addressed by adding a sigpipe handler in rustcdriver explicitly, as done in . But this was changed in for rustc and in for rustdoc to use which was intended to be a more reusable mechanism. Now removed attribute meaning that those flags are load-bearing, for building rustc and rustdoc binaries. Cargo might not be affected itself if it uses its own sigpipe handling, but I have not investigated that specifically.In to help with , we addedIn we moved being set only for tool build from to to help mitigate rebuilds for Miri tests (because setting only for rustdoc means if you build another tool, the tool build cache will get invalidated due to differing ). Note that this particular instance of is for tool builds and cargo, there is a different instance of for building the rustc binary itself in . Conditionally omitting for cargo itself does not cause tool build cache invalidation before (and ) because we were simply using bootstrap cargo (or rather, in bootstrap terms) and not try to build stage 1 cargo ourselves. Only tests want to build stage 1 cargo, even miri tests just use initial cargo. Now that tests builds stage 1 cargo, the omitted for cargo tool build specifically will lead to tool build cache invalidation due to differing . Note that I don't fully understand how tool build caches work and why differing for one of the tools can lead to tool build cache invalidation for all of the tools built from the same stage compiler.I tried to remove both instances of : The instance in : this I suspect was intended for binary. Now I think I understand I cannot remove this flag, because to at least binary I believe is load-bearing for kill-process-on-broken-pipe behavior due to UI changes to command-line flag as aforementioned. Not sure how cargo tests are affected, which is why the flag is not unconditionally always set in the first place. The instance in : this I definitely should not have removed because as I described previously is now load-bearing for the binary for kill-process-on-broken-pipe, otherwise it will reintroduce . I intend to revert now that I have a better understanding of why these flags are even there in the first place, and not having the flags set regresses broken-pipe behavior for and at the minimum. This effect includes dist builds of them so I practically introduced a P-critical regression to and if not also for other tools. I intend to try unconditionally set for all tool builds in so that (1) it preserves desired kill-process-on-broken-pipe behavior for and other tools that are typical of cli tools and (2) it should not cause tool build cache invalidation because it is not conditionally absent from cargo. I intend to investigate/fix a few things: Work with T-cargo and T-bootstrap to figure out why some cargo tests may fail on and either fix those tests and/or fix how cargo is building itself. Investigate why zero tests failed in full CI and locally, in both rustc and rustdoc test suites, even if I reintroduce the ICE for rustc and a similar panic for rustdoc. I intend to add regression tests for and for this behavior specifically, or fix the existing tests that didn't test what they intended to test.
I tried to update PR title and PR description to better reflect the current understanding regarding the two cargo test failures related to changing where is applied in bootstrap.

cmd.args(lint_flags.split_whitespace()); } <ins> // Conditionally pass `-Zon-broken-pipe=kill` to underlying rustc. Not all binaries want // `-Zon-broken-pipe=kill`, which includes cargo itself. if env::var_os("FORCE_ON_BROKEN_PIPE_KILL").is_some() { cmd.arg("-Z").arg("on-broken-pipe=kill"); } </ins> if target.is_some() { // The stage0 compiler has a special sysroot distinct from what we // actually downloaded, so we just always pass the `--sysroot` option,


Question:
In <https://rust- identified the root cause of (unnecessary stage 1 cargo rebuilds) being The other instance of this is As (thank you so much) pointed out: I tried to limit application of to and binary wrappers in themselves, and unfortunately this leads to two cargo test failures: <details<summaryPrevious history</summaryI'm putting up a PR () to remove conditionally adding , and as we expect two cargo tests to be broken with if that is unconditionally passed to bootstrap. I don't know if this breaks someone's workflow regarding to piping cargo tool tests, but in the interest of not making everyone rebuild stage1 cargo on every single invocation of , I'm considering this as "known breakage" for the time being. As suggested: </details
cc team in case anyone has any advice regarding these two tests.
cc if you have any advice since this was in for (it didn't occur to me that adding would cause build cache invalidation problems), presumably to workaround the cargo test failures.
Thanks for the ping. Unfortunately I currently do not have the time to look into this.
No worries that is fine, pinged just in case you had immediate context or advice.
Maybe we should only run those two tests in rust-lang/cargo CI?
Can you give some more context? What are the benefits and drawbacks of ? What does that look like to the user of and ? I don't quite understand . It looks like it regresses something, but I'm not clear what. If it is breaking cargo tests, how is it possible for that PR to land? It seems like removing would be regressing whatever issue it was to fix in the first place, but I don't know what that is.
The linked PR does not break Cargo tests, it possibly breaks someone's contributor workflow that relies on bootstrap implicitly setting . Bootstrap can't implicitly set that flag for everything, or it breaks Cargo's tests. The bug here is that none of the numerous people who looked at the original PR (including me) noticed that the right thing to do here is not set the flag at all, because inconsistent flag-setting creates spurious rebuilds.
Yeah sorry I didn't know how to word the issue title accurately (please rename this issue if there's an more accurate description), will remove conditionally passed flags passed to cargo from bootstrap, which might break someone's workflow related to running cargo tool tests through bootstrap if they wanted to do something like (AFAICT) because now we don't pass at all, but unconditionally setting will cause the aforementioned test failures. EDIT: I tried to fixup the issue description and title to be more accurate.
Sorry, I'm still not clear what is being changed or what is being proposed. Also, sorry for many questions, but I don't have context on what is going on. What happens after when someone does ? What happened before? Is the concern after specifically about , or is it all bootstrap commands? Some of them? Does change the dist artifacts? If so, how? How much of this is specific to using versus using and ? Is there an original issue related to bootstrap workflows that initiated the introduction of ? Who is asking for a different behavior? Looking at , it seems like this stems back to . How does rustc now handle sigpipe? My naive thinking is that removing causes that to regress, but it doesn't seem like that is what you are proposing, and clearly no tests are being broken. But I don't see how all these pieces fit together.
only affects the entry point. Setting it on libraries is useless. I think could be used to add flags that only effect the final build and not any dependency.
... Actually thanks for asking these questions, it seems that simply removing these flags to fix rebuilds will regress rustc (and probably rustdoc) behavior with respect to broken pipes. rustc will ICE locally (e.g. , i.e. reintroduces ) without being built with that flag being set. The context is that I was trying to make not have to rebuild stage1 cargo even if nothing changed, because was not universally applied to tool builds (specifically excluding cargo), which causes tool build cache invalidation because stage1 cargo has to be rebuilt due to the differing flags. I will revert , investigate why regression test for rustc doesn't catch the broken pipe ICE, and reinvestigate what is going on with .
Apparently it does, I'm putting up a revert now. This unfortunately affects how itself is built. This was originally related to where we changed from the in-source attribute of UI to a command-line UI , so they were in an attempt to preserve the existing behavior of kill process if pipe is broken, instead of panicking (and possibly leading to an ICE for rustc specifically). Apparently through that flag when the main binary is being built. AFAICT your suspicions are correct, and indeed removing the flag will regress that. I don't know why no tests are being broken, which probably means no tests were actually exercising this behavior.
I tried to do some digging, and here's what I came up with. Note: the following investigation is to the best of my understanding and most likely contains inaccuracies and misleading representations, reader discretion is required In , the UI of changed to become an unstable rustc flag (cf. stabilization comment ). corresponds to . Not setting will default to . Note that this default behavior will lead to panic in Rust programs if the pipe is broken (e.g in a simple program ). For rustc binary it means the unexpected panic will be caught by the ICE handler manifesting in an ICE . For other tools like rustdoc or cargo it depends on how unexpected panics are handled, but nothing good. removed from rustc and rustdoc (i.e. from their binaries), and set to preserve kill-process-on-broken-pipe behavior to not have the panics and ICEs. Before was available, was addressed by adding a sigpipe handler in rustcdriver explicitly, as done in . But this was changed in for rustc and in for rustdoc to use which was intended to be a more reusable mechanism. Now removed attribute meaning that those flags are load-bearing, for building rustc and rustdoc binaries. Cargo might not be affected itself if it uses its own sigpipe handling, but I have not investigated that specifically.In to help with , we addedIn we moved being set only for tool build from to to help mitigate rebuilds for Miri tests (because setting only for rustdoc means if you build another tool, the tool build cache will get invalidated due to differing ). Note that this particular instance of is for tool builds and cargo, there is a different instance of for building the rustc binary itself in . Conditionally omitting for cargo itself does not cause tool build cache invalidation before (and ) because we were simply using bootstrap cargo (or rather, in bootstrap terms) and not try to build stage 1 cargo ourselves. Only tests want to build stage 1 cargo, even miri tests just use initial cargo. Now that tests builds stage 1 cargo, the omitted for cargo tool build specifically will lead to tool build cache invalidation due to differing . Note that I don't fully understand how tool build caches work and why differing for one of the tools can lead to tool build cache invalidation for all of the tools built from the same stage compiler.I tried to remove both instances of : The instance in : this I suspect was intended for binary. Now I think I understand I cannot remove this flag, because to at least binary I believe is load-bearing for kill-process-on-broken-pipe behavior due to UI changes to command-line flag as aforementioned. Not sure how cargo tests are affected, which is why the flag is not unconditionally always set in the first place. The instance in : this I definitely should not have removed because as I described previously is now load-bearing for the binary for kill-process-on-broken-pipe, otherwise it will reintroduce . I intend to revert now that I have a better understanding of why these flags are even there in the first place, and not having the flags set regresses broken-pipe behavior for and at the minimum. This effect includes dist builds of them so I practically introduced a P-critical regression to and if not also for other tools. I intend to try unconditionally set for all tool builds in so that (1) it preserves desired kill-process-on-broken-pipe behavior for and other tools that are typical of cli tools and (2) it should not cause tool build cache invalidation because it is not conditionally absent from cargo. I intend to investigate/fix a few things: Work with T-cargo and T-bootstrap to figure out why some cargo tests may fail on and either fix those tests and/or fix how cargo is building itself. Investigate why zero tests failed in full CI and locally, in both rustc and rustdoc test suites, even if I reintroduce the ICE for rustc and a similar panic for rustdoc. I intend to add regression tests for and for this behavior specifically, or fix the existing tests that didn't test what they intended to test.
I tried to update PR title and PR description to better reflect the current understanding regarding the two cargo test failures related to changing where is applied in bootstrap.

cargo.rustdocflag("-Zcrate-attr=warn(rust_2018_idioms)"); <del> // If the rustc output is piped to e.g. `head -n1` we want the process to be // killed, rather than having an error bubble up and cause a panic. </del> <ins> // If the rustc output is piped to e.g. `head -n1` we want the process to be killed, rather than // having an error bubble up and cause a panic. // // FIXME(jieyouxu): this flag is load-bearing for rustc to not ICE on broken pipes, because // rustc internally sometimes uses std `println!` -- but std `println!` by default will panic on // broken pipes, and uncaught panics will manifest as an ICE. The compiler *should* handle this // properly, but this flag is set in the meantime to paper over the I/O errors. // // See <https://github.com/rust-lang/rust/issues/131059> for details. // // Also see the discussion for properly handling I/O errors related to broken pipes, i.e. safe // variants of `println!` in // <https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Internal.20lint.20for.20raw.20.60print!.60.20and.20.60println!.60.3F>. </ins> cargo.rustflag("-Zon-broken-pipe=kill"); if builder.config.llvm_enzyme {


Question:
In <https://rust- identified the root cause of (unnecessary stage 1 cargo rebuilds) being The other instance of this is As (thank you so much) pointed out: I tried to limit application of to and binary wrappers in themselves, and unfortunately this leads to two cargo test failures: <details<summaryPrevious history</summaryI'm putting up a PR () to remove conditionally adding , and as we expect two cargo tests to be broken with if that is unconditionally passed to bootstrap. I don't know if this breaks someone's workflow regarding to piping cargo tool tests, but in the interest of not making everyone rebuild stage1 cargo on every single invocation of , I'm considering this as "known breakage" for the time being. As suggested: </details
cc team in case anyone has any advice regarding these two tests.
cc if you have any advice since this was in for (it didn't occur to me that adding would cause build cache invalidation problems), presumably to workaround the cargo test failures.
Thanks for the ping. Unfortunately I currently do not have the time to look into this.
No worries that is fine, pinged just in case you had immediate context or advice.
Maybe we should only run those two tests in rust-lang/cargo CI?
Can you give some more context? What are the benefits and drawbacks of ? What does that look like to the user of and ? I don't quite understand . It looks like it regresses something, but I'm not clear what. If it is breaking cargo tests, how is it possible for that PR to land? It seems like removing would be regressing whatever issue it was to fix in the first place, but I don't know what that is.
The linked PR does not break Cargo tests, it possibly breaks someone's contributor workflow that relies on bootstrap implicitly setting . Bootstrap can't implicitly set that flag for everything, or it breaks Cargo's tests. The bug here is that none of the numerous people who looked at the original PR (including me) noticed that the right thing to do here is not set the flag at all, because inconsistent flag-setting creates spurious rebuilds.
Yeah sorry I didn't know how to word the issue title accurately (please rename this issue if there's an more accurate description), will remove conditionally passed flags passed to cargo from bootstrap, which might break someone's workflow related to running cargo tool tests through bootstrap if they wanted to do something like (AFAICT) because now we don't pass at all, but unconditionally setting will cause the aforementioned test failures. EDIT: I tried to fixup the issue description and title to be more accurate.
Sorry, I'm still not clear what is being changed or what is being proposed. Also, sorry for many questions, but I don't have context on what is going on. What happens after when someone does ? What happened before? Is the concern after specifically about , or is it all bootstrap commands? Some of them? Does change the dist artifacts? If so, how? How much of this is specific to using versus using and ? Is there an original issue related to bootstrap workflows that initiated the introduction of ? Who is asking for a different behavior? Looking at , it seems like this stems back to . How does rustc now handle sigpipe? My naive thinking is that removing causes that to regress, but it doesn't seem like that is what you are proposing, and clearly no tests are being broken. But I don't see how all these pieces fit together.
only affects the entry point. Setting it on libraries is useless. I think could be used to add flags that only effect the final build and not any dependency.
... Actually thanks for asking these questions, it seems that simply removing these flags to fix rebuilds will regress rustc (and probably rustdoc) behavior with respect to broken pipes. rustc will ICE locally (e.g. , i.e. reintroduces ) without being built with that flag being set. The context is that I was trying to make not have to rebuild stage1 cargo even if nothing changed, because was not universally applied to tool builds (specifically excluding cargo), which causes tool build cache invalidation because stage1 cargo has to be rebuilt due to the differing flags. I will revert , investigate why regression test for rustc doesn't catch the broken pipe ICE, and reinvestigate what is going on with .
Apparently it does, I'm putting up a revert now. This unfortunately affects how itself is built. This was originally related to where we changed from the in-source attribute of UI to a command-line UI , so they were in an attempt to preserve the existing behavior of kill process if pipe is broken, instead of panicking (and possibly leading to an ICE for rustc specifically). Apparently through that flag when the main binary is being built. AFAICT your suspicions are correct, and indeed removing the flag will regress that. I don't know why no tests are being broken, which probably means no tests were actually exercising this behavior.
I tried to do some digging, and here's what I came up with. Note: the following investigation is to the best of my understanding and most likely contains inaccuracies and misleading representations, reader discretion is required In , the UI of changed to become an unstable rustc flag (cf. stabilization comment ). corresponds to . Not setting will default to . Note that this default behavior will lead to panic in Rust programs if the pipe is broken (e.g in a simple program ). For rustc binary it means the unexpected panic will be caught by the ICE handler manifesting in an ICE . For other tools like rustdoc or cargo it depends on how unexpected panics are handled, but nothing good. removed from rustc and rustdoc (i.e. from their binaries), and set to preserve kill-process-on-broken-pipe behavior to not have the panics and ICEs. Before was available, was addressed by adding a sigpipe handler in rustcdriver explicitly, as done in . But this was changed in for rustc and in for rustdoc to use which was intended to be a more reusable mechanism. Now removed attribute meaning that those flags are load-bearing, for building rustc and rustdoc binaries. Cargo might not be affected itself if it uses its own sigpipe handling, but I have not investigated that specifically.In to help with , we addedIn we moved being set only for tool build from to to help mitigate rebuilds for Miri tests (because setting only for rustdoc means if you build another tool, the tool build cache will get invalidated due to differing ). Note that this particular instance of is for tool builds and cargo, there is a different instance of for building the rustc binary itself in . Conditionally omitting for cargo itself does not cause tool build cache invalidation before (and ) because we were simply using bootstrap cargo (or rather, in bootstrap terms) and not try to build stage 1 cargo ourselves. Only tests want to build stage 1 cargo, even miri tests just use initial cargo. Now that tests builds stage 1 cargo, the omitted for cargo tool build specifically will lead to tool build cache invalidation due to differing . Note that I don't fully understand how tool build caches work and why differing for one of the tools can lead to tool build cache invalidation for all of the tools built from the same stage compiler.I tried to remove both instances of : The instance in : this I suspect was intended for binary. Now I think I understand I cannot remove this flag, because to at least binary I believe is load-bearing for kill-process-on-broken-pipe behavior due to UI changes to command-line flag as aforementioned. Not sure how cargo tests are affected, which is why the flag is not unconditionally always set in the first place. The instance in : this I definitely should not have removed because as I described previously is now load-bearing for the binary for kill-process-on-broken-pipe, otherwise it will reintroduce . I intend to revert now that I have a better understanding of why these flags are even there in the first place, and not having the flags set regresses broken-pipe behavior for and at the minimum. This effect includes dist builds of them so I practically introduced a P-critical regression to and if not also for other tools. I intend to try unconditionally set for all tool builds in so that (1) it preserves desired kill-process-on-broken-pipe behavior for and other tools that are typical of cli tools and (2) it should not cause tool build cache invalidation because it is not conditionally absent from cargo. I intend to investigate/fix a few things: Work with T-cargo and T-bootstrap to figure out why some cargo tests may fail on and either fix those tests and/or fix how cargo is building itself. Investigate why zero tests failed in full CI and locally, in both rustc and rustdoc test suites, even if I reintroduce the ICE for rustc and a similar panic for rustdoc. I intend to add regression tests for and for this behavior specifically, or fix the existing tests that didn't test what they intended to test.
I tried to update PR title and PR description to better reflect the current understanding regarding the two cargo test failures related to changing where is applied in bootstrap.

// See https://github.com/rust-lang/rust/issues/116538 cargo.rustflag("-Zunstable-options"); <del> // `-Zon-broken-pipe=kill` breaks cargo tests </del> <ins> // NOTE: The root cause of needing `-Zon-broken-pipe=kill` in the first place is because `rustc` // and `rustdoc` doesn't gracefully handle I/O errors due to usages of raw std `println!` macros // which panics upon encountering broken pipes. `-Zon-broken-pipe=kill` just papers over that // and stops rustc/rustdoc ICEing on e.g. `rustc --print=sysroot | false`. // // cargo explicitly does not want the `-Zon-broken-pipe=kill` paper because it does actually use // variants of `println!` that handles I/O errors gracefully. It's also a breaking change for a // spawn process not written in Rust, especially if the language default handler is not // `SIG_IGN`. Thankfully cargo tests will break if we do set the flag. // // For the cargo discussion, see // <https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Applying.20.60-Zon-broken-pipe.3Dkill.60.20flags.20in.20bootstrap.3F>. // // For the rustc discussion, see // <https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Internal.20lint.20for.20raw.20.60print!.60.20and.20.60println!.60.3F> // for proper solutions. </ins> if !path.ends_with("cargo") { <del> // If the output is piped to e.g. `head -n1` we want the process to be killed, // rather than having an error bubble up and cause a panic. cargo.rustflag("-Zon-broken-pipe=kill"); </del> <ins> // Use an untracked env var `FORCE_ON_BROKEN_PIPE_KILL` here instead of `RUSTFLAGS`. // `RUSTFLAGS` is tracked by cargo. Conditionally omitting `-Zon-broken-pipe=kill` from // `RUSTFLAGS` causes unnecessary tool rebuilds due to cache invalidation from building e.g. // cargo *without* `-Zon-broken-pipe=kill` but then rustdoc *with* `-Zon-broken-pipe=kill`. cargo.env("FORCE_ON_BROKEN_PIPE_KILL", "-Zon-broken-pipe=kill"); </ins> } cargo


Question:
In <https://rust- identified the root cause of (unnecessary stage 1 cargo rebuilds) being The other instance of this is As (thank you so much) pointed out: I tried to limit application of to and binary wrappers in themselves, and unfortunately this leads to two cargo test failures: <details<summaryPrevious history</summaryI'm putting up a PR () to remove conditionally adding , and as we expect two cargo tests to be broken with if that is unconditionally passed to bootstrap. I don't know if this breaks someone's workflow regarding to piping cargo tool tests, but in the interest of not making everyone rebuild stage1 cargo on every single invocation of , I'm considering this as "known breakage" for the time being. As suggested: </details
cc team in case anyone has any advice regarding these two tests.
cc if you have any advice since this was in for (it didn't occur to me that adding would cause build cache invalidation problems), presumably to workaround the cargo test failures.
Thanks for the ping. Unfortunately I currently do not have the time to look into this.
No worries that is fine, pinged just in case you had immediate context or advice.
Maybe we should only run those two tests in rust-lang/cargo CI?
Can you give some more context? What are the benefits and drawbacks of ? What does that look like to the user of and ? I don't quite understand . It looks like it regresses something, but I'm not clear what. If it is breaking cargo tests, how is it possible for that PR to land? It seems like removing would be regressing whatever issue it was to fix in the first place, but I don't know what that is.
The linked PR does not break Cargo tests, it possibly breaks someone's contributor workflow that relies on bootstrap implicitly setting . Bootstrap can't implicitly set that flag for everything, or it breaks Cargo's tests. The bug here is that none of the numerous people who looked at the original PR (including me) noticed that the right thing to do here is not set the flag at all, because inconsistent flag-setting creates spurious rebuilds.
Yeah sorry I didn't know how to word the issue title accurately (please rename this issue if there's an more accurate description), will remove conditionally passed flags passed to cargo from bootstrap, which might break someone's workflow related to running cargo tool tests through bootstrap if they wanted to do something like (AFAICT) because now we don't pass at all, but unconditionally setting will cause the aforementioned test failures. EDIT: I tried to fixup the issue description and title to be more accurate.
Sorry, I'm still not clear what is being changed or what is being proposed. Also, sorry for many questions, but I don't have context on what is going on. What happens after when someone does ? What happened before? Is the concern after specifically about , or is it all bootstrap commands? Some of them? Does change the dist artifacts? If so, how? How much of this is specific to using versus using and ? Is there an original issue related to bootstrap workflows that initiated the introduction of ? Who is asking for a different behavior? Looking at , it seems like this stems back to . How does rustc now handle sigpipe? My naive thinking is that removing causes that to regress, but it doesn't seem like that is what you are proposing, and clearly no tests are being broken. But I don't see how all these pieces fit together.
only affects the entry point. Setting it on libraries is useless. I think could be used to add flags that only effect the final build and not any dependency.
... Actually thanks for asking these questions, it seems that simply removing these flags to fix rebuilds will regress rustc (and probably rustdoc) behavior with respect to broken pipes. rustc will ICE locally (e.g. , i.e. reintroduces ) without being built with that flag being set. The context is that I was trying to make not have to rebuild stage1 cargo even if nothing changed, because was not universally applied to tool builds (specifically excluding cargo), which causes tool build cache invalidation because stage1 cargo has to be rebuilt due to the differing flags. I will revert , investigate why regression test for rustc doesn't catch the broken pipe ICE, and reinvestigate what is going on with .
Apparently it does, I'm putting up a revert now. This unfortunately affects how itself is built. This was originally related to where we changed from the in-source attribute of UI to a command-line UI , so they were in an attempt to preserve the existing behavior of kill process if pipe is broken, instead of panicking (and possibly leading to an ICE for rustc specifically). Apparently through that flag when the main binary is being built. AFAICT your suspicions are correct, and indeed removing the flag will regress that. I don't know why no tests are being broken, which probably means no tests were actually exercising this behavior.
I tried to do some digging, and here's what I came up with. Note: the following investigation is to the best of my understanding and most likely contains inaccuracies and misleading representations, reader discretion is required In , the UI of changed to become an unstable rustc flag (cf. stabilization comment ). corresponds to . Not setting will default to . Note that this default behavior will lead to panic in Rust programs if the pipe is broken (e.g in a simple program ). For rustc binary it means the unexpected panic will be caught by the ICE handler manifesting in an ICE . For other tools like rustdoc or cargo it depends on how unexpected panics are handled, but nothing good. removed from rustc and rustdoc (i.e. from their binaries), and set to preserve kill-process-on-broken-pipe behavior to not have the panics and ICEs. Before was available, was addressed by adding a sigpipe handler in rustcdriver explicitly, as done in . But this was changed in for rustc and in for rustdoc to use which was intended to be a more reusable mechanism. Now removed attribute meaning that those flags are load-bearing, for building rustc and rustdoc binaries. Cargo might not be affected itself if it uses its own sigpipe handling, but I have not investigated that specifically.In to help with , we addedIn we moved being set only for tool build from to to help mitigate rebuilds for Miri tests (because setting only for rustdoc means if you build another tool, the tool build cache will get invalidated due to differing ). Note that this particular instance of is for tool builds and cargo, there is a different instance of for building the rustc binary itself in . Conditionally omitting for cargo itself does not cause tool build cache invalidation before (and ) because we were simply using bootstrap cargo (or rather, in bootstrap terms) and not try to build stage 1 cargo ourselves. Only tests want to build stage 1 cargo, even miri tests just use initial cargo. Now that tests builds stage 1 cargo, the omitted for cargo tool build specifically will lead to tool build cache invalidation due to differing . Note that I don't fully understand how tool build caches work and why differing for one of the tools can lead to tool build cache invalidation for all of the tools built from the same stage compiler.I tried to remove both instances of : The instance in : this I suspect was intended for binary. Now I think I understand I cannot remove this flag, because to at least binary I believe is load-bearing for kill-process-on-broken-pipe behavior due to UI changes to command-line flag as aforementioned. Not sure how cargo tests are affected, which is why the flag is not unconditionally always set in the first place. The instance in : this I definitely should not have removed because as I described previously is now load-bearing for the binary for kill-process-on-broken-pipe, otherwise it will reintroduce . I intend to revert now that I have a better understanding of why these flags are even there in the first place, and not having the flags set regresses broken-pipe behavior for and at the minimum. This effect includes dist builds of them so I practically introduced a P-critical regression to and if not also for other tools. I intend to try unconditionally set for all tool builds in so that (1) it preserves desired kill-process-on-broken-pipe behavior for and other tools that are typical of cli tools and (2) it should not cause tool build cache invalidation because it is not conditionally absent from cargo. I intend to investigate/fix a few things: Work with T-cargo and T-bootstrap to figure out why some cargo tests may fail on and either fix those tests and/or fix how cargo is building itself. Investigate why zero tests failed in full CI and locally, in both rustc and rustdoc test suites, even if I reintroduce the ICE for rustc and a similar panic for rustdoc. I intend to add regression tests for and for this behavior specifically, or fix the existing tests that didn't test what they intended to test.
I tried to update PR title and PR description to better reflect the current understanding regarding the two cargo test failures related to changing where is applied in bootstrap.

<ins> //! Check that `rustc` and `rustdoc` does not ICE upon encountering a broken pipe due to unhandled //! panics from raw std `println!` usages. //! //! Regression test for <https://github.com/rust-lang/rust/issues/34376>. //@ ignore-cross-compile (needs to run test binary) #![feature(anonymous_pipe)] use std::io::Read; use std::process::{Command, Stdio}; use run_make_support::env_var; #[derive(Debug, PartialEq)] enum Binary { Rustc, Rustdoc, } fn check_broken_pipe_handled_gracefully(bin: Binary, mut cmd: Command) { let (reader, writer) = std::pipe::pipe().unwrap(); drop(reader); // close read-end cmd.stdout(writer).stderr(Stdio::piped()); let mut child = cmd.spawn().unwrap(); let mut stderr = String::new(); child.stderr.as_mut().unwrap().read_to_string(&mut stderr).unwrap(); let status = child.wait().unwrap(); assert!(!status.success(), "{bin:?} unexpectedly succeeded"); const PANIC_ICE_EXIT_CODE: i32 = 101; #[cfg(not(windows))] { // On non-Windows, rustc/rustdoc built with `-Zon-broken-pipe=kill` shouldn't have an exit // code of 101 because it should have an wait status that corresponds to SIGPIPE signal // number. assert_ne!(status.code(), Some(PANIC_ICE_EXIT_CODE), "{bin:?}"); // And the stderr should be empty because rustc/rustdoc should've gotten killed. assert!(stderr.is_empty(), "{bin:?} stderr:n{}", stderr); } #[cfg(windows)] { match bin { // On Windows, rustc has a paper that propagates the panic exit code of 101 but converts // broken pipe errors into fatal errors instead of ICEs. Binary::Rustc => { assert_eq!(status.code(), Some(PANIC_ICE_EXIT_CODE), "{bin:?}"); // But make sure it doesn't manifest as an ICE. assert!(!stderr.contains("internal compiler error"), "{bin:?} ICE'd"); } // On Windows, rustdoc seems to cleanly exit with exit code of 1. Binary::Rustdoc => { assert_eq!(status.code(), Some(1), "{bin:?}"); assert!(!stderr.contains("panic"), "{bin:?} stderr contains panic"); } } } } fn main() { let mut rustc = Command::new(env_var("RUSTC")); rustc.arg("--print=sysroot"); check_broken_pipe_handled_gracefully(Binary::Rustc, rustc); let mut rustdoc = Command::new(env_var("RUSTDOC")); rustdoc.arg("--version"); check_broken_pipe_handled_gracefully(Binary::Rustdoc, rustdoc); } </ins>


Question:
I am getting this on each invocation now, since very recently: This is in my main checkout, not in a worktree, so I am not quite sure what could even be so unusual about my setup that causes an error here. Cc
A bisect points at That's I am surprised about the date of this PR, I think I would have noticed this earlier if this happened for a month... so probably some other factor is also involved. Cc
It seems to try to read which indeed is not a file that exists here. I also noticed this line in So maybe checking these files is just futile since git doesn't always use a file to track these refs?
I think what happened is that has been run, and that indeed cleans up most of the files from . So the current approach in bootstrap of looking at these files is not reliable. IMO we should instead look at the commit date of the most recent commit in that branch. That also avoids having to directly mess with git's internal files.
yeah, i'm gonna accept defeat on this one. is kinda slow on my device, but only if the relevant files aren't in the i/o cache, and building rust takes a good while anyways.
is not the case anymore since . I am planning to revert and as they are not really required.
Seems like it will still be the case if upstream was configured and too old. But that could be fixed in a much better way (e.g., we could ignore upstream commit and use merge commit in current branch) compare to and

if !verify_rustfmt_version(build) { return Ok(None); } get_git_modified_files(&build.config.git_config(), Some(&build.config.src), &["rs"]) }


Question:
I am getting this on each invocation now, since very recently: This is in my main checkout, not in a worktree, so I am not quite sure what could even be so unusual about my setup that causes an error here. Cc
A bisect points at That's I am surprised about the date of this PR, I think I would have noticed this earlier if this happened for a month... so probably some other factor is also involved. Cc
It seems to try to read which indeed is not a file that exists here. I also noticed this line in So maybe checking these files is just futile since git doesn't always use a file to track these refs?
I think what happened is that has been run, and that indeed cleans up most of the files from . So the current approach in bootstrap of looking at these files is not reliable. IMO we should instead look at the commit date of the most recent commit in that branch. That also avoids having to directly mess with git's internal files.
yeah, i'm gonna accept defeat on this one. is kinda slow on my device, but only if the relevant files aren't in the i/o cache, and building rust takes a good while anyways.
is not the case anymore since . I am planning to revert and as they are not really required.
Seems like it will still be the case if upstream was configured and too old. But that could be fixed in a much better way (e.g., we could ignore upstream commit and use merge commit in current branch) compare to and

use std::path::PathBuf; use std::{env, fs}; <del> use build_helper::git::warn_old_master_branch; </del> use crate::Build; #[cfg(not(feature = "bootstrap-self-test"))] use crate::builder::Builder;


Question:
I am getting this on each invocation now, since very recently: This is in my main checkout, not in a worktree, so I am not quite sure what could even be so unusual about my setup that causes an error here. Cc
A bisect points at That's I am surprised about the date of this PR, I think I would have noticed this earlier if this happened for a month... so probably some other factor is also involved. Cc
It seems to try to read which indeed is not a file that exists here. I also noticed this line in So maybe checking these files is just futile since git doesn't always use a file to track these refs?
I think what happened is that has been run, and that indeed cleans up most of the files from . So the current approach in bootstrap of looking at these files is not reliable. IMO we should instead look at the commit date of the most recent commit in that branch. That also avoids having to directly mess with git's internal files.
yeah, i'm gonna accept defeat on this one. is kinda slow on my device, but only if the relevant files aren't in the i/o cache, and building rust takes a good while anyways.
is not the case anymore since . I am planning to revert and as they are not really required.
Seems like it will still be the case if upstream was configured and too old. But that could be fixed in a much better way (e.g., we could ignore upstream commit and use merge commit in current branch) compare to and

if let Some(ref s) = build.config.ccache { cmd_finder.must_have(s); } <del> warn_old_master_branch(&build.config.git_config(), &build.config.src); </del> }


Question:
I am getting this on each invocation now, since very recently: This is in my main checkout, not in a worktree, so I am not quite sure what could even be so unusual about my setup that causes an error here. Cc
A bisect points at That's I am surprised about the date of this PR, I think I would have noticed this earlier if this happened for a month... so probably some other factor is also involved. Cc
It seems to try to read which indeed is not a file that exists here. I also noticed this line in So maybe checking these files is just futile since git doesn't always use a file to track these refs?
I think what happened is that has been run, and that indeed cleans up most of the files from . So the current approach in bootstrap of looking at these files is not reliable. IMO we should instead look at the commit date of the most recent commit in that branch. That also avoids having to directly mess with git's internal files.
yeah, i'm gonna accept defeat on this one. is kinda slow on my device, but only if the relevant files aren't in the i/o cache, and building rust takes a good while anyways.
is not the case anymore since . I am planning to revert and as they are not really required.
Seems like it will still be the case if upstream was configured and too old. But that could be fixed in a much better way (e.g., we could ignore upstream commit and use merge commit in current branch) compare to and

.collect(); Ok(Some(files)) } <del> /// Print a warning if the branch returned from `updated_master_branch` is old /// /// For certain configurations of git repository, this remote will not be /// updated when running `git pull`. /// /// This can result in formatting thousands of files instead of a dozen, /// so we should warn the user something is wrong. pub fn warn_old_master_branch(config: &GitConfig<'_>, git_dir: &Path) { if crate::ci::CiEnv::is_ci() { // this warning is useless in CI, // and CI probably won't have the right branches anyway. return; } // this will be overwritten by the actual name, if possible let mut updated_master = "the upstream master branch".to_string(); match warn_old_master_branch_(config, git_dir, &mut updated_master) { Ok(branch_is_old) => { if !branch_is_old { return; } // otherwise fall through and print the rest of the warning } Err(err) => { eprintln!("warning: unable to check if {updated_master} is old due to error: {err}") } } eprintln!( "warning: {updated_master} is used to determine if files have been modifiedn warning: if it is not updated, this may cause files to be needlessly reformatted" ); } pub fn warn_old_master_branch_( config: &GitConfig<'_>, git_dir: &Path, updated_master: &mut String, ) -> Result<bool, Box<dyn std::error::Error>> { use std::time::Duration; *updated_master = updated_master_branch(config, Some(git_dir))?; let branch_path = git_dir.join(".git/refs/remotes").join(&updated_master); const WARN_AFTER: Duration = Duration::from_secs(60 * 60 * 24 * 10); let meta = match std::fs::metadata(&branch_path) { Ok(meta) => meta, Err(err) => { let gcd = git_common_dir(&git_dir)?; if branch_path.starts_with(&gcd) { return Err(Box::new(err)); } std::fs::metadata(Path::new(&gcd).join("refs/remotes").join(&updated_master))? } }; if meta.modified()?.elapsed()? > WARN_AFTER { eprintln!("warning: {updated_master} has not been updated in 10 days"); Ok(true) } else { Ok(false) } } fn git_common_dir(dir: &Path) -> Result<String, String> { output_result(Command::new("git").arg("-C").arg(dir).arg("rev-parse").arg("--git-common-dir")) .map(|x| x.trim().to_string()) } </del>


Question:
It seems that the prefix is used more often than , so we should swap the function names before 0.1.
We're probably going the other direction -
Done.

}, Primitive::F32 => types::F32, Primitive::F64 => types::F64, <del> Primitive::Pointer => pointer_ty(tcx), </del> <ins> // FIXME(erikdesjardins): handle non-default addrspace ptr sizes Primitive::Pointer(_) => pointer_ty(tcx), </ins> } }


Question:
It seems that the prefix is used more often than , so we should swap the function names before 0.1.
We're probably going the other direction -
Done.

pub(crate) use cpuid::codegen_cpuid_call; pub(crate) use llvm::codegen_llvm_intrinsic_call; <ins> use rustc_middle::ty::layout::HasParamEnv; </ins> use rustc_middle::ty::print::with_no_trimmed_paths; use rustc_middle::ty::subst::SubstsRef; use rustc_span::symbol::{kw, sym, Symbol};


Question:
It seems that the prefix is used more often than , so we should swap the function names before 0.1.
We're probably going the other direction -
Done.

return; } <del> if intrinsic == sym::assert_zero_valid && !fx.tcx.permits_zero_init(layout) { </del> <ins> if intrinsic == sym::assert_zero_valid && !fx.tcx.permits_zero_init(fx.param_env().and(layout)) { </ins> with_no_trimmed_paths!({ crate::base::codegen_panic( fx,


Question:
It seems that the prefix is used more often than , so we should swap the function names before 0.1.
We're probably going the other direction -
Done.

} if intrinsic == sym::assert_mem_uninitialized_valid <del> && !fx.tcx.permits_uninit_init(layout) </del> <ins> && !fx.tcx.permits_uninit_init(fx.param_env().and(layout)) </ins> { with_no_trimmed_paths!({ crate::base::codegen_panic(


Question:
It seems that the prefix is used more often than , so we should swap the function names before 0.1.
We're probably going the other direction -
Done.

is_main_fn: bool, sigpipe: u8, ) { <del> let main_ret_ty = tcx.fn_sig(rust_main_def_id).output(); </del> <ins> let main_ret_ty = tcx.bound_fn_sig(rust_main_def_id).subst_identity().output(); </ins> // Given that `main()` has no arguments, // then its return type cannot have // late-bound regions, since late-bound


Question:
Yes, really
It looks like this is 2640 bytes of lovecraft quotes in each exectuable (out of , 0.56%). Perhaps it's not so bad?
2k is pretty bad, because a hello world binary should be ~10k at most. It's not the lowest hanging fruit right now but it will become a bigger fish as we fix the other problems. I think it's an indication of a larger issue rather than being a problem itself though...
I think there is no defensible reason to have that text in every executable.
And thus poetry was killed...
Not particularly new - and
2K? So that's what 2014 is about?
If you want Rust to be taken seriously as a systems language, you have to worry about that. It's not acceptable in many embedded environments for binaries to be this large. It makes the language unusable without writing the entire standard library again. It's fine for it to be in the standard libraries... just not every binary linking against them.
Should be fine until other sources of bloat are removed.
The problem here isn't the quotes, it's that the code containing the quotes is used or considered used at all. It's the canary in the coal mine. I'm sure we can cut down the runtime overhead to something much smaller, including getting rid of this.
It's not unreasonable for it to be considered used, considering it's part of the abort code, so even a trivial program might trigger it (e.g. on OOM, stack corruption, etc). Personally I'd add a no_horrors cfg option or something to disable it in the rare cases where 2k is considered important, unless the potential for user confusion is considered to great to keep the behaviour at all.
It's not rare for people to compare the size of the binaries to C and decide against using Rust for their use case due to it being very unfavourable. You shouldn't have to compile Rust again to disable debugging features useful only to the developers. This is only the runtime abort code, it's not the generic which isn't even a function call. Runtime errors should report real errors, and logic errors should be dealt with by improving the code so redundant checks aren't necessary in the normal release builds. It can remain around in a build that's not for regular end users... the code paths calling this just need some work to remove the need for debugging stuff.
Yeah but I love it though :( Hehe.
I also love it, but it's more important to be professional and chuck it out. Let's not make this Rust's equivalent to TPAAMAYIMNEKUDOTAYIM. Easter eggs are fun, but they have to have literally zero impact on users.
The key question isn't "is 2K big or small". The key question is "what value does this add".
Keeping these as default isn't very professional for many reasons, but I think value would be lost if lightheartedness was removed from Rust as a continuing policy. I've been amazed at how many people become interested in the language after I link them the abort in question. A human touch to the compiler output goes a long way. How about a '-fun' flag that enables easter eggs being compiled in?
Sounds a bit ridiculous tbh. The point of an easter egg is to have it everywhere, not to compile it purposefully.
Perhaps, but I'd argue the main point of an easter egg is to be entertainingly surprising. A flag enabling them wouldn't give away when they happen, just discourage unpleasant surprises. for a compiler. Another option would be to strip the messages when optimizations are enabled. -O equals -nofun.
That's funny, wordy and mawkish. "what value does this add"? Nothing. I'd vote +1 to remove them entirely.
Besides Lovecraft, I see tons of text obviously related to assertion failures and references to my build directory. I assume there is a lot of debugging code left in the compiler and libraries that will eventually get turned off in a production compiler, yes?
Am I the only one that's going to bring up copyright issues? I work for a company that thoroughly reviews code with lawyers that will ban any and all uses of software that are even questionable in terms of their license or copyright issues. You might claim embedding these quotes (and without attribution) is fair use etc, but all it takes is for one of my company's lawyers to disagree with your conclusion and suddenly Rust is banned from use in the company. I understand and appreciate the value of having some fun with a project, but these quotes: unnecessary overhead to executable size and memory (and yes, in real life I work on embedded systems where a few k can make a difference). potential users because a zealous lawyer has concerns regarding the quotes and bans Rust "just to be safe".
Lovecraft's works are basically public domain, it's not a problem.
To be fair, pretty sure copyright is the wrong case to make. Lovecraft's works are in the public domain. Edit: Dang, Steve beat me to it.
Won't the embedded environments you speak of use libcore?
True, but (but I probably should have been more specific because this issue specifically mention's Lovecraft's quotes and doesn't mention Zelda quotes). I know I'm being a bit paranoid here when I bring up copyright stuff, but I'm not kidding when I mention zealous lawyers laying down strict rules...
This is only the opinion of a user on the outside looking in, but I'm not sure there's any sensible reason for this being in-- at best it's a waste of space and code, and at worst having Lovecraft spouted during an could be seen by the user on the receiving end as being in poor taste. (Speaking from experience a month or two ago, when a build of ed after ages of tring to compile it)
I think that it should remain in. It sort of reminds people who stumble upon this that has indeed been built by real people :-) I also don't think that it is somehow "unprofessional", every program I ever came across has some sort of an easter egg in it,including Git, (starting with its name). Having this compile only with a certain opt in flag kind of defeats the purpose, but maybe a flag that can explicitly opt out of this kind of thing is worth having for embedded developers. There's no sensible reason apart from having some fun, I think that's enough of a reason, but opinions will differ.
It's not part of , it's part of the runtime and is included in every Rust program without . An easter egg like this in is different than putting it in every Rust program.
I suggest its removal simply be the christening commit of 1.0-stable.
yesssss
To those of you saying "2k, in 2014?" I will point out that there are a lot of platforms out there where 2k is still a big deal. If Rust is going to work for embedded systems work, you can't pull tricks like this.
those would not be using Rust's runtime anyway, and so would not have this in it.
Why should we have poetry in a binary executable generated by a supposedly serious, non-esoteric programming language? One would think this wouldn't even need to be a discussion...........
that is not necessarily true. As I understand, the runtime is getting slimmer and slimmer with every RFC.
aye. To my tastes, this sort of easter egg belongs in the compiler/toolchain, not a statically linked stdlib.
True, it probably shouldn't be part of the runtime.
An embedded gag that only comes up when the program is frustrating the user with a catastrophic error?
Honestly, as someone outside the Rust community, seeing this puts me off using the language. I'm a Lovecraft fan, and if this was an easter egg in the toolchain I would love it, but embedding this statically into all the binaries I ship to end users is a step too far. There's a lot of negative interpretations a snooping end-user could get from finding these quotes talking about things dying and gods in the binaries (and running on a binary isn't exactly difficult). That negative interpretation would fall on me, who they see as the developer, not the Rust team, who they probably don't even know exists. Rust is a tool. If my table saw has a tiny inscription on the underside with the name of the engineer who designed it - that's neat, a fun homage, and overall great. If my table saw contains a tiny router that engraves that engineer's name onto every piece of wood I cut with it - not so great. It degrades the quality of the tool. While I appreciate the entertainment value of the quotes, I think moving them into a developer tool like the Rust compiler would maintain that entertainment while also not degrading the quality of Rust by inserting unwanted data in generated binaries.
That's an incredibly fitting analogy. Here are a complete outsider's 2 cents: why not change instead to display a funny (or lighthearted) quote when something goes wrong, to sort of alleviate the pain of having your compilation fail? Of course, it shouldn't get in the way of you solving the issue (or it would be even worse), but if it manages to have some "decorative" value, I think it would be a perfect middle-ground between getting rid of this easter egg entirely or moving it to a more sensible place.
I am very much in favour of removing the quotes. Put the quotes somewhere where humans will read them, not machines

let _ = write!(&mut w, "{}", args); let msg = str::from_utf8(&w.buf[0..w.pos]).unwrap_or("aborted"); let msg = if msg.is_empty() {"aborted"} else {msg}; <del> // Give some context to the message let hash = msg.bytes().fold(0, |accum, val| accum + (val as uint) ); let quote = match hash % 10 { 0 => " It was from the artists and poets that the pertinent answers came, and I know that panic would have broken loose had they been able to compare notes. As it was, lacking their original letters, I half suspected the compiler of having asked leading questions, or of having edited the correspondence in corroboration of what he had latently resolved to see.", 1 => " There are not many persons who know what wonders are opened to them in the stories and visions of their youth; for when as children we listen and dream, we think but half-formed thoughts, and when as men we try to remember, we are dulled and prosaic with the poison of life. But some of us awake in the night with strange phantasms of enchanted hills and gardens, of fountains that sing in the sun, of golden cliffs overhanging murmuring seas, of plains that stretch down to sleeping cities of bronze and stone, and of shadowy companies of heroes that ride caparisoned white horses along the edges of thick forests; and then we know that we have looked back through the ivory gates into that world of wonder which was ours before we were wise and unhappy.", 2 => " Instead of the poems I had hoped for, there came only a shuddering blackness and ineffable loneliness; and I saw at last a fearful truth which no one had ever dared to breathe before — the unwhisperable secret of secrets — The fact that this city of stone and stridor is not a sentient perpetuation of Old New York as London is of Old London and Paris of Old Paris, but that it is in fact quite dead, its sprawling body imperfectly embalmed and infested with queer animate things which have nothing to do with it as it was in life.", 3 => " The ocean ate the last of the land and poured into the smoking gulf, thereby giving up all it had ever conquered. From the new-flooded lands it flowed again, uncovering death and decay; and from its ancient and immemorial bed it trickled loathsomely, uncovering nighted secrets of the years when Time was young and the gods unborn. Above the waves rose weedy remembered spires. The moon laid pale lilies of light on dead London, and Paris stood up from its damp grave to be sanctified with star-dust. Then rose spires and monoliths that were weedy but not remembered; terrible spires and monoliths of lands that men never knew were lands...", 4 => " There was a night when winds from unknown spaces whirled us irresistibly into limitless vacuum beyond all thought and entity. Perceptions of the most maddeningly untransmissible sort thronged upon us; perceptions of infinity which at the time convulsed us with joy, yet which are now partly lost to my memory and partly incapable of presentation to others.", _ => "You've met with a terrible fate, haven't you?" }; rterrln!("{}", ""); rterrln!("{}", quote); rterrln!("{}", ""); </del> rterrln!("fatal runtime error: {}", msg); unsafe { intrinsics::abort(); } }


Question:
See I propose to change the license of Non trivial contributors: OK OK OK (MoCo employee) Contributors appearing in git blame that are trivial (trivial update due to language changes): OK (MoCo employee) OK OK (MoCo employee) OK OK OK OK OK OK (sent agreement to by email) Contributors with removed and trivial contributions are not considered. For the persons that are not in "OK" state, please respond to this issue saying: Then, I'll propose the corresponding PR. Thanks.
I agree to relicense any previous contributions to according to the term of the computer Language Benchmarks Game license (
We don't need statements from Graydon or Marijn as they both contributed as employees. On Jun 7, 2014 5:50 AM, "TeXitoi" wrote:
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()
Op updated. could you please respond?
Citing in a private email: can I consider the contribution of negligible? the same for renaming? If yes I can propose a PR for this and for
guh, I suppose so, though I'm disappointed that didn't cooperate.
My change is obviously trivial and I have zero copyright over anything to do with the shootout benchmarks, but if you must, then: I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()
OP updated. Thanks. I'll wait some days to see if respond to my email.
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()

"libstd/sync/spsc_queue.rs", # BSD "libstd/sync/mpmc_bounded_queue.rs", # BSD "libsync/mpsc_intrusive.rs", # BSD <ins> "test/bench/shootout-binarytrees.rs", # BSD </ins> "test/bench/shootout-fannkuch-redux.rs", # BSD "test/bench/shootout-meteor.rs", # BSD "test/bench/shootout-regex-dna.rs", # BSD


Question:
See I propose to change the license of Non trivial contributors: OK OK OK (MoCo employee) Contributors appearing in git blame that are trivial (trivial update due to language changes): OK (MoCo employee) OK OK (MoCo employee) OK OK OK OK OK OK (sent agreement to by email) Contributors with removed and trivial contributions are not considered. For the persons that are not in "OK" state, please respond to this issue saying: Then, I'll propose the corresponding PR. Thanks.
I agree to relicense any previous contributions to according to the term of the computer Language Benchmarks Game license (
We don't need statements from Graydon or Marijn as they both contributed as employees. On Jun 7, 2014 5:50 AM, "TeXitoi" wrote:
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()
Op updated. could you please respond?
Citing in a private email: can I consider the contribution of negligible? the same for renaming? If yes I can propose a PR for this and for
guh, I suppose so, though I'm disappointed that didn't cooperate.
My change is obviously trivial and I have zero copyright over anything to do with the shootout benchmarks, but if you must, then: I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()
OP updated. Thanks. I'll wait some days to see if respond to my email.
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()

<del> // Copyright 2012-2013 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. </del> <ins> // The Computer Language Benchmarks Game // http://benchmarksgame.alioth.debian.org/ </ins> // <del> // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. </del> <ins> // contributed by the Rust Project Developers // Copyright (c) 2012-2014 The Rust Project Developers // // All rights reserved. // // Redistribution and use in source and binary forms, with or without // modification, are permitted provided that the following conditions // are met: // // - Redistributions of source code must retain the above copyright //   notice, this list of conditions and the following disclaimer. // // - Redistributions in binary form must reproduce the above copyright //   notice, this list of conditions and the following disclaimer in //   the documentation and/or other materials provided with the //   distribution. // // - Neither the name of "The Computer Language Benchmarks Game" nor //   the name of "The Computer Language Shootout Benchmarks" nor the //   names of its contributors may be used to endorse or promote //   products derived from this software without specific prior //   written permission. // // THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS // "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT // LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS // FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE // COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, // INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES // (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR // SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) // HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, // STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) // ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED // OF THE POSSIBILITY OF SUCH DAMAGE. </ins> extern crate sync; extern crate arena;


Question:
Currently, pointers stored on the stack aren't word-aligned. This is a critical issue because it causes stack growth to fail most of the time.
Commit disables task growth for now until this is fixed.
WONTFIX (moot point given disabled stack growth)

rustup toolchain install --profile minimal nightly-${TOOLCHAIN} # Sanity check to see if the nightly exists echo nightly-${TOOLCHAIN} > rust-toolchain <del> echo "=> Uninstalling all old nighlies" </del> <ins> echo "=> Uninstalling all old nightlies" </ins> for nightly in $(rustup toolchain list | grep nightly | grep -v $TOOLCHAIN | grep -v nightly-x86_64); do rustup toolchain uninstall $nightly done


Question:
(sorry about the bad title but I really have no clue what's going on here!) Compiles and prints . I think it's getting at the of the inside a . edit: As one might expect, does not compile.
Seems rather bad. cc
Nominating.
This is a fun bug, it's by far not limited to the operator. I tried to reduce the test case a bit, starting with a new non-operator trait, changed it to a static method that just returns for inference, and...
cc me
Assigning 1.0, P-backcompat-lang.
Even smaller:

} } <del> (&ty::ty_param(ref a_p), &ty::ty_param(ref b_p)) if a_p.idx == b_p.idx => { </del> <ins> (&ty::ty_param(ref a_p), &ty::ty_param(ref b_p)) if a_p.idx == b_p.idx && a_p.space == b_p.space => { </ins> Ok(a) }


Question:
(sorry about the bad title but I really have no clue what's going on here!) Compiles and prints . I think it's getting at the of the inside a . edit: As one might expect, does not compile.
Seems rather bad. cc
Nominating.
This is a fun bug, it's by far not limited to the operator. I tried to reduce the test case a bit, starting with a new non-operator trait, changed it to a static method that just returns for inference, and...
cc me
Assigning 1.0, P-backcompat-lang.
Even smaller:

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. use std::num::Num; trait BrokenAdd: Num { fn broken_add<T>(&self, rhs: T) -> Self { *self + rhs //~ ERROR mismatched types } } impl<T: Num> BrokenAdd for T {} pub fn main() { let foo: u8 = 0u8; let x: u8 = foo.broken_add("hello darkness my old friend".to_string()); println!("{}", x); } </ins>


Question:
(sorry about the bad title but I really have no clue what's going on here!) Compiles and prints . I think it's getting at the of the inside a . edit: As one might expect, does not compile.
Seems rather bad. cc
Nominating.
This is a fun bug, it's by far not limited to the operator. I tried to reduce the test case a bit, starting with a new non-operator trait, changed it to a static method that just returns for inference, and...
cc me
Assigning 1.0, P-backcompat-lang.
Even smaller:

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Tr<T> { fn op(T) -> Self; } // these compile as if Self: Tr<U>, even tho only Self: Tr<Self or T> trait A:    Tr<Self> { fn test<U>(u: U) -> Self { Tr::op(u)   //~ ERROR expected Tr<U>, but found Tr<Self> } } trait B<T>: Tr<T> { fn test<U>(u: U) -> Self { Tr::op(u)   //~ ERROR expected Tr<U>, but found Tr<T> } } impl<T> Tr<T> for T { fn op(t: T) -> T { t } } impl<T> A for T {} fn main() { std::io::println(A::test((&7306634593706211700, 8))); } </ins>


Question:
(sorry about the bad title but I really have no clue what's going on here!) Compiles and prints . I think it's getting at the of the inside a . edit: As one might expect, does not compile.
Seems rather bad. cc
Nominating.
This is a fun bug, it's by far not limited to the operator. I tried to reduce the test case a bit, starting with a new non-operator trait, changed it to a static method that just returns for inference, and...
cc me
Assigning 1.0, P-backcompat-lang.
Even smaller:

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Tr { fn test<X>(u: X) -> Self { u   //~ ERROR mismatched types } } fn main() {} </ins>


Question:
At this point, and both exist. Just in case it matters: my prefix is .
Fallout from , perhaps? This isn’t the first time we’ve had completely broken (two months ago it happened, ). Why don’t we add it to the tests done on the buildbot?
Indeed, this was predicted as a known consequence of . It may be the case that asking people to set is too much. We might need/want wrapper scripts to drive that set up such environment variables, much like other projects have.
Fixed by .
(see comment , since it is relevant to this issue.)

CFG_LIBDIR_RELATIVE=bin fi <ins> if [ "$CFG_OSTYPE" = "pc-mingw32" ] || [ "$CFG_OSTYPE" = "w64-mingw32" ] then CFG_LD_PATH_VAR=PATH CFG_OLD_LD_PATH_VAR=$PATH elif [ "$CFG_OSTYPE" = "Darwin" ] then CFG_LD_PATH_VAR=DYLD_LIBRARY_PATH CFG_OLD_LD_PATH_VAR=$DYLD_LIBRARY_PATH else CFG_LD_PATH_VAR=LD_LIBRARY_PATH CFG_OLD_LD_PATH_VAR=$LD_LIBRARY_PATH fi </ins> flag uninstall "only uninstall from the installation prefix" opt verify 1 "verify that the installed binaries run correctly" valopt prefix "/usr/local" "set installation prefix"


Question:
At this point, and both exist. Just in case it matters: my prefix is .
Fallout from , perhaps? This isn’t the first time we’ve had completely broken (two months ago it happened, ). Why don’t we add it to the tests done on the buildbot?
Indeed, this was predicted as a known consequence of . It may be the case that asking people to set is too much. We might need/want wrapper scripts to drive that set up such environment variables, much like other projects have.
Fixed by .
(see comment , since it is relevant to this issue.)

if [ -z "${CFG_UNINSTALL}" ] then msg "verifying platform can run binaries" <ins> export $CFG_LD_PATH_VAR="${CFG_SRC_DIR}/lib":$CFG_OLD_LD_PATH_VAR </ins> "${CFG_SRC_DIR}/bin/rustc" --version > /dev/null if [ $? -ne 0 ] then err "can't execute rustc binary on this platform" fi <ins> export $CFG_LD_PATH_VAR=$CFG_OLD_LD_PATH_VAR </ins> fi fi


Question:
At this point, and both exist. Just in case it matters: my prefix is .
Fallout from , perhaps? This isn’t the first time we’ve had completely broken (two months ago it happened, ). Why don’t we add it to the tests done on the buildbot?
Indeed, this was predicted as a known consequence of . It may be the case that asking people to set is too much. We might need/want wrapper scripts to drive that set up such environment variables, much like other projects have.
Fixed by .
(see comment , since it is relevant to this issue.)

done < "${CFG_SRC_DIR}/${CFG_LIBDIR_RELATIVE}/rustlib/manifest.in" # Sanity check: can we run the installed binaries? <ins> # # As with the verification above, make sure the right LD_LIBRARY_PATH-equivalent # is in place. Try first without this variable, and if that fails try again with # the variable. If the second time tries, print a hopefully helpful message to # add something to the appropriate environment variable. </ins> if [ -z "${CFG_DISABLE_VERIFY}" ] then msg "verifying installed binaries are executable" <del> "${CFG_PREFIX}/bin/rustc" --version > /dev/null </del> <ins> "${CFG_PREFIX}/bin/rustc" --version 2> /dev/null 1> /dev/null </ins> if [ $? -ne 0 ] then <del> ERR="can't execute installed rustc binary. " ERR="${ERR}installation may be broken. " ERR="${ERR}if this is expected then rerun install.sh with `--disable-verify` " ERR="${ERR}or `make install` with `--disable-verify-install`" err "${ERR}" </del> <ins> export $CFG_LD_PATH_VAR="${CFG_PREFIX}/lib":$CFG_OLD_LD_PATH_VAR "${CFG_PREFIX}/bin/rustc" --version > /dev/null if [ $? -ne 0 ] then ERR="can't execute installed rustc binary. " ERR="${ERR}installation may be broken. " ERR="${ERR}if this is expected then rerun install.sh with `--disable-verify` " ERR="${ERR}or `make install` with `--disable-verify-install`" err "${ERR}" else echo echo "    please ensure '${CFG_PREFIX}/lib' is added to ${CFG_LD_PATH_VAR}" echo fi </ins> fi fi


Question:
At this point, and both exist. Just in case it matters: my prefix is .
Fallout from , perhaps? This isn’t the first time we’ve had completely broken (two months ago it happened, ). Why don’t we add it to the tests done on the buildbot?
Indeed, this was predicted as a known consequence of . It may be the case that asking people to set is too much. We might need/want wrapper scripts to drive that set up such environment variables, much like other projects have.
Fixed by .
(see comment , since it is relevant to this issue.)

TTNonterminal(Span, Ident) } <del> /// Matchers are nodes defined-by and recognized-by the main rust parser and /// language, but they're only ever found inside syntax-extension invocations; /// indeed, the only thing that ever _activates_ the rules in the rust parser /// for parsing a matcher is a matcher looking for the 'matchers' nonterminal /// itself. Matchers represent a small sub-language for pattern-matching /// token-trees, and are thus primarily used by the macro-defining extension /// itself. /// /// MatchTok /// -------- /// ///     A matcher that matches a single token, denoted by the token itself. So ///     long as there's no $ involved. /// /// /// MatchSeq /// -------- /// ///     A matcher that matches a sequence of sub-matchers, denoted various ///     possible ways: /// ///             $(M)*       zero or more Ms ///             $(M)+       one or more Ms ///             $(M),+      one or more comma-separated Ms ///             $(A B C);*  zero or more semi-separated 'A B C' seqs /// /// /// MatchNonterminal /// ----------------- /// ///     A matcher that matches one of a few interesting named rust ///     nonterminals, such as types, expressions, items, or raw token-trees. A ///     black-box matcher on expr, for example, binds an expr to a given ident, ///     and that ident can re-occur as an interpolation in the RHS of a ///     macro-by-example rule. For example: /// ///        $foo:expr   =>     1 + $foo    // interpolate an expr ///        $foo:tt     =>     $foo        // interpolate a token-tree ///        $foo:tt     =>     bar! $foo   // only other valid interpolation ///                                       // is in arg position for another ///                                       // macro /// /// As a final, horrifying aside, note that macro-by-example's input is /// also matched by one of these matchers. Holy self-referential! It is matched /// by a MatchSeq, specifically this one: /// ///                   $( $lhs:matchers => $rhs:tt );+ /// /// If you understand that, you have closed the loop and understand the whole /// macro system. Congratulations. </del> <ins> // Matchers are nodes defined-by and recognized-by the main rust parser and // language, but they're only ever found inside syntax-extension invocations; // indeed, the only thing that ever _activates_ the rules in the rust parser // for parsing a matcher is a matcher looking for the 'matchers' nonterminal // itself. Matchers represent a small sub-language for pattern-matching // token-trees, and are thus primarily used by the macro-defining extension // itself. // // MatchTok // -------- // //     A matcher that matches a single token, denoted by the token itself. So //     long as there's no $ involved. // // // MatchSeq // -------- // //     A matcher that matches a sequence of sub-matchers, denoted various //     possible ways: // //             $(M)*       zero or more Ms //             $(M)+       one or more Ms //             $(M),+      one or more comma-separated Ms //             $(A B C);*  zero or more semi-separated 'A B C' seqs // // // MatchNonterminal // ----------------- // //     A matcher that matches one of a few interesting named rust //     nonterminals, such as types, expressions, items, or raw token-trees. A //     black-box matcher on expr, for example, binds an expr to a given ident, //     and that ident can re-occur as an interpolation in the RHS of a //     macro-by-example rule. For example: // //        $foo:expr   =>     1 + $foo    // interpolate an expr //        $foo:tt     =>     $foo        // interpolate a token-tree //        $foo:tt     =>     bar! $foo   // only other valid interpolation //                                       // is in arg position for another //                                       // macro // // As a final, horrifying aside, note that macro-by-example's input is // also matched by one of these matchers. Holy self-referential! It is matched // by a MatchSeq, specifically this one: // //                   $( $lhs:matchers => $rhs:tt );+ // // If you understand that, you have closed the loop and understand the whole // macro system. Congratulations. </ins> pub type Matcher = Spanned<Matcher_>; #[deriving(Clone, PartialEq, Eq, Encodable, Decodable, Hash)]


Question:
A fixed-length array expression with a repeat count with the high bit set and no suffix is incorrectly treated as a negative count. On a 64-bit machine: This results in
Can be easily fixed after landed
Seems that it is not an issue any more.
I'm thinking that if it behave differently on different platforms, is it making it an undefined behavior? And I think designating an exact behavior for UB cannot possibly be a breaking change?
This does not make it undefined behavior. It's very much defined behavior. If it were undefined behavior, then any or literal would be undefined behavior as well, because the range of valid values is architecture-dependent.

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // error-pattern: too big for the current architecture #[cfg(target_pointer_width = "32")] fn main() { let x = [0usize; 0xffff_ffff]; } #[cfg(target_pointer_width = "64")] fn main() { let x = [0usize; 0xffff_ffff_ffff_ffff]; } </ins>


Question:
We should record the names that users give complex types and use them when we can when reporting diagnostics.
WONTFIX (not require for bootstrapping; works correctly in rustc already).


Question:
fails with vector v.
WONTFIX (not required for bootstrapping, reopen if somehow this re-emerges in rustc)


Question:
On the pull request for (), had a good suggestion for what I think would make a good additional function: "a version of frombytes which doesn't fail on invalid input but rather offers some sort of error recovery options. Like maybe it can return the partly converted string with an index to the invalid position. Or perhaps, a callback function to handle the error, etc." At a glance the easy way to do this would be with a callback to, e.g., drop, replace, or coerce offending sequences into UTF-8 or else return a ... But is this a recipe for complex callbacks? Perhaps providing sensible callback functions like , , , and so on would make this simple enough to use. Maybe those should just be simple functions for whole byte vector conversion, anyways. What do you think?
I don't have a strong opinion about it, but I guess I would prefer to wait until somebody actually needs something like this.
Not RFC-level proposal. Just a library wishlist item. Might accept a patch; but it seems a bit overwrought. Anyone need such a thing yet?
I think this is subsumed in ; we might well adopt a dynamic-handler mechanism while working through that bug. This would be a special case.

<del> Subproject commit 2751bdcef125468ea2ee006c11992cd1405aebe5 </del> <ins> Subproject commit 34fca48ed284525b2f124bf93c51af36d6685492 </ins>


Question:
On the pull request for (), had a good suggestion for what I think would make a good additional function: "a version of frombytes which doesn't fail on invalid input but rather offers some sort of error recovery options. Like maybe it can return the partly converted string with an index to the invalid position. Or perhaps, a callback function to handle the error, etc." At a glance the easy way to do this would be with a callback to, e.g., drop, replace, or coerce offending sequences into UTF-8 or else return a ... But is this a recipe for complex callbacks? Perhaps providing sensible callback functions like , , , and so on would make this simple enough to use. Maybe those should just be simple functions for whole byte vector conversion, anyways. What do you think?
I don't have a strong opinion about it, but I guess I would prefer to wait until somebody actually needs something like this.
Not RFC-level proposal. Just a library wishlist item. Might accept a patch; but it seems a bit overwrought. Anyone need such a thing yet?
I think this is subsumed in ; we might well adopt a dynamic-handler mechanism while working through that bug. This would be a special case.

<del> Subproject commit 388750b081c0893c275044d37203f97709e058ba </del> <ins> Subproject commit e3f3af69dce71cd37a785bccb7e58449197d940c </ins>


Question:
On the pull request for (), had a good suggestion for what I think would make a good additional function: "a version of frombytes which doesn't fail on invalid input but rather offers some sort of error recovery options. Like maybe it can return the partly converted string with an index to the invalid position. Or perhaps, a callback function to handle the error, etc." At a glance the easy way to do this would be with a callback to, e.g., drop, replace, or coerce offending sequences into UTF-8 or else return a ... But is this a recipe for complex callbacks? Perhaps providing sensible callback functions like , , , and so on would make this simple enough to use. Maybe those should just be simple functions for whole byte vector conversion, anyways. What do you think?
I don't have a strong opinion about it, but I guess I would prefer to wait until somebody actually needs something like this.
Not RFC-level proposal. Just a library wishlist item. Might accept a patch; but it seems a bit overwrought. Anyone need such a thing yet?
I think this is subsumed in ; we might well adopt a dynamic-handler mechanism while working through that bug. This would be a special case.

<del> Subproject commit d43038932adeb16ada80e206d4c073d851298101 </del> <ins> Subproject commit ee7c676fd6e287459cb407337652412c990686c0 </ins>


Question:
On the pull request for (), had a good suggestion for what I think would make a good additional function: "a version of frombytes which doesn't fail on invalid input but rather offers some sort of error recovery options. Like maybe it can return the partly converted string with an index to the invalid position. Or perhaps, a callback function to handle the error, etc." At a glance the easy way to do this would be with a callback to, e.g., drop, replace, or coerce offending sequences into UTF-8 or else return a ... But is this a recipe for complex callbacks? Perhaps providing sensible callback functions like , , , and so on would make this simple enough to use. Maybe those should just be simple functions for whole byte vector conversion, anyways. What do you think?
I don't have a strong opinion about it, but I guess I would prefer to wait until somebody actually needs something like this.
Not RFC-level proposal. Just a library wishlist item. Might accept a patch; but it seems a bit overwrought. Anyone need such a thing yet?
I think this is subsumed in ; we might well adopt a dynamic-handler mechanism while working through that bug. This would be a special case.

<del> Subproject commit 07e0df2f006e59d171c6bf3cafa9d61dbeb520d8 </del> <ins> Subproject commit c954202c1e1720cba5628f99543cc01188c7d6fc </ins>


Question:
On the pull request for (), had a good suggestion for what I think would make a good additional function: "a version of frombytes which doesn't fail on invalid input but rather offers some sort of error recovery options. Like maybe it can return the partly converted string with an index to the invalid position. Or perhaps, a callback function to handle the error, etc." At a glance the easy way to do this would be with a callback to, e.g., drop, replace, or coerce offending sequences into UTF-8 or else return a ... But is this a recipe for complex callbacks? Perhaps providing sensible callback functions like , , , and so on would make this simple enough to use. Maybe those should just be simple functions for whole byte vector conversion, anyways. What do you think?
I don't have a strong opinion about it, but I guess I would prefer to wait until somebody actually needs something like this.
Not RFC-level proposal. Just a library wishlist item. Might accept a patch; but it seems a bit overwrought. Anyone need such a thing yet?
I think this is subsumed in ; we might well adopt a dynamic-handler mechanism while working through that bug. This would be a special case.

<del> Subproject commit b123ab4754127d822ffb38349ce0fbf561f1b2fd </del> <ins> Subproject commit 08bb147d51e815b96e8db7ba4cf870f201c11ff8 </ins>