jiebi/CodeConvo huggingface dataset:
Change:
// except according to those terms. #![feature(struct_variant)] <del> // Test `Sized?` types not allowed in fields. </del> <ins> // Test `Sized?` types not allowed in fields (except the last one). </ins> struct S1<Sized? X> { f1: X, //~ ERROR type `f1` is dynamically sized. dynamically sized types may only appear as the

Discussion:
cc
This should be a compiler error, not an ICE. The error is (or should be) that is unsized, but is not a bare .
Why would this be an error? Isn't enabling this kind of code part of the goal of DST?
Not quite. We want to allow struct's last field to be potentially unsized, but it must be possible to have a sized version too. This is because only sized types can be instantiated. Since there is no possible sized version of , it cannot be instantiated and should be an error.
Hm, I see. This is kinda unfortunate though, because you can't hide away the actual slice type from your wrapper. Eg, you could do But that widens your wrapper to possibly be instantiated with more than and . Maybe allow a struct definition like but to use it you need to transmute something like ? As an aside, the example in this issue would probably not work anyway, as the stride should presumably be stored per pointer, and not once in the target matrices backing memory. But this is till relevant for newtype wrappers around , eg a hypothetical
Change:
check-stage$(1)-T-$(2)-H-$(3)-$(4)-exec: $$(call TEST_OK_FILE,$(1),$(2),$(3),$(4)) <del> ifeq ($$(CTEST_DISABLE_$(4)),) </del> <ins> # CTEST_DONT_RUN_$(1)-T-$(2)-H-$(3)-$(4) # Goal: leave this variable as empty string if we should run the test. # Otherwise, set it to the reason we are not running the test. # (Encoded as a separate variable because GNU make does not have a # good way to express OR on ifeq commands) ifneq ($$(CTEST_DISABLE_$(4)),) # Test suite is disabled for all configured targets. CTEST_DONT_RUN_$(1)-T-$(2)-H-$(3)-$(4) := $$(CTEST_DISABLE_$(4)) else # else, check if non-self-hosted target (i.e. target not-in hosts) ... ifeq ($$(findstring $(2),$$(CFG_HOST)),) # ... if so, then check if this test suite is disabled for non-selfhosts. ifneq ($$(CTEST_DISABLE_NONSELFHOST_$(4)),) # Test suite is disabled for this target. CTEST_DONT_RUN_$(1)-T-$(2)-H-$(3)-$(4) := $$(CTEST_DISABLE_NONSELFHOST_$(4)) endif endif # Neither DISABLE nor DISABLE_NONSELFHOST is set ==> okay, run the test. endif ifeq ($$(CTEST_DONT_RUN_$(1)-T-$(2)-H-$(3)-$(4)),) </ins> $$(call TEST_OK_FILE,$(1),$(2),$(3),$(4)):  $$(TEST_SREQ$(1)_T_$(2)_H_$(3))  $$(CTEST_DEPS_$(4)_$(1)-T-$(2)-H-$(3))

Discussion:
Original title: "compiletest has implicit dependency on libnative" compiletest has implicit dependency on libnative When I tried to do , I get the following: says this is because, despite 's continued use of , there is an implicit attempt to link in unless one puts in a attribute into the crate attributes. I plan to try to fix this pronto. After fixing the above, I get: So there's another separate problem blocking from working.
Still working on this, there was a new problem that came up (run-pass-fulldeps needs libsyntax to have been rebuilt), so I've updated the description and the title to reflect the more general issue here.
Change:
let &Matrix(ref rows) = matrix; assert!(rows.iter().all(|r| r.len() == v.len())); let pcx = PatternContext { ty: rows.iter().map(|r| r[0].ty).find(|ty| !ty.references_error()) .unwrap_or(v[0].ty), <del> max_slice_length: rows.iter().filter_map(|row| match *row[0].kind { PatternKind::Slice { ref prefix, slice: _, ref suffix } => Some(prefix.len() + suffix.len()), PatternKind::Constant { value: ConstVal::ByteStr(ref data) } => Some(data.len()), _ => None }).max().map_or(0, |v| v + 1) </del> <ins> max_slice_length: max_slice_length(cx, rows.iter().map(|r| r[0]).chain(Some(v[0]))) </ins> }; debug!("is_useful_expand_first_col: pcx={:?}, expanding {:?}", pcx, v[0]);

