jiebi/CodeConvo huggingface dataset:
Change:
# If curl is not present on Win32, we should not sys.exit #   but raise `CalledProcessError` or `OSError` instead require(["curl", "--version"], exception=platform_is_win32()) <del> run(["curl", option, </del> <ins> extra_flags = [] if curl_version() > (7, 70): extra_flags = [ "--retry-all-errors" ] run(["curl", option] + extra_flags + [ </ins> "-L", # Follow redirect. "-y", "30", "-Y", "10",    # timeout if speed is < 10 bytes/sec for > 30 seconds "--connect-timeout", "30",  # timeout if cannot connect within 30 seconds "-o", path, <ins> "--continue-at", "-", </ins> "--retry", "3", "-SRf", url], verbose=verbose, exception=True, # Will raise RuntimeError on failure

Discussion:
We're passing --retry: but by default that only retries 500 errors, not any error: Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is a regression from when I moved the downloads from python to rust (about a year ago now I think).
Mentoring instructions: Add the option to the invocations, in and This doesn't affect the Windows Powershell fallback, since we already retry on any error. There are many other invocations across the repo, but they seem to not be causing problems.
claim
This is quite new flag shipped with recent versions of curl, which is not supported on many machines/platforms(including our CI runners). We can consider using as I also suggest at
I'd like to take a look at this. Looking through the PR history, we would like basic retry logic written in Rust versus using a curl flag like to retry during the bootstrap process. If it's a 404, then do not retry, but any other errors should be retried. I assume there is a http library already vendored in, so no new dependencies should be .
claim
Thanks! This shouldn't be needed. For now, retrying on "connection refused" () should be fine.
I'm a little confused as to why was closed then. What more is there beyond adding the retry refused connections flag?
I forgot that our CI runners depend on very old curl versions which doesn't support the flag I suggested. Sorry, you are right. As jyn also said() in that PR, we can handle this in Rust
are we ok with adding the dependency to facilitate sending requests to the payload URL? I'm very hesitant to add another crate dependency to the core payload. But without it, we would need to manually built a request via the standard library tcp library. Which is a little awkward. doesn't actually have support for sending requests. I suppose, in the case we decide to use it, another library would need to be as well?
What about using curl arguments to read the status code and handle it in rust logic? It might be a bit ugly, but adding a dependency solely for this purpose seems like overkill to me.
I agree adding a new dep seems extreme.

I can try parsing the curl exit code, great idea.
claim
claim
Hello Is this still relevant?
please don't ping me about rust-lang/ issues. is the current maintainer.
We didn't change any curl flags since then; it should be still relevant.
release-assignment
Change:
let cstore = &ccx.tcx.sess.cstore; cstore.iter_crate_data(|cnum, _| { csearch::each_top_level_item_of_crate(cstore, cnum, |dl, _, _| { <del> handle_external_def(&mut traits, ccx, cstore, dl) </del> <ins> handle_external_def(&mut traits, &mut external_mods, ccx, cstore, dl) </ins> }) });

