jiebi/CodeConvo huggingface dataset:
Code change:
} #[test] <del> #[cfg_attr(any(target_os = "vxworks", target_os = "android"), ignore)] </del> <ins> #[cfg_attr(any(target_os = "vxworks"), ignore)] </ins> fn test_process_output_output() { let Output { status, stdout, stderr } = if cfg!(target_os = "windows") { Command::new("cmd").args(&["/C", "echo hello"]).output().unwrap() } else { <del> Command::new("echo").arg("hello").output().unwrap() </del> <ins> shell_cmd().arg("-c").arg("echo hello").output().unwrap() </ins> }; let output_str = str::from_utf8(&stdout).unwrap();

Related discussion:
text: To enable test on android bot and test/run-pass/rtio- It looks to me RtioProcess does not work properly on android.
logs are
Hm this may be an FFI issue with libuv. I realized during my uv rewrite that libuv is giving us an int64t exit status and we think it's a cint. Once lands this may be fixed.
Hmm, this issue number has propagated to several more tests that are cfg-disabled on android. (Some of which are now failing when I mixed in a Boehm/BDW conservative GC into the runtime, in particular .)
Also, has landed, so it would be good to determine if these tests now work on Android.
Triage: I have no idea how to test this, but a lot has changed in a year (especially the removal of green & libuv), so these may be magically fixed; if someone can check.
Triage: is gone, but all these tests in are still ignored for android.
I tried to run these tests with but they all failed with , which seems suspect (at least for the tests that invoke , , , etc.). Is there a better way to test? I have an android device available.
Code change:
<ins> #![feature(prelude_import)] #![no_std] // This test certify that we can mix attribute macros from Rust and external proc-macros. // For instance, `#[derive(Default)]` uses `#[default]` and `#[derive(SmartPointer)]` uses // `#[pointee]`. // The scoping rule should allow the use of the said two attributes when external proc-macros // are in scope. //@ check-pass //@ aux-build: another-proc-macro.rs //@ compile-flags: -Zunpretty=expanded #![feature(derive_smart_pointer)] #[prelude_import] use ::std::prelude::rust_2015::*; #[macro_use] extern crate std; #[macro_use] extern crate another_proc_macro; const _: () = { const POINTEE_MACRO_ATTR_DERIVED: () = (); }; const _: () = { const DEFAULT_MACRO_ATTR_DERIVED: () = (); }; </ins>