Discussion:
Hello, According to this , I have writted this example: But after the rustc 1.14.0-nightly version from 2016-10-25 --, I expected to see this happen:
Minimal example Fails with
regression introduced in .
How can this be a stable-nightly regression when this affects a gated feature?
Not sure what's the policy about it. It's a regression.
Yeah, I totally agree that this is a regression, although the label is inaccurate. I have wanted a label in the past (for eg. ), and think that once upon a time there even was such a label.
Change:
<ins> thread 'main' panicked at 'explicit panic', $DIR/issue-47429-short-backtraces.rs:17:5 stack backtrace: 0: std::panicking::begin_panic 1: issue_47429_short_backtraces::main note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. </ins>

Discussion:
v.s. is less verbose, but I remember it also filtering out some stack frames in some previous compiler versions. (Only frame # 6 is really useful to me here.) Indeed, contains some code that looks for a symbol on the stack to find out what to filter. It looks like some functionality has regressed. Stepping through the program in gdb it looks like the function is called, but despite there’s apparently no stack frame (anymore?) for it. CC and for , , and .
contains a fix for this
Now being worked on in instead afaict?
It is.
This issue hasn't been active in almost two years, and so have the issues linked here. Is there any intention of resuming work on this? It's mostly a small papercut because currently when crashing, programs suggest: run with environment variable to display a backtrace. and after setting that, also claim that: Some details are omitted, run with for a verbose backtrace. even though no details were omitted at all (which is the issue of course)
A simple fix would be to just look for "std::rt::lang_start::{{closure}}" instead until the real solution to the disappearing function is found..
This single fix is likely to have the biggest positive effect on my use of Rust since async/await. Thank you so much!
Awesome! I'm happy to see this finally fixed :D Thanks to everyone who had a part in this fix :)
Change:
} }) }; <del> let mut diff = Command::new("diff"); // diff recursively, showing context, and excluding .css files diff.args(&["-u", "-r", "-x", "*.css"]).args(&[&compare_dir, out_dir]); let output = if let Some(pager) = pager { let diff_pid = diff.stdout(Stdio::piped()).spawn().expect("failed to run `diff`"); </del> <ins> let diff_filename = format!("build/tmp/rustdoc-compare-{}.diff", std::process::id()); { let mut diff_output = File::create(&diff_filename).unwrap(); for entry in walkdir::WalkDir::new(out_dir) { let entry = entry.expect("failed to read file"); let extension = entry.path().extension().and_then(|p| p.to_str()); if entry.file_type().is_file() && (extension == Some("html".into()) || extension == Some("js".into())) { let expected_path = compare_dir.join(entry.path().strip_prefix(&out_dir).unwrap()); let expected = if let Ok(s) = std::fs::read(&expected_path) { s } else { continue }; let actual_path = entry.path(); let actual = std::fs::read(&actual_path).unwrap(); diff_output .write_all(&unified_diff::diff( &expected, &expected_path.to_string_lossy(), &actual, &actual_path.to_string_lossy(), 3, )) .unwrap(); } } } match self.config.color { ColorConfig::AlwaysColor => colored::control::set_override(true), ColorConfig::NeverColor => colored::control::set_override(false), _ => {} } if let Some(pager) = pager { </ins> let pager = pager.trim(); if self.config.verbose { eprintln!("using pager {}", pager);

Discussion:
When running on Linux and a failure happens, a really nice diff of the output vs rustdoc-nightly is produced which very clearly shows the issue. This does not work on Windows for multiple reasons. One the call to fails: Second, the output from rustdoc-nightly seems to exactly match that from the local compiler making it not possible to do manual diffs.
How do you diff directories recursively on Windows? On Linux I would be very surprised for not to be installed. Oh I just thought of something - do you have a rustup overide that defaults to your local toolchain? Right now compiletest assumes the default is nightly, I've been meaning to change it.
No, I only set overrides on specific projects (and rust-lang/rust is not one of them). My default is the stable compiler.
Git for Windows provides : Are you building Rust using Git Bash prompt?
I don't think it'd be a good idea to require testing rustdoc in the Git for Windows bash shell. I'd like for this to work in and PowerShell if possible.
Change:
#[stable(feature = "rust1", since = "1.0.0")] impl PartialEq<str> for OsStr { <ins> #[inline] </ins> fn eq(&self, other: &str) -> bool { *self == *OsStr::new(other) }

Discussion:
Godbolt link: I expect these two snippets have the same optimized asm but they don't:
I think the bigger problem here is that the quite trivial AsRef and PartialEq implementations did not get inlined. I would not expect anything to optimize well without those getting inlined.
I'm not sure we can expect these two to give you the same assembly. They are actually a bit different -- the first one will construct conditionally ( will call the closure only for ), whereas the second one will create the unconditionally before even checking if the parameter is or . As for the differences in the assembly wrt. comparisons themselves, this seems to be due to the difference between the code to check for equality of vs . I wonder, do you have a particular benchmark/workload where the first function is slower than expected?
Still, if I change the first snippet like below, [the asm][1] is different too: [1]:
is effectively a pointer cast, so it is warranted to expect assembly of at least similar quality. Inlining does not happen because we do happen to have generated machine code for these trivial functions in Tacking some s should suffice?
After inlining some methods in , I got the same asm between those two snippets:
Change:
}; let ty = self.normalize(expr.span, ty); if self.can_coerce(found, ty) { <del> err.multipart_suggestion( "you might have meant to return this value", vec![ (expr.span.shrink_to_lo(), "return ".to_string()), (expr.span.shrink_to_hi(), ";".to_string()), ], Applicability::MaybeIncorrect, ); </del> <ins> if let Some(node) = self.tcx.hir().find(fn_id) && let Some(owner_node) = node.as_owner() && let Some(span) = expr.span.find_ancestor_inside(owner_node.span()) { err.multipart_suggestion( "you might have meant to return this value", vec![ (span.shrink_to_lo(), "return ".to_string()), (span.shrink_to_hi(), ";".to_string()), ], Applicability::MaybeIncorrect, ); } </ins> } } }

Discussion:
The suggestion converts the code to: which is invalid. It should suggest: The suggestion works correctly for non-macro string values. This suggestion was introduced in . No response
It cannot be reproduced on .
I'm able to reproduce it locally. It seems to be suggesting a change in : (note the path) I assume that this is due to macro expansion. It might not be working on the playground because the playground doesn't have the component installed but that's a total guess.
The presence of only affects the human-readable rendering. The important part to me is the JSON output which has even without rust-src. Ideally it would be something closer to what it looks like with :
It seems to affect all macro expansions ():
Is the solution to just disable this suggestion for macro-expanded code? As an aside, perhaps the playground should get , especially because of its prevalence in sharing code which might need the additional context.
I think it's possible to achieve the desired output found in the description, although I'm not sure how exactly. Typically, you would use on the span to peel away the layers of macro invocations, though for that you would need to provide a parent to mark the end of the chain. doesn't need such a stopper but here its use would be incorrect if the macro call itself (e.g. ) was inside of a macro expansion. Since we don't have a parent (afaiaa), earlier I briefly tried to create a parent for via I think but that didn't work. Maybe could work, not sure. This approach is a catch-22 I believe.
Yeah, would that be the desired solution though? Can this be generalized to all the other type mismatch suggestions?
That's a good question. It was mostly an experiment to see if this specific issue can be solved with .
Change:
use crate::mem; use crate::net::{Shutdown, SocketAddr}; use crate::os::unix::io::{AsFd, AsRawFd, BorrowedFd, FromRawFd, IntoRawFd, RawFd}; <del> use crate::str; </del> use crate::sys::fd::FileDesc; use crate::sys::pal::unix::IsMinusOne; use crate::sys_common::net::{getsockopt, setsockopt, sockaddr_to_addr};