Discussion:
Updated 10/21: is currently valid Rust. I don't know if it should be, but it causes the compiler to blow its stack when recursively traversing a crate which contains it. To reproduce: Create a lib crate with this body: (compiles fine)Link to this crate, then include code that results in a method missing error, such as: This will cause the stack to overflow in while it looks up traits in linked crates that define a method . There are probably other functions which overflow like this in the case of this text. I would think either should be smart enough to not recursively include the self module or should be an error.
It would be easier to debug this problem if we would have source code that causes it (e.g. for ).
I did some debugging, found the issue, and have updated the title and top comment to explain it clearly, including steps to reproduce. Fortunately, the practical fix is easy (don't use ).
Change:
<ins> error[E0277]: a value of type `f32` cannot be made by summing an iterator over elements of type `{integer}` --> $DIR/invalid-iterator-chain-with-int-infer.rs:2:41 | LL |     let x = Some(()).iter().map(|()| 1).sum::<f32>(); |                                         ^^^ value of type `f32` cannot be made by summing a `std::iter::Iterator<Item={integer}>` | = help: the trait `Sum<{integer}>` is not implemented for `f32` = help: the following other types implement trait `Sum<A>`: <f32 as Sum<&'a f32>> <f32 as Sum> note: the method call chain might not have had the expected associated types --> $DIR/invalid-iterator-chain-with-int-infer.rs:2:29 | LL |     let x = Some(()).iter().map(|()| 1).sum::<f32>(); |             -------- ------ ^^^^^^^^^^^ `Iterator::Item` changed to `{integer}` here |             |        | |             |        `Iterator::Item` is `&()` here |             this expression has type `Option<()>` note: required by a bound in `std::iter::Iterator::sum` --> $SRC_DIR/core/src/iter/traits/iterator.rs:LL:COL error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
Regression from stable 1.66 / beta 1.67 -nightly 1.68 (haven't bisected). Stable/beta correctly produce an error, nightly ICEs. I've also confirmed the behavior on the latest commit to master (, at time of writing). (nightly — ICE) (beta — error as expected) (stable — error as expected) Setting produced the same output as above. I tried to dig into this, struggled to make sense of the typechecking code. I think the following is going on: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cargo-bisect-rustc seems to think this is caused by of which looks like the most plausible candidate since it touched type relation code which calls without handling infer vars :thinking: cc
Ugh i'll fix it claim
WG-prioritization assigning priority (). label -I-prioritize +P-high
This is a bit weird, but I was able to come up with an alternative reduction (after hit it on - we use a pinned nightly so this is mostly a coincidence): I'm not sure why the inference variable vs generic param makes a difference like that, but I wasn't able to combine the two reductions together. Also, the ICE query stack confirms the / split between nightly versions, even in the combined example.
Change:
Self { tcx, set: Default::default() } } <ins> /// Adds a predicate to the set. /// /// Returns whether the predicate was newly inserted. That is: /// - If the set did not previously contain this predicate, `true` is returned. /// - If the set already contained this predicate, `false` is returned, ///   and the set is not modified: original predicate is not replaced, ///   and the predicate passed as argument is dropped. </ins> pub fn insert(&mut self, pred: ty::Predicate<'tcx>) -> bool { // We have to be careful here because we want //

Discussion:
While working on I think I found a bug. Given this program: rustc outputs the following vtable layout: Which is surprising, because is unnecessary — does not have any methods, so vtable can be inlined... I think we should be smarter here: (for the record, I'm pretty sure this happens in practice, I've found this with ) Originally posted by in
cc
sorry been slow a little recently... This is a nice improvement.
Change:
<ins> #![crate_name = "foo"] #![no_std] // @has 'foo/fn.foo.html' // @has - '//*[@class="docblock"]' 'inc2 x' #[doc = include_str!("short-line.md")] pub fn foo() {} </ins>

Discussion:
When using to insert another file as a docstring, it seems that the last line gets cut off if it contains only one character. : : (Both files have a trailing new line.) : Running on the above produces output like this: That is, the file gets included correctly, but the file loses its second line. This bug only seems to happen if the last line is a single character. Reproduced this bug on both stable and nightly. : :
does this also happen for string constants and other things using ? Or just the doc attribute?
Oh I didn't think to check that. Looks like the bug doesn't reproduce with a non- use of . This runs without error:
Ok cool and follow-up question - does have the same issue? Or only with include_str?
That does reproduce the issue. The rustdoc output looks like .
cc this is probably related to your changes to try and make the indentation smarter.
You mean removing the smart indent? ;) But yes, very likely. I'll take a look.
Change:
return; } <del> if self.in_scope_lifetimes.contains(&ident.modern()) { </del> <ins> if self.in_scope_lifetimes.contains(&ParamName::Plain(ident.modern())) { </ins> return; }

Discussion:
The following breaks on nightly (see ) With: CC: dtolnay/async-trait
Reduced:
Forgot to mention in case this helps, giving the inner fn a matching lifetime avoids this issue for some reason:
The reason this is happening is that the desugared version of applies all in-scope lifetimes to the returned existential type, which in this case is creating , which is invalid. I'm not sure exactly what the best fix is for this, though, since elided lifetimes in the impl signature are intentionally unnameable. The closest idea I have would be to create some special new lifetime that is but can refer to lifetimes originating from the impl header. cc who may have opinions.
Hmm wouldn't you expect the nested to not inherit anything from its enclosing scopes? Seems like a bug to me that it does? Am I confused about something?
The function in the middle is actually a bit of a source of confusion here, although it does indicate that there's a second bug since we shouldn't be inheriting generics since the nested isn't part of the . The bug I was focusing on is better illustrated by this example: which produces this error: This is because the code is transformed into and in that case does not refer back to the usage from the header.
I see. Indeed, I would expect that, internally, we'd have some way to refer back to the from the impl header. I believe this should be possible, no? In particular, the in impls expands (internally) to for some integer N, which I believe is basically treated like any other named lifetime.
Yep, I would've expected so as well-- I'm not sure why that isn't working, I'd have to take a look.
I was looking and I think the bug lies here: Probably needs to be a instead, or we need to use something else for this purpose.
A closer reading suggests I was mistaken. The lifetimes from the impl should show up in -- includes only the explicitly declared lifetimes written by the user on the impl. I'm not quite sure what the problem is yet.
OK, no, I was correct. When processing impl items, we convert the lifetimes into entries. EDIT: Er, I'm still not entirely sure. Reading more. =)
OK, I have a fix for the method issue, but not the nested async fn item issue.

I forked off for the method issue
I didn't prep a fix for this one yet. It seems obvious that some internal state is not being reset when we enter a new item.
but if you have a chance to investigate, would be appreciated
Presumably the problem is that doesn't "reset" the vector -- it only seems to extend it...
Indeed, in-band lifetimes are broken in the same way. This fails to compile ():
Working on a possible fix
Yep, have a fix.
Inband lifetimes looks similar to fwiw
thanks
Change:
// MSVC-LABEL: !DIGlobalVariable(name: "impl$<debug_vtable::Foo, _>::vtable$" // CHECK: !DISubrange(count: 3 <ins> // NONMSVC-LABEL: !DIGlobalVariable(name: "<debug_vtable::bar::{closure#0} as core::ops::function::FnOnce<(core::option::Option<&dyn core::ops::function::Fn<(), Output=()>>)>>::{vtable}" // MSVC-LABEL: !DIGlobalVariable(name: "impl$<debug_vtable::bar::closure$0, core::ops::function::FnOnce<tuple$<enum$<core::option::Option<ref$<dyn$<core::ops::function::Fn<tuple$<>,assoc$<Output,tuple$<> > > > > >, {{.*}}, {{.*}}, Some> > > >::vtable$" </ins> #![crate_type = "lib"] pub struct Foo;

Discussion:
Building on Windows ( toolchain) causes an ICE: <details<summarybacktrace</summary</detailsBisecting reveals this was injected by (cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
I'll look into it.
Since landed in 1.57, labeling as stable-to-beta regression.
Re-opening to track the beta backport.
fix backported to beta in PR rollup
Change:
pub use creader::{load_symbol_from_dylib, DylibError}; pub use fs::{emit_wrapper_file, METADATA_FILENAME}; pub use native_libs::{ <del> find_native_static_library, try_find_native_static_library, walk_native_lib_search_dirs, </del> <ins> find_native_static_library, try_find_native_dynamic_library, try_find_native_static_library, walk_native_lib_search_dirs, </ins> }; pub use rmeta::{encode_metadata, rendered_const, EncodedMetadata, METADATA_HEADER};

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. --Hi all, I'm coming from to report an inconsistency in how Rust passes library names to Visual Studio's . In the project, which is driven through Meson, I expected all libraries to be found correctly. Instead, I get an error of library not found at linking time. This is caused by the following snippet of code. The above snippet hardcodes the convention when passing import or static libraries' names. However, this is not consistent with , which is already handled correctly in a separate portion of the Rust compiler: The result of the above is that Rust, under MSVC, will happily put together and , but will fail utterly when a is demanded under the present set of circumstances. This is the other half required to completely address the issue in -- I tried working around this by inserting plus setting the correct file name, as shown in , but it returns an error: This is already known and was never addressed: <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace of the big linker error</summary<p</p</details
Any update on this issue?
I see you have done quite a bit of work here, thank you! Is there anything I can do to help move this forward? I can try to build this custom branch and test if it works?
Apologies, I now see the relevant issue is already being worked on!
Change:
self.command.env(key.as_ref(), value.as_ref()); self } <ins> pub fn add_rustc_lib_path(&mut self, builder: &Builder<'_>, compiler: Compiler) { builder.add_rustc_lib_path(compiler, &mut self.command); } </ins> } impl From<Cargo> for Command {

Discussion:
I tried to build rust right after got merged and caught error:
cc
What command did you run?
Change:
<ins> // Regression test for issue #95717 // Hide cross-crate `#[doc(hidden)]` associated items in trait impls. #![crate_name = "dependent"] // edition:2021 // aux-crate:dependency=cross-crate-hidden-assoc-trait-items.rs // The trait `Tr` contains 2 hidden and 2 visisible associated items. // Instead of checking for the absence of the hidden items, check for the presence of the // visible items instead and assert that there are *exactly two* associated items // (by counting the number of `section`s). This is more robust and future-proof. // @has dependent/struct.Ty.html // @has - '//*[@id="associatedtype.VisibleAssoc"]' 'type VisibleAssoc = ()' // @has - '//*[@id="associatedconstant.VISIBLE_ASSOC"]' 'const VISIBLE_ASSOC: ()' // @count - '//*[@class="impl-items"]/section' 2 // @has dependent/trait.Tr.html // @has - '//*[@id="associatedtype.VisibleAssoc-1"]' 'type VisibleAssoc = ()' // @has - '//*[@id="associatedconstant.VISIBLE_ASSOC-1"]' 'const VISIBLE_ASSOC: ()' // @count - '//*[@class="impl-items"]/section' 2 pub use dependency::{Tr, Ty}; </ins>

Discussion:
Minimal reproducible example (on stable and nightly): Document crate and take a look at the generated pages of and : You should be able to actually see the associated type in the block despite being marked as hidden. You probably need to click (expand) first. The block I refer to is in section Implementors on the trait page and in section Trait Implementations on the implementor's page. It should be noted that even though wrongly shows up in those blocks, it is indeed not shown in the code block at the start of the trait page – at the “definition site” if you will (compared to the “use sites” – the blocks). It is crucial that the trait and the type are defined inside of an external crate. If they were defined in the “current” crate, this bug would not occur: The hidden associated items would not be shown. You can check this for yourself by documenting on its own and viewing its documentation separately, or by re-exporting the crate from (e.g. with ) and then documenting : On the page for , the associated item is hidden On the page for the re-export , however, the associated item is displayed after a CI job failed because the linkchecker complained about broken links in the standard library when documenting it with a modified rustdoc. The broken links are not relevant for this bug, they are mere symptoms of it: If everything was properly hidden, no broken links would ever be generated. This bug currently affects the standard library documentation (for stable and nightly) as mentioned in the linked comment. In this case, the trait is  the type is  the associated type that shouldn't be shown is crate “alpha” is crate “beta” is label T-rustdoc A-cross-crate-reexports <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<del> Subproject commit 05fdec916a3a9755c6ea603bab79cdb2f7c062bf </del> <ins> Subproject commit 15e81a94b1aff99f7c38151d6976757ee0ed0097 </ins>

Discussion:
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! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
let infcx = self.fields.infcx; let a = infcx.type_variables.borrow_mut().replace_if_possible(a); let b = infcx.type_variables.borrow_mut().replace_if_possible(b); <ins> debug!("{}.tys: replacements ({:?}, {:?})", self.tag(), a, b); </ins> match (&a.sty, &b.sty) { (&ty::Infer(TyVar(a_id)), &ty::Infer(TyVar(b_id))) => { infcx.type_variables.borrow_mut().equate(a_id, b_id);

Discussion:
When using the nightly with the bugfix for the problems with , this error happens when trying to document the crate: note: rustc 1.31.0-nightly ( 2018-10-01) running on x86_64-apple-darwin
cc: FYI
it seemed to document fine for me on the most recent nightly build
This is fixed as of
Closing then! Thanks! :D
Will this need backporting at all?
Change:
offset.map(|n| n as _).as_ref(), None, ); <ins> let status = if status == c::STATUS_PENDING { c::WaitForSingleObject(self.as_raw_handle(), c::INFINITE); io_status.status() } else { status }; </ins> match status { // If the operation has not completed then abort the process. // Doing otherwise means that the buffer and stack may be written to // after this function returns. <del> c::STATUS_PENDING => { eprintln!("I/O error: operation failed to complete synchronously"); crate::process::abort(); } </del> <ins> c::STATUS_PENDING => rtabort!("I/O error: operation failed to complete synchronously"), </ins> // Return `Ok(0)` when there's nothing more to read. c::STATUS_END_OF_FILE => Ok(0),

Discussion:
on windows. with and rename it back to git bash I expected to see this happen: my really long string gets printed twice, followed by a clean exit Instead, this happened: some amount of my really long string gets printed, followed by: The test case, while simple, does appear to have a minimum size requirement to trigger this crash. Shrinking the string will cause it to stop crashing. I'm using in the steps for simplicity, but we've observed this happening with other programs at the end of the pipe too. Redirecting to a file instead of a pipe seems to not trigger this crash. Using is not necessary to trigger the crash, running the built executable directly also crashes. This PR this new error condition: I am not the only one seeing this new error message: modify labels: +regression-from-stable-to-stable +O-windows
I believe this must be because git bash (cygwin? msys?) is opening pipes between processes with . In my original bug report, I suggested calling once if returned , since that will at least resolve the pending IO correctly in the case where the file is not being used for other IOs concurrently. This would cover this and other cases at least as well as the original code calling . This isn't perfect, since of course takes , so you can probably deadlock in a multi-threaded process in this async pipe configuration. But it would at least avoid the common case. However, it seems that this got missed from the actual change (sorry, I should have caught that). Is there a reason this was skipped?
Oh, hrm. That looks like an oversight on my part. I'll PR a fix asap.
Thanks for fixing the issue quickly. When the PR that fixes this issue is merged, will a patch release 1.62.1 be published? Or will we have to wait for a fix in 1.63?
PR was nominated and accepted for both beta and stable backport by T-libs. Leaving this open until those play out. Assigning P-high for the same reasons it was accepted for backports.
Change:
<ins> error: compilation successful --> $DIR/borrowck-box-insensitivity.rs:160:1 | LL | / fn main() { //[mir]~ ERROR compilation successful LL | |     copy_after_move(); LL | |     move_after_move(); LL | |     borrow_after_move(); ...  | LL | |     mut_borrow_after_borrow_nested(); LL | | } | |_^ error: aborting due to previous error </ins>

Discussion:
The revision system lets encode different sets of errors for different invocations of the compiler. and normally attempts to catch cases where you left out expected error messages by saying "if you have any annotation in your file, then the set of such annotations needs to match the same set of errors that are actually emitted. However, if you combine these features, then for each revision (call it ) in the revisions list, at least one of your errors currently need to be written with the revision system in mind, e.g. If none of the error annotations include a revision (i.e., if they are all ), then thinks that the test has no error annotations, and thus treats it as a case where the compiler's error output is blindly accepted. That seems bad.
cc
This is surely no longer the case, because and annotations are now mandatory?
With annotation for warnings and errors being mandatory , and additionally annotations applying to all revisions , this should be non-issue.