jiebi/CodeConvo huggingface dataset:
Code change:
impl<'tcx> OpaqueTypeExpander<'tcx> { fn expand_opaque_ty(&mut self, def_id: DefId, substs: SubstsRef<'tcx>) -> Option<Ty<'tcx>> { <del> if self.found_recursion { </del> <ins> if self.found_any_recursion { </ins> return None; } let substs = substs.fold_with(self);

Related discussion:
text: I tried this code: I expected running to produce an error like: It does, but takes time exponential in the number of calls, although doesn't appear to use any extra memory. In the time take looks like: I believe it's also exponential in the number of calls in . The reason I had code like this was because I was using nom's parser combinators which results in lots of nested closures. I spotted it because this caused rust-analyzer to hang because cargo clippy hung (it looks like check was the issue), I had to kill clippy to fix it. I bisected this (with cargo-bisect-rustc) to find the regression in , which contained the following bors commits: merge of - Centril:rollup-rzvry15, r=Centril merge of - tmandry:rollup-0k6jiik, r=tmandry merge of - Manishearth:clippyup, r=Manishearth merge of - tanriol:explain_borrow-use-context-dominators, r=nagisa merge of - ehuss:update-cargo-books, r=alexcrichton modify labels: +regression-from-stable-to-stable -regression-untriaged
what version of rust are you using? Is this also present on nightly?
Good question! This repros on the latest nightly () and on stable (1.53.0 2021-06-17).
Regression means that it was linear, or exponential, but smaller?
I didn't looks to still be exponential just much quicker, and with a smaller base (~2 vs ~14):
looks related
Bisected to innocent-looking commit . Removing the caching from in master does indeed fix the issue. I haven't looked at the how or why or where that causes (other) problems though. cc
Hmm, the only thing that looks expensive there is the hashing - I wonder if it's hashing over and over again without ever getting a cache hit? Hashing has a fixed cost, but can be an arbitrary length:
cuts down on time for this testcase and others with invalid recursive opaque types by bailing out early if a recursion is found.
Code change:
impl<'tcx> OpaqueTypeExpander<'tcx> { fn expand_opaque_ty(&mut self, def_id: DefId, substs: SubstsRef<'tcx>) -> Option<Ty<'tcx>> { <del> if self.found_recursion { </del> <ins> if self.found_any_recursion { </ins> return None; } let substs = substs.fold_with(self);

Related discussion:
text: This fixes the regression but the check time is still exponential in the recursion: #wraps|time (s) ---|--- 23|9.2 24|18.3 25|36.6 Not sure if that matters in practice though.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
That's the same as before the regression, right? I definitely think that's a change worth making :) I expect the doubling will have a completely different cause.
Yes, same ballpark.
Code change:
/// Options for rendering Markdown in the main body of documentation. pub(crate) fn opts() -> Options { <del> Options::ENABLE_TABLES | Options::ENABLE_FOOTNOTES | Options::ENABLE_STRIKETHROUGH </del> <ins> Options::ENABLE_TABLES | Options::ENABLE_FOOTNOTES | Options::ENABLE_STRIKETHROUGH | Options::ENABLE_TASKLISTS </ins> } /// A subset of [`opts()`] used for rendering summaries.

Related discussion:
text: These include: The reasoning for all of these extensions is that they all have wide use not just in GitHub, but in many applications of Markdown.
I'm not sure if automatically creating links from bare domain names is a good idea, so if there's an option to disable that specifically I'd suggest it. The rest all seems fine to me.
Just like said for Autolinks. I'm also not sure to see the point of the task list one. However, adding strikethrough would be nice.
Tasklist would be useful for things like this: [x] Implemented thing [x] Some other implemented thing [ ] Unimplemented thing [ ] Some other unimplemented thing or possibly in the crate root [x] Webhooks [x] Websockets [ ] Websites [ ] Other
Another noteworthy extension to implement is . This would prevent the following tags from being used for safety reasons: - - - - -
We decided in not to add this. Instead rustdoc will now suggest to turn raw links into automatic links (). So I think the only thing left is adding task list parsing.
Code change:
- env: IMAGE=dist-x86_64-linux DEPLOY_ALT=1 - env: > RUST_CHECK_TARGET=dist <del> RUST_CONFIGURE_ARGS="--enable-extended" </del> <ins> RUST_CONFIGURE_ARGS="--enable-extended --enable-profiler" </ins> SRC=. DEPLOY_ALT=1 RUSTC_RETRY_LINKER_ON_SEGFAULT=1

Related discussion:
text: Steps to reproduce: Alternative steps to reproduce that will provides a suitable compiler: On OS X, with LLVM assertions disabled (like in rustc builds in , which are the default in Servo’s ), rustc 1.20.0-nightly ( 2017-06-28) fails with: This problem does not occur with from rustup, which has LLVM assertions enabled. (But perhaps that’s not the only difference between the two kinds of builds?)
What’s ?
It’s also enabled in the "non-alt" build, so probably not relevant.
Have you tried building the project in the same disk partition where you've installed rustc, i.e. inside ?
Yes. With the second set of steps (and ), the error message looks like this:
Does show anything special?
not as far I can tell.
Okay... There are for dyld but I doubt if they are useful. The problem is that is not found, meaning is not expanded properly. I've checked does not* have an load command, meaning the is only supplied through . I don't think the alt-build's and normal build's Cargo has any difference though. Verify if is correct?
with and without in : Both contain:
Both contains directly inside ? (not )
Almost, the one has a different hash:
Huh, that's even stranger. The should be resolved correctly. But the alt- rustc linked using the libstd from the non-alt-build??
Well it sounds unlikely to me that “from the other build” is really what’s going on, I’d bet on incorrect hashing. How is the hexadecimal part of determined? What base values are being hashed?
IIRC rustc will just search for all , it doesn't recompute the hash. Would it work if you move out of , and then do a + ?
I first hit the issue before the "non-alt" build was downloaded.
I've tried to reproduce it myself and it seems plays a role in finding which is linked. I can make it link to the correctly hashed by: "Install" it sure does not contain , and includes it. It should work. Overriding without installing causes rustc not able to find .
What is "it" and what does "installing" mean?
Run after extracting the tarball (sorry was on mobile so did not check the exact instruction).
What does this do besides copying the files?
Code change:
- env: IMAGE=dist-x86_64-linux DEPLOY_ALT=1 - env: > RUST_CHECK_TARGET=dist <del> RUST_CONFIGURE_ARGS="--enable-extended" </del> <ins> RUST_CONFIGURE_ARGS="--enable-extended --enable-profiler" </ins> SRC=. DEPLOY_ALT=1 RUSTC_RETRY_LINKER_ON_SEGFAULT=1

Related discussion:
text: Regardless, this is a regression, it only happens on OS X, and only with "alternate" builds…
It looks like the problem is presumably that and don't have the same hash. One fairly clear problem is that Servo for some reason doesn't download rust-std from alt by-default AFAICT; having some quick prints to the util script. That would lead to incompatibilities; this should be fixed.
I've filed which should fix this.
Good catch! This fixes the problem, thank you.
Code change:
# https://github.com/puppeteer/puppeteer/issues/375 # # We also specify the version in case we need to update it to go around cache limitations. <del> RUN npm install -g browser-ui-test@0.2.12 --unsafe-perm=true </del> <ins> RUN npm install -g browser-ui-test@0.2.14 --unsafe-perm=true </ins> ENV RUST_CONFIGURE_ARGS  --build=x86_64-unknown-linux-gnu 

Related discussion:
text: It looks like a CSS rule is being applied incorrectly. It also looks weird if you click through to the type alias's page (). ! !
I'm not really sure, could that be slipped in ?
It turns out it was actually much more recent. The PR causing the regression was , cc searched nightlies: from nightly-2021-05-01 to nightly-2021-06-12 regressed nightly: nightly-2021-06-04 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
The culprit CSS rule is here: It also caused which was fixed by .
Ah, I have missed this one. Sending a fix.
Assigning priority as in the prioritization working group. label: +P-medium -I-prioritize
The fix should be merged in less than 3 hours. ;)
I know, but we had already agreed on a priority :)
Oh I see. Thanks for taking care of that then! :)
Code change:
use libc::{mmap, mprotect}; use libc::{MAP_ANON, MAP_FAILED, MAP_FIXED, MAP_PRIVATE, PROT_NONE, PROT_READ, PROT_WRITE}; <ins> use crate::io; </ins> use crate::ops::Range; use crate::sync::atomic::{AtomicUsize, Ordering}; use crate::sys::os;

Related discussion:
text: There is too little confidence in this mistake, why not return to errno. The mmap interface provides the errno, such as the ENOMEM and SIGSEGV interfaces. panic!("failed to allocate an alternative stack")
!
Please try again your code latest nightly Rust version. Also could you paste the ICE backtrace? label E-needs-mcve I-ICE
This is not a ICE This issue propose printing errno on this :
Probably we want this then: label: -I-ICE, -T-compiler, +T-libs
Code change:
} } <del> clean::ExternCrateItem(..) | clean::ImportItem(_) => { if i.visibility != Some(hir::Public) { return None } } </del> clean::StructFieldItem(..) => { if i.visibility != Some(hir::Public) { return Some(clean::Item {

Related discussion:
text: Rustdoc defaults to only documented things that are public, i.e. things that the user of a library would care about. This is a good default, but rustdoc can also be useful to people working on large crates by documenting these crates themselves. In that case, it’s preferable to also include private types, fields, functions, and methods. was about this use case, and was closed with this solution: We just tried this on . It’s better than before, but has the unexpected side effect that every item (including non- and the implicit prelude) and every (including the implicit ) is documented under “Reexports”. It can get pretty noisy: ! They’re technically part of the crate, but don’t provide useful information. Could rustdoc split up the pass into one that strips private and , and one for everything else?
Code change:
RelateOutputImplTypes(span) => span, MatchExpressionArm(match_span, _) => match_span, IfExpression(span) => span, <ins> IfExpressionWithNoElse(span) => span </ins> } } }

Related discussion:
text: I apologize in advance if this is a separate issue. With the map() generic function from the tutorial: That code gives a nice error message: However, remove the assignment and what should be the same error message becomes:
Yes, that is unrelated to this issue. You're seeing an expected type mismatch error since the return type of main() is () and your samples result in two different non-() results.
Thanks I was one hour into learning Rust when I came across this. I understand what is going on now. I still think the error message could be improved to mention that "expected " is referring to the return type of main(). That simple clue could help people not as familiar with Rust to remember the semicolon rule to turn a statement into an expression.
Not critical for 0.7, but improving error messages is always good. Nominating for milestone 5.
declined. this is bad but it's not a blocker.
Confirmed that the situation is unchanged.
This is still an issue.
Bug triage. Still an issue.
Very, very small change:
Code change:
<ins> pub trait Ice { fn f(&self, _: ()); } impl Ice for () { fn f(&self, _: ()) {} } fn main() { ().f::<()>(()); //~^ ERROR this associated function takes 0 generic arguments but 1 generic argument was supplied } </ins>

Related discussion:
text: Repros on the /current nightly. But works (gives an error about mismatched number of generic arguments) on stable and beta. s/o to for the minimal example. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label regression-from-stable-to-nightly
Regressed in (nightly-2022-09-02), presumably , though seems to have already made the connection to that PR anyways :-)
Code change:
kind_name, tcx.item_path_str(variant.did), field_names); <del> if let Some((span, _)) = inexistent_fields.last() { </del> <ins> if let Some((span, ident)) = inexistent_fields.last() { </ins> err.span_label(*span, format!("{} `{}` does not have {} field{}", kind_name, tcx.item_path_str(variant.did), t, plural)); <ins> if plural == "" { let input = unmentioned_fields.iter().map(|field| &field.name); let suggested_name = find_best_match_for_name(input, &ident.name.as_str(), None); if let Some(suggested_name) = suggested_name { err.span_suggestion(*span, "did you mean", suggested_name.to_string()); // we don't want to throw `E0027` in case we have thrown `E0026` for them unmentioned_fields.retain(|&x| x.as_str() != suggested_name.as_str()); } } </ins> } if tcx.sess.teach(&err.get_code().unwrap()) { err.note(

Related discussion:
text: With a single typo in a match arm, we generate three separate errors: We should collect all these errors into a single diagnostic:
could you share sample code to exactly reproduce above diagnostic?
I will raise another PR to address the case where we are unnecessarily throwing .
Code change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test transitive analysis for associated types. Collected types // should be normalized and new obligations generated. trait Foo { type A; fn foo(&self) {} } impl Foo for usize { type A = usize; } struct Bar<T: Foo> { inner: T::A } fn is_send<T: Send>() {} fn main() { is_send::<Bar<usize>>(); } </ins>

Related discussion:
text: For example, this code does not compile: cc
I think this may be another instance of
Trusting analysis, closing in favor of but adding test case there as well.
(it of course would be good to confirm that this actually is an instance of -- my initial reaction when I saw it was "they might be related ... but wait, wasn't part of the opt-in-builtin-bounds work to be able to move the special case handling of / out into library code...?"; I've only done some rough skimming that makes me think the hypothesis remains plausible.)
Ah either way is fine by me, I personally like fewer issues :). We can reopen once is addressed one way or another if necessary (or if you'd like to reopen now that's also fine by me!)
oh that was really just a note to myself as much as anything else, not a comment on your choice to close this ticket. :)
I don't think this code uses type-contents. If it does, that is itself a bug! Either way, we should keep this open for the time being.
cc
Code change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test transitive analysis for associated types. Collected types // should be normalized and new obligations generated. trait Foo { type A; fn foo(&self) {} } impl Foo for usize { type A = usize; } struct Bar<T: Foo> { inner: T::A } fn is_send<T: Send>() {} fn main() { is_send::<Bar<usize>>(); } </ins>

Related discussion:
text: The following doesn't compile, but I believe it should: Error: Even though , and . In fact, this compiles:
should be , because the old definition that didn't use assoc types was . Probably the code that detects builtin bounds wasn't updated to handle associated types. cc
This breaks us in hyper. For now, I'll have to manually , knowing that it's safe.,,
Code change:
fn to_radians(self) -> f64 { num::Float::to_radians(self) } #[inline] <del> fn ldexp(x: f64, exp: int) -> f64 { unsafe { cmath::ldexp(x, exp as c_int) } </del> <ins> fn ldexp(self, exp: isize) -> f64 { unsafe { cmath::ldexp(self, exp as c_int) } </ins> } /// Breaks the number into a normalized fraction and a base-2 exponent,

Related discussion:
text: has an unusual format: it takes as it's first parameter where everything else in the trait takes . It should take as it's first parameter for consistency with everything else. It is located in 
+1. There are a few different things to consider here, though: does not operate on any FP number per se like most other operations do, but rather constructs a new FP number from two arguments one of which happens to be FP number. This function’s signature is consistent with most other methods that construct some kind of FP number (e.g. ). We might want to consider whether methods such as shouldn’t just go ahead and take instead. can’t currently be chained, but I see literally 0 cases where anybody would chain this function. cc
Okay, but from a consistency standpoint, it's like 1/80 for vs . It it keeps the same format, it and it's similar functions would probably be better to go at the end or beginning of the function list where they won't be so unusual.
Nominating for 1.0-beta P-backcompat-libs
One should be able to call this thing as a method, one way or another. We need to make sure that is resolved.
0 beta, P-backcompat-libs
I started to fix this.
Code change:
<ins> error[E0599]: no method named `b` found for reference `&Self` in the current scope --> $DIR/issue-117794.rs:5:14 | LL |         self.b(|| 0) |              ^ help: there is a method with a similar name: `a` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0599`. </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'error: internal compiler error: expected type of closure to be a closure', 'error: internal compiler error: expected type of closure to be a closure' File: --auto-reduced (treereduce-rust): original: Version information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: [mirbuilt] building MIR for [unsafetycheckresult] unsafety-checking [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkmoditemtypes] checking item types in top-level module [analysis] running analysis passes on this crate --
regression in ping
nice, that's one of the ICE messages I just too
Code change:
<ins> error[E0599]: no method named `b` found for reference `&Self` in the current scope --> $DIR/issue-117794.rs:5:14 | LL |         self.b(|| 0) |              ^ help: there is a method with a similar name: `a` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0599`. </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'no entry found for key'', 'thread 'rustc' panicked at 'no entry found for key'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in nightly-2023-11-08 / ping
I think is fixing an issue that may have the same root cause.
Code change:
<ins> error[E0599]: no method named `b` found for reference `&Self` in the current scope --> $DIR/issue-117794.rs:5:14 | LL |         self.b(|| 0) |              ^ help: there is a method with a similar name: `a` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0599`. </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in nightly-2023-11-08 / ping
This should be fixed by
I'm intrigued as to why you believe could rectify this problem. The issue can be distilled as follows: It results in a panic at due to the closure utilizing the type from its outermost function, eventually returning . This issue appears to be unrelated to .
You're provably correct, and I am likely wrong about the root cause of the issue. I will look tomorrow. Feel free to claim this issue if you've already found a solution in the process of investigation.
Code change:
assert_eq!("ΑΣ''Α".to_lowercase(), "ασ''α"); // https://github.com/rust-lang/rust/issues/124714 <ins> // input lengths around the boundary of the chunk size used by the ascii prefix optimization assert_eq!("abcdefghijklmnoΣ".to_lowercase(), "abcdefghijklmnoς"); </ins> assert_eq!("abcdefghijklmnopΣ".to_lowercase(), "abcdefghijklmnopς"); <ins> assert_eq!("abcdefghijklmnopqΣ".to_lowercase(), "abcdefghijklmnopqς"); </ins> // a really long string that has it's lowercase form // even longer. this tests that implementations don't assume

Related discussion:
text: I'm looking into the performance of / on mostly ascii strings, using a small microbenchmark to . Using linux perf tooling I see that the hot part of the code is the following large loop, which despite heavy use of sse2 instructions only seems to process 32 bytes per iteration. I don't see an easy way to improve the autovectorization of this code, but it should be relatively easy to explicitly vectorize it using , and I would like to prepare such a PR if there are no objections. As far as I know, is already in use inside , for example by .
The way the loop ors the bits for the is-ascii check into a single usize doesn't seem ideal for vectorization. keeping the lanes independent should yield better autovectorization results.
Thanks for the suggestion. I already started with a simd implementation, but now checked again if the autovectorization could be improved. With the following main loop The assembly and performance is indeed better, but there is still some weird shuffling and shifting going on: The explicit simd version looks a bit better, mostly because the ascii check directly translates to a : Do you have a preference here between autovectorization and explicit simd?
If the SIMD impl results in reasonable code across architectures, including some without SIMD then that should be fine. I think it would be the first time where we use portable simd unconditionally, so it could use some additional scrutiny. If it's only meant to target x86 with SSE2 then that'd mean having multiple paths and in that case we'd still have to tweak the generic path anyway. At that point we might as well just optimize the latter further. You can probably get rid of those too by keeping multiple bools in a small array. That way the optimizer will more easily see that it can shove them into independent simd lanes. Increasing the unroll count might help too to fit better into simd registers. We do get pretty decent autovectorization in other places in the standard library by massaging things into a state that basically looks like arrays-instead-of-SIMD-types. E.g.
It seems llvm is too "smart" for this trick, on its own that generates the exact same code. The trick does work, although it seems a bit fragile.