Related discussion:
text: https://crater- https://crater- cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
label F-derivesmartpointer
Thread on zulip: https://rust-
claim
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
} fn write_u16s(handle: c::HANDLE, data: &[u16]) -> io::Result<usize> { <ins> debug_assert!(data.len() < u32::MAX as usize); </ins> let mut written = 0; cvt(unsafe { c::WriteConsoleW(

Related discussion:
text: (and similarly, should call ) Windows provides these nice functions which performantly implement utf-8 <-utf-16 conversions. We should probably call them in the standard library when possible.
Do we get measurable performance wins that make calling more unsafe C APIs worth it? Especially with the inlining barrier across languages. And I would assume console printing is bottlenecked on the console rendering part anyway, not on string conversions.
Do we have any good benchmarks for console I/O perf?
A simple main writing 100MB worth of lines to stdout and measuring the time it takes should do?
For sure. I was just wondering if we had something already. I mean, we'd probably want to be testing a few different languages as well to make sure we're not just optimizing for ASCII only.
I don't think we do because most benchmarks suppress console output.
I did do a benchmark, and interestingly, ASCII text was about twice as fast with as with rust-native code; however, Chinese text was slightly slower. Given that most of the actual cost of printing to the screen is in the actual printing, I no longer think it's a good idea to do this. See benchmarks at [strega-nil/rust-bench-cvt-utf8-utf16][]. [strega-nil/rust-bench-cvt-utf8-utf16]: Run on M1 chip: someone may want to check on an x64 chip, since that might be faster.
Just to check my understanding: The utf16 conversion only happens when one writes to an actually rendered console. There isn't some stuff like virtual consoles that act more like NUL where speeding up the conversion could help because the data will be discarded by the OS. And output to files is binary anyway.
There are now (since Windows 10, 1809) which are consoles without the rendering part. Though the intent would be for the rendering to be implemented by another program, it would also be possible to skip or delay (e.g. by writing a log) rendering.
In that case a speedup may be useful, but is the optimization potential of the built-in conversion already squeezed dry?
yeah, I think it's unlikely that the complexity is worth it given what the benchmarks show; I would really appreciate if someone ran the benchmark on x64, since it may be that Windows implements faster algorithms on that platform.
Code change:
} fn write_u16s(handle: c::HANDLE, data: &[u16]) -> io::Result<usize> { <ins> debug_assert!(data.len() < u32::MAX as usize); </ins> let mut written = 0; cvt(unsafe { c::WriteConsoleW(

Related discussion:
text: I don't think anyone has worked on optimizing this so I'm sure there's plenty of optimization potential. The results from I got from an AMD Ryzen 5 3600 machine are:
Mmh, thanks I'll also push some benchmarks for testing other cases later, since there are plenty of other cases than just "bulk-converting a bunch of text". Thanks! Nicole
Code change:
/// [`slice_from_raw_parts`]: fn.slice_from_raw_parts.html /// [`from_raw_parts_mut`]: ../../std/slice/fn.from_raw_parts_mut.html #[inline] <del> #[unstable(feature = "slice_from_raw_parts", reason = "recently added", issue = "36925")] </del> <ins> #[stable(feature = "slice_from_raw_parts", since = "1.42.0")] </ins> #[rustc_const_unstable(feature = "const_slice_from_raw_parts", issue = "67456")] pub const fn slice_from_raw_parts_mut<T>(data: *mut T, len: usize) -> *mut [T] { unsafe { Repr { raw: FatPtr { data, len } }.rust_mut }

Related discussion:
text: In stable Rust, the only way to get a with an arbitrary length is through . Unfortunately, that function returns a , which makes it very dubious to use with arbitrary raw pointers.
Given that isn't defined for , what would be the value of being able to create ?
Why would you want one, but also, this seems like it depends on (yet to be decided?) details of the memory model. Is the fleeting moment where a reference exists in enough to invoke UB if the pointer is invalid?
If the reference is , then this is insta-UB for sure.
Is there anything holding [] from stabilizing? If not, I'd like to propose stabilization of these functions, as they are rather simple in concept and allow avoiding manifesting references during (slice) pointer manipulation. cc If I'm reading the various issue threads correctly, the validity invariant of pointer metadata is at max that of the metadata type. For slice pointers, the metadata is typed at . Context: I happen to currently be writing a library that cannot use the reference-based functions, because though the pointers are known to be non-null (and valid), it is not (and cannot be, with the current abstraction) known whether the pointer has unique or shared provenance (thus should use or to be sound). (Specifically, I'm now adding the bits required to handle erasing slice types. I can bifurcate my function into and , but so far, it works fine with one operating over , and it'd be sad to have the / split hanging around even after these functions stabilize (assuming they can)).
I don't recall any reason that cannot be stabilized.
The implementation PR used this feature requested as a tracking issue, but this wasn’t labelled properly. Doing so now.
By the way, would also cover this :)
Code change:
<del> error: expected expression, found reserved keyword `try` --> $DIR/try-block-in-match.rs:6:11 | LL |     match try { false } { _ => {} } |     ----- ^^^ expected expression |     | |     while parsing this match expression error: aborting due to previous error </del>

Related discussion:
text: This produces a lint: But removing the parentheses produces an error. This bug was already mentioned in , but that issue is lost in feature-request purgatory since it asks for the version without parentheses to be allowed. I'm opening this issue to track the incorrect lint specifically. (Edit: Fixed the example.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Will wait for to get merged before this is fixed though.
Code change:
<del> error: expected expression, found reserved keyword `try` --> $DIR/try-block-in-match.rs:6:11 | LL |     match try { false } { _ => {} } |     ----- ^^^ expected expression |     | |     while parsing this match expression error: aborting due to previous error </del>

Related discussion:
text: The following code fails to compile (): The compiler error is: Adding parentheses or braces, it will compile fine: The same issue happens with other constructs such as:
cc
I believe the error is expected here, the same as with : Which also needs to be to compile. That said, the warning to remove the necessary parens is definitely wrong. EDIT: Hmm, I might be wrong, actually. The following compiles, which surprised me: as does this: So maybe the parser restriction is only for struct literals, not for keyword-introduced expressions.
Yeah I think is the better comparison here so it's probably a bug.
This is exactly what a thought. I didn't know that this:
For , hmmm... well, I can't come up with a truly devastating example, but eliminating the parentheses could hurt diagnostics.
Code change:
} #[test] <del> #[cfg_attr(any(target_os = "vxworks", target_os = "android"), ignore)] </del> <ins> #[cfg_attr(any(target_os = "vxworks"), ignore)] </ins> fn stdout_works() { if cfg!(target_os = "windows") { let mut cmd = Command::new("cmd"); cmd.args(&["/C", "echo foobar"]).stdout(Stdio::piped()); assert_eq!(run_output(cmd), "foobarrn"); } else { <del> let mut cmd = Command::new("echo"); cmd.arg("foobar").stdout(Stdio::piped()); </del> <ins> let mut cmd = shell_cmd(); cmd.arg("-c").arg("echo foobar").stdout(Stdio::piped()); </ins> assert_eq!(run_output(cmd), "foobarn"); } } #[test] <del> #[cfg_attr(any(windows, target_os = "android", target_os = "vxworks"), ignore)] </del> <ins> #[cfg_attr(any(windows, target_os = "vxworks"), ignore)] </ins> fn set_current_dir_works() { <del> let mut cmd = Command::new("/bin/sh"); </del> <ins> let mut cmd = shell_cmd(); </ins> cmd.arg("-c").arg("pwd").current_dir("/").stdout(Stdio::piped()); assert_eq!(run_output(cmd), "/n"); } #[test] <del> #[cfg_attr(any(windows, target_os = "android", target_os = "vxworks"), ignore)] </del> <ins> #[cfg_attr(any(windows, target_os = "vxworks"), ignore)] </ins> fn stdin_works() { <del> let mut p = Command::new("/bin/sh") </del> <ins> let mut p = shell_cmd() </ins> .arg("-c") .arg("read line; echo $line") .stdin(Stdio::piped())

Related discussion:
text: To enable test on android bot and test/run-pass/rtio- It looks to me RtioProcess does not work properly on android.
logs are
Hm this may be an FFI issue with libuv. I realized during my uv rewrite that libuv is giving us an int64t exit status and we think it's a cint. Once lands this may be fixed.
Hmm, this issue number has propagated to several more tests that are cfg-disabled on android. (Some of which are now failing when I mixed in a Boehm/BDW conservative GC into the runtime, in particular .)
Also, has landed, so it would be good to determine if these tests now work on Android.
Triage: I have no idea how to test this, but a lot has changed in a year (especially the removal of green & libuv), so these may be magically fixed; if someone can check.
Triage: is gone, but all these tests in are still ignored for android.
I tried to run these tests with but they all failed with , which seems suspect (at least for the tests that invoke , , , etc.). Is there a better way to test? I have an android device available.
Code change:
<ins> // Regression test for #81899. // The `panic!()` below is important to trigger the fixed ICE. const _CONST: &[u8] = &f(&[], |_| {}); const fn f<F>(_: &[u8], _: F) -> &[u8] where F: FnMut(&u8), { panic!() //~ ERROR: evaluation of constant value failed } fn main() {} </ins>

Related discussion:
text: The following code causes compiler panics due to the first line without which the issue isn't reproducible. Calling the function outside of a constant context emits the right compiler errors. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <details<summary<strongBacktrace</strong</summary<p</p</details
FWIW, replacing the function body with still gives an ICE:
Minimized slightly further, without const generics: <details<summarybacktrace</summary</detailsThe ICE occurs back to . In , it errors with By making small changes such as making the closure no longer take paramters or removing the reference at It errors, instead of an ICE, on stable and nightly with
searched nightlies: from nightly-2020-08-16 to nightly-2021-02-03 regressed nightly: nightly-2020-12-28 searched commits: from to regressed commit: edit: for this code sample <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
cc
Just to clarify, AFAICT, this issue is not due to , the stabilization just allowed code with const generics to run into this. MCVE ICEs before and shows that this is a borrowck bug not related to const generics
Assigning as discussed as part of the and removing .
I'm not sure if this is identical problem or not. The error message is: and my code is: I need both parts or the COPY tuple for the error to trigger and I'm unsure why. And also, if I put in its own const the bug is not triggered.
Triage: No longer ICE with the latest nightly, I guess fixed it? Marking as .
Code change:
use rustc_middle::ty::{ self, fold::BottomUpFolder, print::TraitPredPrintModifiersAndPath, Ty, TypeFoldable, }; <del> use rustc_span::Span; </del> <ins> use rustc_span::{symbol::kw, Span}; </ins> use rustc_trait_selection::traits; use rustc_trait_selection::traits::query::evaluate_obligation::InferCtxtExt;

Related discussion:
text: When using the flag, I stumbled upon a warning that I don't understand and assume to be a bug/missed implementation. If this is the intended behavior, could anyone please explain why? This is simplified code that generates the warning: But when adding a type restriction on self (in this case Sized)_ the warning does not appear anymore. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
This is in fact a bug.
Update: This issue is still present, and has now sneaked into stable with the release of ; as such I'm updating the title to reflect that.
This is similar to the bug report
This isn't the same bug. This just has to do with a false warning of the lint.
on this, also encountering this bug
Also encountering with
Code change:
fn the(&self); } } <ins> #[cfg(any())] mod nonexistent_file; // Check that unconfigured non-inline modules are not loaded or parsed. </ins>

Related discussion:
text: This fails on stable because rust still parses the unstable module: It's possible to work around this by conditionally defining a macro and then having the macro define the module but that's a bit messy:
Or implement the module in another file. I think this is a fundamental limitation -- you can't skip forward over an item if you don't understand the syntax that the item is using. The only way we could solve it is with time travel, i.e., doing a point release of stable that knows the syntax but not what it means.
That's actually what I'm doing in my project (still the same problem). That is, I have the following in my : And a module,
Modules are parsed before 's are parsed, which has been an issue for as long as I can remember. Can someone find whether there is an issue tracking this?
Dupe of . cc ( expert!)
Though this'll be fixed by the above PR, the workaround for current stable is
Code change:
fn the(&self); } } <ins> #[cfg(any())] mod nonexistent_file; // Check that unconfigured non-inline modules are not loaded or parsed. </ins>

Related discussion:
text: The ABI string for is validated while being parsed, meaning one can get errors about in 'd off modules: (Compiled without .) This isn't necessarily wrong, but it is weird and somewhat annoying if one needs it. (It can be worked-around by hiding the block behind a macro: .)
Any ideas where we could move the check into? Any of borrowck, typeck, lints, privacy and resolve don’t exactly fit. I think trans thematically is the best place to have it, but it is a shame to have it error out so late for such an easy to detect and obvious error. I’m personally fine keeping it a parse error, IMO there’s no reason to have cfg blocks with code that does not compile.
NB. we can add a special pass if necessary (i.e. there's no reason for us to compromise by putting the error in trans). Yeah, of course. However, there are cases when the d code does compile, e.g. I encountered this in where I an ABI and had to use it in inside a module. Similarly, if we add ABIs in future, someone might have code designed to compile with Rust 1.0.0, but can take advantage of the newer ABI if it is available.
The block might be to gate nightly-only code. The code within the gated block is compiled only when a cargo feature is enabled; the code outside it works both on stable and nightly. I hit it myself; I'm playing with the SIMD work from pull request, but I want to keep the crate working on stable. .
Code change:
(&TestKind::Range { .. }, _) => None, (&TestKind::Eq { .. } | &TestKind::Len { .. }, _) => { <ins> // The call to `self.test(&match_pair)` below is not actually used to generate any // MIR. Instead, we just want to compare with `test` (the parameter of the method) // to see if it is the same. // // However, at this point we can still encounter or-patterns that were extracted // from previous calls to `sort_candidate`, so we need to manually address that // case to avoid panicking in `self.test()`. if let PatKind::Or { .. } = &*match_pair.pattern.kind { return None; } </ins> // These are all binary tests. // // FIXME(#29623) we can be more clever here

Related discussion:
text: When using the feature, attempting to match on a tuple creates a compiler panic. The following code causes the panic. (Also available at the ) This occurs both on the playground and on my local machine on a previous version (details below). Rust version from the playground: Local version: Playground backtrace: Local backtrace: EDIT: Added local machine backtrace too
It looks like the problem is here in . The call to seems to rely on the invariant that the match pairs have been fully simplified at this point, but are a special case and can still show up here.
Reproducible with recent nightlies too: : Triggered by more than 3 pattern condition with this compiler version.
I would have assumed that the implementation merely desugars into a bunch of top-level or-patterns. Is that not the case? Why are tuples special cased? If it isn't too involved, I could take a crack at this with some guidance... very much want to see this over the finish line.
Code change:
<ins> error: this file contains an un-closed delimiter --> $DIR/issue-58094-missing-right-square-bracket.rs:4:4 | LL | #[Ѕ |  - ^ |  | |  un-closed delimiter error: expected item after attributes --> $DIR/issue-58094-missing-right-square-bracket.rs:4:4 | LL | #[Ѕ |    ^ error: aborting due to 2 previous errors </ins>

Related discussion:
text: Reproduction branch: When applying the change from the last commit I get a panic in my code during the call to . <details<summaryBacktrace</summary</details
Cannot reproduce on my linux. Can you provide a small ? Is that possible? Maybe without all the externals :/
I can reproduce a very similar problem (appears to involve the same origin and failing assertion of ) compiling rust-lang/regex with and compiler flags: For me, setting to 2 or greater is required to present this failure. <details<summarybacktrace</summary<code<preRUSTBACKTRACE=1 cargo build Compiling regex v1.1.2 (/home/kent/rust/regex) thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at 2: std::panicking::defaulthook::{{closure}} at at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::beginpanic 7: syntax::sourcemap::SourceMap::bytepostofilecharpos 8: syntax::sourcemap::SourceMap::lookupcharpos 9: <rustccodegenssa::mir::FunctionCx<'a, 'tcx, Bx::scopemetadataforloc 10: <rustccodegenssa::mir::FunctionCx<'a, 'tcx,
Code change:
<ins> error: this file contains an un-closed delimiter --> $DIR/issue-58094-missing-right-square-bracket.rs:4:4 | LL | #[Ѕ |  - ^ |  | |  un-closed delimiter error: expected item after attributes --> $DIR/issue-58094-missing-right-square-bracket.rs:4:4 | LL | #[Ѕ |    ^ error: aborting due to 2 previous errors </ins>

Related discussion:
text: Bx::debugloc 11: rustccodegenssa::mir::codegenmir 12: rustccodegenssa::base::codegeninstance 13: rustccodegenssa::monoitem::MonoItemExt::define 14: rustccodegenllvm::base::compilecodegenunit::modulecodegen 15: rustc::depgraph::graph::DepGraph::withtask 16: rustccodegenllvm::base::compilecodegenunit 17: rustccodegenssa::base::codegencrate 18: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 19: rustc::util::common::time 20: rustcdriver::driver::phase4codegen 21: rustcdriver::driver::compileinput::{{closure}} 22: <std::thread::local::LocalKey<T::with 23: rustc::ty::context::TyCtxt::createandenter 24: rustcdriver::driver::compileinput 25: rustcdriver::runcompilerwithpool 26: <scopedtls::ScopedKey<T::set 27: rustcdriver::runcompiler 28: syntax::withglobals 29: rustmaybecatchpanic at 30: <F as alloc::boxed::FnBox<A::callbox 31: std::sys::unix::thread::Thread::new::threadstart at at at 32: <unknown33: clone query stack during panic: end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.34.0-nightly ( 2019-02-26) running on x86_64-unknown-linux-gnu note: compiler flags: -Z mir-opt-level=2 -C debuginfo=2 -C incremental --crate-type lib </pre</code</details
With the help of , I've found a tiny test that reproduces this crash on Linux and Mac:
Got another one: <details</detailsHappens when compiling regex tests with and calling on every span found in the mir of the functions needing codegen.
According to glaicer, the ICE from this example has been gone.
can you confirm that your example does not crash on nightly anymore?
Code change:
<ins> error: this file contains an un-closed delimiter --> $DIR/issue-58094-missing-right-square-bracket.rs:4:4 | LL | #[Ѕ |  - ^ |  | |  un-closed delimiter error: expected item after attributes --> $DIR/issue-58094-missing-right-square-bracket.rs:4:4 | LL | #[Ѕ |    ^ error: aborting due to 2 previous errors </ins>

Related discussion:
text: Has been fixed in
is likely the part of the rollup fixing it.
Shouldn't a testcase be instead of closing this?
A similar crash that still happens: