jiebi/CodeConvo huggingface dataset:
Change:
With the change in function shouldrunsuccessfully() of commit : RunPass =true, Ui == Some(PassMode::Run), RunPass | Ui =self.effectivepass_mode() == Some(PassMode::Run), The test cases under run-pass directory are tested for building only, the compiled test cases are not running any more. Does it work as design?
Oh. This is bad. Will fix today. cc (on vacation)
Fixed in

Discussion:
// ignore-pretty issue #37195 // ignore-cloudabi spawning processes is not supported // ignore-emscripten spawning processes is not supported <del> // normalize-stderr-test ".*n" -> "" </del> <ins> // ignore-msvc issue #62844 </ins> // ignore-sgx no processes <ins> // normalize-stderr-test ".*n" -> "" </ins> // Note that above `-opt-bisect-limit=0` is used to basically disable // optimizations. It creates tons of output on stderr, hence we normalize

// ignore-cloudabi spawning processes is not supported // ignore-emscripten spawning processes is not supported // ignore-openbsd no support for libbacktrace without filename <ins> // ignore-msvc issue #62844 </ins> // ignore-sgx no processes // compile-flags:-g

<ins> // ignore-android // ignore-cloudabi // ignore-emscripten // ignore-sgx </ins> #![feature(rustc_private)] fn main() {

// See issue #59123 for a full explanation. // edition:2018 <ins> // ignore-wasm32 issue #62807 </ins> #![feature(generators, generator_trait)]

<del> // Make sure that the mono-item collector does not crash when trying to // instantiate a default impl for DecodeUtf16<<u8 as A>::Item> // See https://github.com/rust-lang/rust/issues/58375 // compile-flags:-C link-dead-code #![crate_type = "rlib"] pub struct DecodeUtf16<I>(I); pub trait Arbitrary { fn arbitrary() {} } pub trait A { type Item; } impl A for u8 { type Item = char; } impl Arbitrary for DecodeUtf16<<u8 as A>::Item>  { } </del>

<ins> // Make sure that the mono-item collector does not crash when trying to // instantiate a default impl for DecodeUtf16<<u8 as A>::Item> // See https://github.com/rust-lang/rust/issues/58375 // build-pass // compile-flags:-C link-dead-code #![crate_type = "rlib"] pub struct DecodeUtf16<I>(I); pub trait Arbitrary { fn arbitrary() {} } pub trait A { type Item; } impl A for u8 { type Item = char; } impl Arbitrary for DecodeUtf16<<u8 as A>::Item> {} </ins>

} fn should_run_successfully(&self) -> bool { <ins> let pass_mode = self.pass_mode(); </ins> match self.config.mode { <del> RunPass | Ui => self.pass_mode() == Some(PassMode::Run), </del> <ins> Ui => pass_mode == Some(PassMode::Run), RunPass => pass_mode == Some(PassMode::Run) || pass_mode.is_none(), </ins> mode => panic!("unimplemented for mode {:?}", mode), } }
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.

Discussion:
/// Checks whether the regions of memory starting at `src` and `dst` of size /// `count * size_of::<T>()` overlap. <ins> #[cfg(not(miri))] // Cannot compare with `>` across allocations in Miri </ins> fn overlaps<T>(src: *const T, dst: *const T, count: usize) -> bool { let src_usize = src as usize; let dst_usize = dst as usize;

debug_assert!(is_aligned_and_not_null(src), "attempt to copy from unaligned or null pointer"); debug_assert!(is_aligned_and_not_null(dst), "attempt to copy to unaligned or null pointer"); <ins> #[cfg(not(miri))] </ins> debug_assert!(!overlaps(src, dst, count), "attempt to copy to overlapping memory"); copy_nonoverlapping(src, dst, count) }

<del> Subproject commit b5ddc94bf02c641e5acbb08ae742014f40347f10 </del> <ins> Subproject commit b269bb07078446c9c153e0f2acaf83bf8f19b935 </ins>
Change:
Starting with an ambiguous rustdoc correctly reports the ambiguity and suggests the possible resolutions: In this case I want to link to the module so let's update accepts this without warnings but the generated html file contains: I would expect [module to link to the module x, not the function x. Mentioning tracking issue:
Workaround: leverage rustc's name resolution instead of rustdoc's.
This is coming directly from , so I'm not sure how to fix it. Maybe has ideas? The issue is that currently we can only select between types, values, and macros, and modules count as all three so there's not a way to say 'only give me modules'.
I think eventually we should switch rustdoc to using . That would also But I have no idea how hard that would be.
Yeah I don't know either. I'm not sure how that overlap works in resolve. might? We could tweak the resolve resolution functions to force looking for modules.
I don't know much about name resolution, you want Only thing I know is that it should be possible to get a and then use whichever namespace you want from there at your discretion.
the problem is that modules seem to be special and exist in all namespaces but also overlap. Do you have an idea of how that works?
"Modules count as all three" sounds wrong? Modules live in the type namespace last I checked.
Oh! Maybe we should just switch modules to being a type then, I was under the impression they lvied in all namespaces
And yeah, seems like types cannot overlap with modules.
Wait I'm confused - I thought functions are in the type namespace? Are they values instead?
Functions are values