Discussion:
version: nightly-2023-11-22 os: centos-7 panic: thread '' panicked at called on an value: Utf8Error { validupto: 4, errorlen: Some(1) } note: run with environment variable to display a backtrace thread '' panicked at called on an value: Utf8Error { validupto: 4, errorlen: Some(1) } thread '' panicked at called on an value: Utf8Error { validupto: 4, errorlen: Some(1) } thread '' panicked at called on an value: Utf8Error { validupto: 4, error_len: Some(1) }
You are using a nightly that is over half a year old. Try using the latest nightly to see if it reproduces. If it does, please set and report back the printed backtrace as well as the project on which you get this panic.
Based on my testing, the latest version also has this issue.
It would appear that your libc's  function is not returning a UTF-8 encoded string (the fourth byte is invalid).
Can you share some of your system config, especially your locale? gai_strerror returning invalid UTF-8 is certainly not something expected by std.
<img width="955" alt="image" src=""
Which Chinese locale exactly? Could you show the values of the environment variables?
Sorry, the environment is no longer available, but it seems that using unwrap in is too risky.
It's probably not a UTF-8 locale. I would really recommend changing your locale to a UTF-8 one if possible, then this should work again. But you're right, this unwrap shouldn't be there, normal uses from lossy, which will give a bad error but at least won't crash. I'll send a PR.
Change:
[[package]] name = "pulldown-cmark" <del> version = "0.7.0" </del> <ins> version = "0.7.1" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "2c2d7fd131800e0d63df52aff46201acaab70b431a4a1ec6f0343fe8e64f35a4" </del> <ins> checksum = "3e142c3b8f49d2200605ee6ba0b1d757310e9e7a72afe78c36ee2ef67300ee00" </ins> dependencies = [ "bitflags", "memchr",

Discussion:
If I run cargo doc on the below code, it never finishes. I expected to see it finish. Problem does not exist on stable
cc
Fixed upstream in , but not released yet.
Let's hope next version will be released soon then! :)
Unfortunately this also affects 1.43 beta.
Hm so this will hit stable in less than a week then. Do we consider it high priority enough to try to push through a release ourselves? (e.g. we can temporarily fork or whatever, perhaps only on the beta branch). I personally lean towards no but wouldn't be opposed to doing so if t-rustdoc wanted to.
This issue halted development at our company for a day until we bisected the issue down to the particular line of code (a comment) that was causing to hang indefinitely. Thank you for all of your hard work on Rust. It is my most favourite language. I've been waiting for a suitable replacement for C++, and it has arrived!
Looks like there's movement on a point release, I would be in favor of backporting this to beta, since it's a really painful bug to hit...
0.7.1 has been released.
Yea, PR to update is up at .
Change:
} #[stable(feature = "iter_repeat_n", since = "1.82.0")] <ins> impl<A: Clone> Clone for RepeatN<A> { fn clone(&self) -> RepeatN<A> { RepeatN { count: self.count, element: self.element_ref().cloned().map_or_else(MaybeUninit::uninit, MaybeUninit::new), } } } #[stable(feature = "iter_repeat_n", since = "1.82.0")] impl<A: fmt::Debug> fmt::Debug for RepeatN<A> { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { f.debug_struct("RepeatN") .field("count", &self.count) .field("element", &self.element_ref()) .finish() } } #[stable(feature = "iter_repeat_n", since = "1.82.0")] </ins> impl<A> Drop for RepeatN<A> { fn drop(&mut self) { self.take_element();

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --This is technically different from as there's no UAF. However, using with has undefined behavior if you use the last/original element after moving the iterator, since the field has noalias properties. <details<summaryMiri Backtrace</summary<p</p</detailsWrapping the element using (or once we have that) should make this sound.
See also:
The minimal example is actually this: Because eagerly calls drop for . This basically boils down to Which is indeed I quite strongly think that this is a bug in miri and/or ( should use inside of itself probably?). That being said this is not yet decided (again, see the UCG issue) :/
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Yeah, it should -- someone just has to implement first. ;) See
I tweaked the title because while there is an experimental Miri flag to make Unique magical, codegen only has special treatment for Box.

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --currently unconditionally derives . However, it will also drop its inner object if is 0, which can cause a UAF if it's cloned afterwards. Running the above program segfaults: Edit: Made the segfault quicker/more reliable.
same issue with its implementation
cc I think you implemented this. ^^
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
// to iterate breaking tokens mutliple times. For example: // '[BinOpEq(Shr)] => [Gt, Ge] -> [Gt, Gt, Eq]' let mut token_trees: SmallVec<[_; 2]>; <del> if let TokenTree::Token(token) = &tree { </del> <ins> if let TokenTree::Token(token) = tree { </ins> let mut out = SmallVec::<[_; 2]>::new(); <del> out.push(token.clone()); </del> <ins> out.push(token); </ins> // Iterate to fixpoint: // * We start off with 'out' containing our initial token, and `temp` empty // * If we are able to break any tokens in `out`, then `out` will have

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --We have a library that compiles fine on 1.47.0 but after uggrading to 1.48.0 the compilation hangs. This code-snippet above is reduced from the original code as much as I can. I'm having problems understanding exactly where the problem is coming from and any further modifications to reduce it haven't worked. It uses the "paste" crate, and I've tried a few different versions including the latest one but it doesn't make a difference . I've been building it with at 1.47.0 and 1.48.0 to reproduce the issue which I got just by running doesn't work on works on </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
Some quick notes as I find them: This reproduces on just a cargo check, so has nothing to do with codegen (unsurprising) Compilation time scales by a little more than 2x for each additional number (going from 0 to 20 took 11 seconds, 21 took 26, 22 took 1 min 5) Given that I don't think this is a hard hang per se, just a really really long running compilation Definitely something in macro expansion, compiling the post- code is instant Reproduces on current nightly. -Zself-profile shows all the time is spent in . Unfortunately I don't have a debug build of rustc handy, but I imagine slapping a profiler on one should make the issue fairly obvious. I'd recommend cutting the provided example down from 64 to 20 though.