Discussion:
let (res, fragment) = { let mut kind = None; let mut disambiguator = None; <del> path_str = if let Some(prefix) = ["struct@", "enum@", "type@", "trait@", "union@"] .iter() .find(|p| link.starts_with(**p)) </del> <ins> path_str = if let Some(prefix) = ["struct@", "enum@", "type@", "trait@", "union@", "module@", "mod@"] .iter() .find(|p| link.starts_with(**p)) </ins> { kind = Some(TypeNS); disambiguator = Some(&prefix[..prefix.len() - 1]); link.trim_start_matches(prefix) <del> } else if let Some(prefix) = [ "const@", "static@", "value@", "function@", "mod@", "fn@", "module@", "method@", ] .iter() .find(|p| link.starts_with(**p)) </del> <ins> } else if let Some(prefix) = ["const@", "static@", "value@", "function@", "fn@", "method@"] .iter() .find(|p| link.starts_with(**p)) </ins> { kind = Some(ValueNS); disambiguator = Some(&prefix[..prefix.len() - 1]);

<ins> // ignore-tidy-linelength #![deny(intra_doc_link_resolution_failure)] pub fn foo() { } pub mod foo {} // @has intra_doc_link_mod_ambiguity/struct.A.html '//a/@href' '../intra_doc_link_mod_ambiguity/foo/index.html' /// Module is [`module@foo`] pub struct A; // @has intra_doc_link_mod_ambiguity/struct.B.html '//a/@href' '../intra_doc_link_mod_ambiguity/fn.foo.html' /// Function is [`fn@foo`] pub struct B; </ins>
Change:
... and keeps running until I kill it. This bad behavior did not exist on the previous nightly. I hypothesize that it has to do with (cc This issue was found with the help of . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oh, excellent, thanks ! claim

Discussion:
loop { idx = match string[idx..].find('r') { None => break, <del> Some(it) => it + 1 </del> <ins> Some(it) => idx + it + 1 </ins> }; if string[idx..].chars().next() != Some('n') { self.err_span_(start + BytePos(idx as u32 - 1),

<ins> // Issue #62863 // ignore-tidy-cr // Note: if you see ^M in this file, that's how your editor renders literal `r` /// This do
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.

Discussion:
/// Checks whether the regions of memory starting at `src` and `dst` of size /// `count * size_of::<T>()` overlap. <del> #[cfg(not(miri))] // Cannot compare with `>` across allocations in Miri </del> fn overlaps<T>(src: *const T, dst: *const T, count: usize) -> bool { let src_usize = src as usize; let dst_usize = dst as usize;

debug_assert!(is_aligned_and_not_null(src), "attempt to copy from unaligned or null pointer"); debug_assert!(is_aligned_and_not_null(dst), "attempt to copy to unaligned or null pointer"); <del> #[cfg(not(miri))] </del> debug_assert!(!overlaps(src, dst, count), "attempt to copy to overlapping memory"); copy_nonoverlapping(src, dst, count) }

<del> Subproject commit b269bb07078446c9c153e0f2acaf83bf8f19b935 </del> <ins> Subproject commit 7ef40979157b4117faa52bbe79ec144ebd45b0e3 </ins>
Change:
Right now it is allowed to select whether we want to search within all crates or in the specific ones (e.g. core, std, etc). It would be really useful to remember the selected option, because in most cases we want to search in the std crate only. cc
Good idea!
Does not work, neither in stable nor nightly. Go to Choose the "std" option. Type Option, click on it We still see the "All crates" on the , and if we try to search something else, results will be from all sources anyway.
Indeed, will take a look quickly.
Works perfectly now. Thanks!

Discussion:
var OUTPUT_DATA = 1; var params = getQueryStringParams(); <ins> // Set the crate filter from saved storage, if the current page has the saved crate filter. // // If not, ignore the crate filter -- we want to support filtering for crates on sites like // doc.rust-lang.org where the crates may differ from page to page while on the same domain. var savedCrate = getCurrentValue("rustdoc-saved-filter-crate"); if (savedCrate !== null) { onEachLazy(document.getElementById("crate-search").getElementsByTagName("option"), function(e) { if (e.value === savedCrate) { document.getElementById("crate-search").value = e.value; return true; } }); } </ins> // Populate search bar with query string search term when provided, // but only if the input bar is empty. This avoid the obnoxious issue // where you start trying to do a search, and the index loads, and

}; search_input.onpaste = search_input.onchange; <del> var selectCrate = document.getElementById('crate-search'); </del> <ins> var selectCrate = document.getElementById("crate-search"); </ins> if (selectCrate) { selectCrate.onchange = function() { <ins> updateLocalStorage("rustdoc-saved-filter-crate", selectCrate.value); </ins> search(undefined, true); }; }

} function addSearchOptions(crates) { <del> var elem = document.getElementById('crate-search'); </del> <ins> var elem = document.getElementById("crate-search"); </ins> if (!elem) { return;

function usableLocalStorage() { // Check if the browser supports localStorage at all: <del> if (typeof(Storage) === "undefined") { </del> <ins> if (typeof Storage === "undefined") { </ins> return false; } // Check if we can access it; this access will fail if the browser
Change:
Right now it is allowed to select whether we want to search within all crates or in the specific ones (e.g. core, std, etc). It would be really useful to remember the selected option, because in most cases we want to search in the std crate only. cc
Good idea!
Does not work, neither in stable nor nightly. Go to Choose the "std" option. Type Option, click on it We still see the "All crates" on the , and if we try to search something else, results will be from all sources anyway.
Indeed, will take a look quickly.
Works perfectly now. Thanks!

Discussion:
v.push_str(&minify_replacer( &format!("{}n{}", variables.join(""), all_indexes.join("n")), options.enable_minification)); <del> v.push_str("initSearch(searchIndex);addSearchOptions(searchIndex);"); </del> <ins> // "addSearchOptions" has to be called first so the crate filtering can be set before the // search might start (if it's set into the URL for example). v.push_str("addSearchOptions(searchIndex);initSearch(searchIndex);"); </ins> cx.shared.fs.write(&dst, &v)?; } if options.enable_index_page {

var OUTPUT_DATA = 1; var params = getQueryStringParams(); <del> // Set the crate filter from saved storage, if the current page has the saved crate filter. // // If not, ignore the crate filter -- we want to support filtering for crates on sites like // doc.rust-lang.org where the crates may differ from page to page while on the same domain. var savedCrate = getCurrentValue("rustdoc-saved-filter-crate"); if (savedCrate !== null) { onEachLazy(document.getElementById("crate-search").getElementsByTagName("option"), function(e) { if (e.value === savedCrate) { document.getElementById("crate-search").value = e.value; return true; } }); } </del> // Populate search bar with query string search term when provided, // but only if the input bar is empty. This avoid the obnoxious issue // where you start trying to do a search, and the index loads, and

} return 0; }); <ins> var savedCrate = getCurrentValue("rustdoc-saved-filter-crate"); </ins> for (var i = 0; i < crates_text.length; ++i) { var option = document.createElement("option"); option.value = crates_text[i]; option.innerText = crates_text[i]; elem.appendChild(option); <ins> // Set the crate filter from saved storage, if the current page has the saved crate // filter. // // If not, ignore the crate filter -- we want to support filtering for crates on sites // like doc.rust-lang.org where the crates may differ from page to page while on the // same domain. if (crates_text[i] === savedCrate) { elem.value = savedCrate; } </ins> } }
Change:
The libc crate cron job has started failing to build on master for the target . To reproduce: errors with libcore failing to build for the target is bad - that it prevents to build the libc crate for the target is a sideeffect of that.
I wasn't able to reproduce this based on your instructions. Though for me there is no attempt to even build core, it just builds libc.
Weird. The first thing does is build a sysroot for the target, and the first step of doing that is building .
See the exact build failure in libc's CI which mentions the exact same invocation and how the first thing does is building libcore: https://travis-
I suspect that it doesn't build libcore because it's already distributed by rustup (and removing the rustup target makes compilation fail with libcore not found). Maybe something needs to be done to force building of libcore even for a non-custom target?
I don't really follow. and ignore anything distributed by rustup, except for the component, which include libcore sources, and as can be seen in the logs, the first thing they do is compiling the crate, which fails with an LLVM error since the LLVM upgrade.
AFAIK, we do not ship a rust-std component for this particular target.
has a rust-std component that contains just libcore (it's the only target we ship that works on Cortex-M0 chips, so it's quite important for embedded)
can you try to bisect the regression -- ideally to a specific PR? The tool may be of use! I'm marking this as P-high so that we check in on it but it seems like it's not yet clear whether this is a compiler bug exactly or what.
I think it would be helpful if somebody else can reproduce this issue first. Following the instructions that I posted in the OP, I can reproduce this both on a x8664-unknown-linux-gnu and a x8664-apple-darwin host, with the current nightly (rustc 1.38.0-nightly ( 2019-07-24)). which host are you on ?
PR wise we started seeing this right after was merged. I'm afraid that on my home laptop compiling rustc twice to test will take me... days.
I also cannot reproduce on x86_64-unknown-linux-gnu using the instructions above.
I was able to reproduce after doing a . I'm not sure why that works while doesn't. Now I get the LLVM error.
Ah, indeed! makes the error appear.
So I do indeed have nightly as my default Rust toolchain, and on libc's CI this is the case as well for that build job. I'll report this to xargo upstream.
There's a couple of places that can throw this error, the one we hit is The symbol in question is , a jump-table label.
Finally managed to get a reproducer (turns out this only crashes llc at ):
I've opened an LLVM bug at
FYI rust-lang/stdarch game boy advance build job is affected by this as well.
Fixed upstream in and backported to LLVM 9 in LLVM submodule update pending in .

Discussion:
<del> Subproject commit 9b64ca5b7e1e3583978f9ac8af6d93b220a13d90 </del> <ins> Subproject commit f2b0c67661f19bb2564225d47aca424ad0449791 </ins>
Change:
I'm trying to use on project generated by and looks like the source code path is not configured:
Visited during wg-debugging's triage meeting. We think this is most likely still an issue but probably not a high priority one. If someone wants to work on this, the first thing they should do is retest and verify this is still broken (but we think it most likely is). There may be a fairly simple resolution to modify rust-gdb to detect which toolchain it's being invoked from and then run the set substitute-path path with the appropriate paths. I'm willing to help mentor someone in fixing this
Hi, I'm looking for a first issue, would love the mentoring!
can't reproduce it, it works just fine nearly 4 yrs later, has this perhaps already been fixed ?
Past should have included a sample test case.
No, I can still reproduce it. are you maybe using a distro-packaged toolchain? Crashing program: output: To make work, don't use in the replacement.

Discussion:
# Find out where the pretty printer Python module is RUSTC_SYSROOT="$("$RUSTC" --print=sysroot)" GDB_PYTHON_MODULE_DIRECTORY="$RUSTC_SYSROOT/lib/rustlib/etc" <ins> # Get the commit hash for path remapping RUSTC_COMMIT_HASH="$("$RUSTC" -vV | sed -n 's/commit-hash: (w*)/1/p')" </ins> # Run GDB with the additional arguments that load the pretty printers # Set the environment variable `RUST_GDB` to overwrite the call to a

PYTHONPATH="$PYTHONPATH:$GDB_PYTHON_MODULE_DIRECTORY" exec ${RUST_GDB}  --directory="$GDB_PYTHON_MODULE_DIRECTORY"  -iex "add-auto-load-safe-path $GDB_PYTHON_MODULE_DIRECTORY"  <ins> -iex "set substitute-path /rustc/$RUSTC_COMMIT_HASH $RUSTC_SYSROOT/lib/rustlib/src/rust"  </ins> "$@"  No newline at end of file

# Find out where the pretty printer Python module is RUSTC_SYSROOT="$("$RUSTC" --print=sysroot)" GDB_PYTHON_MODULE_DIRECTORY="$RUSTC_SYSROOT/lib/rustlib/etc" <ins> # Get the commit hash for path remapping RUSTC_COMMIT_HASH="$("$RUSTC" -vV | sed -n 's/commit-hash: (w*)/1/p')" </ins> # Set the environment variable `RUST_GDB` to overwrite the call to a # different/specific command (defaults to `gdb`).

# These arguments get passed through to GDB and make it load the # Rust pretty printers. <del> GDB_ARGS="--directory="$GDB_PYTHON_MODULE_DIRECTORY" -iex "add-auto-load-safe-path $GDB_PYTHON_MODULE_DIRECTORY"" </del> <ins> GDB_ARGS="--directory="$GDB_PYTHON_MODULE_DIRECTORY""  "-iex "add-auto-load-safe-path $GDB_PYTHON_MODULE_DIRECTORY""  "-iex "set substitute-path /rustc/$RUSTC_COMMIT_HASH $RUSTC_SYSROOT/lib/rustlib/src/rust"" </ins> # Finally we execute gdbgui. PYTHONPATH="$PYTHONPATH:$GDB_PYTHON_MODULE_DIRECTORY"
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
Miri-side fix:
Could we resolve this by updating Miri?
Right now, no, because and I am not sure what.
Oh, I missed
Breakage is likely caused by
Submitted fix:
The fixes landed?
It did, yes. There are some PRs under review on the rustc side that would break Miri again, but if you want you can update Miri so we'll get one or two nightlies with newer versions. Btw, for using Miri on CI or so, I recommend a snippet such as: This way you'll get a working Miri even if the latest nightly does not have one.
(In case you open a PR, please Cc/r? me. I won't see it otherwise.)

Discussion:
<del> Subproject commit 7ef40979157b4117faa52bbe79ec144ebd45b0e3 </del> <ins> Subproject commit e276676f0c0fc16f41e46cc56cb7a9362dc717b0 </ins>
Change:
I'm seeing an internal compiler error on the following input (found by ): This error does not occur on stable or beta, nor on a nightly from last week.
The panic is being thrown from here: That code assumes that will always return . However, in this case calls , which returns from here:
cc
Seems fixed in the latest nightly(), marked as E-needstest
I'll add a test for this

Discussion:
<ins> // fixed by #66361 // error-pattern: aborting due to 3 previous errors impl W <s(f;Y(;] </ins>

<ins> error: this file contains an un-closed delimiter --> $DIR/issue-63116.rs:3:18 | LL | impl W <s(f;Y(;] |          -       ^ |          | |          un-closed delimiter error: expected one of `!`, `(`, `)`, `+`, `,`, `::`, or `<`, found `;` --> $DIR/issue-63116.rs:3:12 | LL | impl W <s(f;Y(;] |            ^ expected one of 7 possible tokens error: expected one of `!`, `&&`, `&`, `(`, `)`, `*`, `+`, `,`, `->`, `...`, `::`, `<`, `>`, `?`, `[`, `_`, `dyn`, `extern`, `fn`, `for`, `impl`, `unsafe`, or lifetime, found `;` --> $DIR/issue-63116.rs:3:15 | LL | impl W <s(f;Y(;] |              -^ help: `)` may belong here |              | |              unclosed delimiter error: aborting due to 3 previous errors </ins>
Change:
I'm seeing an internal compiler error on the following input (found by ): The error happens on stable, beta, and nightly.
The only early return I see that doesn't emit is here:
Applying the most obvious patch, I get the following non-ICE output: The "expected , found " bit doesn't seem quite right. :slightlysmilingface:
is an unfortunate side effect of the unmatched delimiter recovery logic not accounting for s. Submit a PR with this patch to fix this ICE as fixing the slightly misleading message will require a much larger (unrelated) change.
I'll toss one up after I finish running the test suite. One thing: I'm not sure how to annotate the test. It looks like there's four errors that all point to EOF, but whatever I try to write, only one of them gets recognized as referring to that line.
this is what I did

Discussion:
let mut etc_span = None; while self.token != token::CloseDelim(token::Brace) { <del> let attrs = self.parse_outer_attributes()?; </del> <ins> let attrs = match self.parse_outer_attributes() { Ok(attrs) => attrs, Err(err) => { if let Some(mut delayed) = delayed_err { delayed.emit(); } return Err(err); }, }; </ins> let lo = self.token.span; // check that a comma comes after every field

<ins> // error-pattern: aborting due to 6 previous errors fn i(n{...,f # </ins>

<ins> error: this file contains an un-closed delimiter --> $DIR/issue-63135.rs:3:16 | LL | fn i(n{...,f # |     - -        ^ |     | | |     | un-closed delimiter |     un-closed delimiter error: expected field pattern, found `...` --> $DIR/issue-63135.rs:3:8 | LL | fn i(n{...,f # |        ^^^ help: to omit remaining fields, use one fewer `.`: `..` error: expected `}`, found `,` --> $DIR/issue-63135.rs:3:11 | LL | fn i(n{...,f # |        ---^ |        |  | |        |  expected `}` |        `..` must be at the end and cannot have a trailing comma error: expected `[`, found `}` --> $DIR/issue-63135.rs:3:15 | LL | fn i(n{...,f # |               ^ expected `[` error: expected `:`, found `)` --> $DIR/issue-63135.rs:3:15 | LL | fn i(n{...,f # |               ^ expected `:` error: expected one of `->`, `where`, or `{`, found `<eof>` --> $DIR/issue-63135.rs:3:15 | LL | fn i(n{...,f # |               ^ expected one of `->`, `where`, or `{` here error: aborting due to 6 previous errors </ins>