searched nightlies: from nightly-2020-08-24 to nightly-2020-10-03 regressed nightly: nightly-2020-10-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsLooks like
If it helps, this crate was exploring some ideas related to the crate
Assigning and removing as in the prioritization working group.
This is caused by some of the extra logic I in to ensure that we don't throw out the captured unnecessarily. I'm looking into improving the performance. In the longer term, this will be solved by getting rid of the pretty-print/retokenize hack entirely.
Change:
let def_id = cx.tcx.hir().local_def_id(count.hir_id); let substs = InternalSubsts::identity_for_item(cx.tcx, def_id); let span = cx.tcx.def_span(def_id); <del> let count = match cx.tcx.const_eval_resolve(cx.param_env, def_id, substs, None, Some(span)) { Ok(cv) => cv.eval_usize(cx.tcx, cx.param_env), Err(ErrorHandled::Reported) => 0, Err(ErrorHandled::TooGeneric) => { let span = cx.tcx.def_span(def_id); cx.tcx .sess .span_err(span, "array lengths can't depend on generic parameters"); 0 } }; </del> <ins> let count = match cx.tcx.const_eval_resolve( ty::ParamEnv::reveal_all(), def_id, substs, None, Some(span), ) { Ok(cv) => cv.eval_usize(cx.tcx, ty::ParamEnv::reveal_all()), Err(ErrorHandled::Reported) => 0, Err(ErrorHandled::TooGeneric) => { let span = cx.tcx.def_span(def_id); cx.tcx.sess.span_err(span, "array lengths can't depend on generic parameters"); 0 } }; </ins> ExprKind::Repeat { value: v.to_ref(), count } }

Discussion:
Hiya, on , compilation fails when defining an array whose length is from a constant from a trait from an associated type. The code compiles fine on . The error message: It seems similar to , but in this case, isn't being used. It may also be a duplicate of It also compiles fine on playpen nightly: .
Ouput from searched nightlies: from nightly-2019-12-29 to nightly-2019-12-31 regressed nightly: nightly-2019-12-31 searched commits: from to regressed commit:
cc
triage P-high, removing nomination.
A user reports that this is blocking the Rust Playground from updating its nightly. (See ) Nominating for discussion at today's meeting.
Sorry everyone, I totally forgot about this. A fix PR is up now.
Change:
<ins> // edition:2018 pub struct Test {} impl Test { pub async fn answer_str(&self, _s: &str) -> Test { Test {} } } </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --The code is based on this example and the following : (commit ) <!-- 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. --It fails on stable and nightly: : $ rustc --version --verbose rustc 1.49.0 ( 2020-12-29) binary: rustc commit-hash: commit-date: 2020-12-29 host: x8664-unknown-linux-gnu release: 1.49.0 and rustc 1.51.0-nightly ( 2021-01-30) binary: rustc commit-hash: commit-date: 2021-01-30 host: x8664-unknown-linux-gnu release: 1.51.0-nightly LLVM version: 11.0.1 From stable, non verbose: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This looks like an incremental compilation ICE. Does it disappear after running ?
I can't reproduce the ICE, so it does look like an incremental bug
It does. I have cloned that repo, modified the file as in the git diff above and run fresh too.
<details<p</p</details
Sorry I had misread. No, it does not. Sorry for the confusion
Thanks for the report! I can reproduce with:
This is caused by: There is no guarantee that either or is actually local.
I've never committed to this repository; if you want to guide me to fix this issue, I'm happy to do it. If it's better if you do it, no worries
Assigning as discussed as part of the and removing .
claim