jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // edition:2018 use std::convert::{TryFrom, TryInto}; use std::io; pub struct MyStream; pub struct OtherStream; pub async fn connect() -> io::Result<MyStream> { let stream: MyStream = OtherStream.try_into()?; Ok(stream) } impl TryFrom<OtherStream> for MyStream {} //~^ ERROR: missing fn main() {} </ins>

Related discussion:
text: <!-- 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. --produces an ICE for the code given below. This code should produce an error (the implementation is missing associated items). (UPDATED: Here's MCVE: ) <!-- 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. --: Error also occurs on beta and nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Thanks! Further minimized:
Assigning as and removing .
Don't know the cause yet, but if you remove the keyword or the operator, then you get this error: My hunch is that somehow, lacking those items, the type of is coming up with something that doesn't implement the expected traits -- I would bet that we are getting an , based on some of the output at the end. Perhaps some of the logic in MIR is failing as a result. The actual ICE location though isn't that illuminating:
I did some digging here. The source of the panic is here, during HAIR construction: In this case, the binding below is of the error type (meaning type check for it failed). By replacing the binding with `` we prevent a local from being created for it, which means that when we try to generate code that reads the local we get a panic . I'm not sure what the correct fix is here. Replacing the binding with was done to prevent other ICEs, but we can't generate valid MIR without the local info. More fundamentally: We're building MIR during typeck because this is an async fn. In the past we probably never would have gotten to this stage. Backtrace: <details</details
Code change:
<ins> // Nested impl-traits can impose different member constraints on the same region variable. // check-fail trait Cap<'a> {} impl<T> Cap<'_> for T {} // Assuming the hidden type is `[&'_#15r u8; 1]`, we have two distinct member constraints: // - '_#15r member ['static, 'a, 'b] // from outer impl-trait // - '_#15r member ['static, 'a, 'b] // from inner impl-trait // To satisfy both we can choose 'a or 'b, so it's a failure due to ambiguity. fn fail_early_bound<'s, 'a, 'b>(a: &'s u8) -> impl IntoIterator<Item = impl Cap<'a> + Cap<'b>> where 's: 'a, 's: 'b, { [a] //~^ E0700 //~| E0700 } // Same as the above but with late-bound regions. fn fail_late_bound<'s, 'a, 'b>( a: &'s u8, _: &'a &'s u8, _: &'b &'s u8, ) -> impl IntoIterator<Item = impl Cap<'a> + Cap<'b>> { [a] //~^ E0700 //~| E0700 } fn main() {} </ins>

Related discussion:
text: The following code should pass regardless of the declaration order of lifetimes: This is related to but it's different in that we do have a lower bound region, , but we fail to recognize that because , which is responsible for calculating from , assumes that the outlive relation is a total order, which is not true. Here is the graph of : ! So we need an efficient algorithm that works for partial order relations, but the one that comes to mind is . The perf may not be really important here but I'm curious to see the alternatives. label C-bug T-compiler A-borrow-checker E-mentor E-help-wanted <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Here is the code of concern The code should calculate the from a set of universal regions (). The relations are encoded in and are guaranteed to be transitive and reflexive. The relation graph may have cycles and can be sparse. The goal here is to find a unique minimum choice that is known to be outlived by all other regions. If none can be found, the function returns . Regions that have cycles between them are considered equivalent so we can pick either one of them as a unique choice. e.g. , we can pick either one of as a minimum choice.
Code change:
<ins> error: `panic_impl` language item function is not allowed to have `#[target_feature]` --> $DIR/panic-handler-with-target-feature.rs:11:1 | LL | #[target_feature(enable = "avx2")] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LL | LL | fn panic(info: &PanicInfo) -> ! { | ------------------------------- `panic_impl` language item function is not allowed to have `#[target_feature]` error: aborting due to previous error </ins>

Related discussion:
text: This works (but it shouldn't): similar to , cc (tracking issue) label T-lang T-compiler C-bug I-unsound F-targetfeature11
cc , author of Note that this is about the nostd panic handler, not about the function. This fails as it should: gives
ugh we really need a way to make sure that every single "this is called by rust" function gets a check... I assume that these functions can't be unsafe, so I guess those checks are a food way to start looking and make sure to deduplicate the logic there?
Yeah sadly we do need to make sure, not just for the constructs that we have now but also it needs to be kept in mind for the future constructs we add or stabilize. A lot thankfully goes through either the trait system (operators or the GlobalAlloc trait used by ) or function pointers (alloc error hook, std panic hook). Functions that you can make callable solely by setting an attribute, those are rare. The best list of lang items I could find was in the , so that would be a great start for such an exhaustive search. Thankfully most of them are unstable, but still it needs to be addressed for each of them before stabilization (if that is a target).
WG-prioritization assigning priority (). label -I-prioritize +P-medium
label +requires-nightly
There is also another table of lang items in the source code, .
Code change:
"arch": "x86_64", "cpu": "x86-64", "crt-static-respected": true, <del> "data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128", </del> <ins> "data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128", </ins> "dynamic-linking": true, "env": "gnu", "executables": true,

Related discussion:
text: The commit a check that stars firing due to the changes to the default target layouts in LLVM 18 ():
Having this issue on as well: Why it's trying to compile for a 32-bit target is clearly beyond me because I'm using an entirely 64-bit host ― since happens to be the author of the crate this is failing on (namely, the 32-bit BIOS version of the bootloader crate which I explicitly avoid depending on for my intendedly UEFI-only kernel), pinging him for assistance.
I think this issue thread is about some failing tests in the Rust repo. Your issue seems to be specific to the crate, which required some updates to the custom targets it is using. I published a new version already, which should fix the issue. If you still have issues with the crate after a , please open an issue in the repository.
Code change:
<ins> // run-pass #![allow(dead_code)] enum E { A, B } fn main() { match &&E::A { &&E::A => { } &&E::B => { } }; } </ins>

Related discussion:
text: root: yup-oauth2 - 360 detected crates which regressed due to this; cc <details</details
I think this might have been caused by
I can confirm that is the cause. Patch coming shortly.
Code change:
<ins> error[E0311]: the parameter type `T` may not live long enough --> $DIR/issue-86483.rs:6:1 | LL |   pub trait IceIce<T> |   ^                - help: consider adding an explicit lifetime bound...: `T: 'a` |  _| | | LL | | where LL | |     for<'a> T: 'a, LL | | { ...  | LL | | LL | | } | |_^ ...so that the type `T` will meet its required lifetime bounds error[E0311]: the parameter type `T` may not live long enough --> $DIR/issue-86483.rs:10:5 | LL | pub trait IceIce<T> |                  - help: consider adding an explicit lifetime bound...: `T: 'a` ... LL |     type Ice<'v>: IntoIterator<Item = &'v T>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ...so that the type `T` will meet its required lifetime bounds error[E0309]: the parameter type `T` may not live long enough --> $DIR/issue-86483.rs:10:32 | LL | pub trait IceIce<T> |                  - help: consider adding an explicit lifetime bound...: `T: 'v` ... LL |     type Ice<'v>: IntoIterator<Item = &'v T>; |                                ^^^^^^^^^^^^ ...so that the reference type `&'v T` does not outlive the data it points at error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0309`. </ins>

Related discussion:
text: <!-- 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. --%5D%0D%0Apub%20trait%20IceIce%3CT%3E%0D%0Awhere%0D%0A%20%20%20%20for%3C'a%3E%20T%3A%20'a%2C%0D%0A%7B%0D%0A%20%20%20%20type%20Ice%3C'v%3E%3A%20IntoIterator%3CItem%20%3D%20%26'v%20T%3E%3B%0D%0A%7D%0D%0A%0D%0Afn%20main()%20%7B%7D%0D%0A) <!-- 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. --The ICE happens on , and : : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Maybe related to
Bisection: bash cargo bisect-rustc --regress ice --test-dir=foo `
Looks like
ICE happens on stable and also even without the line so no requires-nightly. label regression-from-stable-to-stable, A-traits
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
Code change:
<ins> error: to use a constant of type `Vec<u8>` in a pattern, `Vec<u8>` must be annotated with `#[derive(PartialEq, Eq)]` --> $DIR/issue-115599.rs:5:12 | LL |     if let CONST_STRING = empty_str {} |            ^^^^^^^^^^^^ | = note: the traits must be derived, manual `impl`s are not sufficient = note: see https://doc.rust-lang.org/stable/std/marker/trait.StructuralEq.html for details error: aborting due to previous error </ins>

Related discussion:
text: <!-- 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. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: This bug was also reproduced in the stable version(1.72) <!-- 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 --
claim
Hmm this was caused by cc
claim
Code change:
/// Takes a path to a source file and cleans the path to it. This canonicalizes /// things like ".." to components which preserve the "top down" hierarchy of a <del> /// static HTML tree. </del> <ins> /// static HTML tree. Each component in the cleaned path will be passed as an /// argument to `f`. The very last component of the path (ie the file name) will /// be passed to `f` if `keep_filename` is true, and ignored otherwise. </ins> // FIXME (#9639): The closure should deal with &[u8] instead of &str // FIXME (#9639): This is too conservative, rejecting non-UTF-8 paths <del> fn clean_srcpath<F>(src_root: &Path, p: &Path, mut f: F) where </del> <ins> fn clean_srcpath<F>(src_root: &Path, p: &Path, keep_filename: bool, mut f: F) where </ins> F: FnMut(&str), { // make it relative, if possible let p = p.relative_from(src_root).unwrap_or(p); <del> for c in p.iter().map(|x| x.to_str().unwrap()) { </del> <ins> let mut iter = p.iter().map(|x| x.to_str().unwrap()).peekable(); while let Some(c) = iter.next() { if !keep_filename && iter.peek().is_none() { break; } </ins> if ".." == c { f("up"); } else {

Related discussion:
text: When visiting a page such as or the link src (for the source code) no longer works. Instead a 404 is returned. This seems to have been broken for several days now.
even before this, many but not all were broken. there may be multiple issues with this symptom.
The links link in the form but it seems like the actual source is being placed in a location in the form For example here's a link from the current docs which will 404: But the following will resolve:
Really annoyed by this. :<
Code change:
pub use reexports::foo; // @has 'foo/outer/inner/fn.foo_crate.html' '//pre[@class="rust item-decl"]' 'pub(crate) fn foo_crate()' pub(crate) use reexports::foo_crate; <del> // @has 'foo/outer/inner/fn.foo_super.html' '//pre[@class="rust item-decl"]' 'pub(in outer) fn foo_super( )' </del> <ins> // @has 'foo/outer/inner/fn.foo_super.html' '//pre[@class="rust item-decl"]' 'pub(in outer) fn foo_super()' </ins> pub(super) use::reexports::foo_super; // @!has 'foo/outer/inner/fn.foo_self.html' pub(self) use reexports::foo_self;

Related discussion:
text: Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
self.suggest_cloning(err, ty, expr, None, Some(move_spans)); } } <del> if let Some(pat) = finder.pat { </del> <ins> self.suggest_ref_for_dbg_args(expr, place, move_span, err); // it's useless to suggest inserting `ref` when the span don't comes from local code if let Some(pat) = finder.pat && !move_span.is_dummy() && !self.infcx.tcx.sess.source_map().is_imported(move_span) { </ins> *in_pattern = true; let mut sugg = vec![(pat.span.shrink_to_lo(), "ref ".to_string())]; if let Some(pat) = finder.parent_pat {

Related discussion:
text: No response No response No response
I thought the intent with was to use it in a passthrough style, so you can insert it into existing expressions ie. becomes . In which case, maybe the lint should be for not using the value resulting from evaluating .
Not sure about the majority of users but for me is a convenience over . I use it without using the return value almost all of the time.
Probably a common thing to do, sure, but if we're talking about adding a lint, why not nudge the user in the direction of the intended and documented usage? You could at least do both: "insert into an existing expression or pass it a borrow" etc.
The fix in will only report a hint when there is already a happened. For example this code: before this fix the error is: with the fix, since there is already a error, the lint will try to find out the original macro, and suggest a borrow: The suggestion is not 100% right, since if we change it to , we need one more extra fix now(the return type is not expecting a reference), but there is a different issue, at least we have already moved one step on. If the original code is: Then suggest a borrow is a great and correct hint.
Similar in the scenario of function argument: original error is: new errors from the fix:
Would not also be a good hint? The suggestion wouldn't compile anyway right? Because would need to change to take ? Without involved, the compiler does indeed suggest that: Once that's addressed (whichever way it's done), once again becomes transparent, and eg. or works. does not, however, and I see why a "consider borrowing" hint would be good there. However, if you make the change first and leave as-is, the resulting error does not include the suggestion to change , which is unhelpful. (I agree that the message is even less helpful though, I'm not disputing that.)
Yes, it's a good hint, but from the implementation view of a hint, it's much harder to analyze the following code from the error point and then construct a new expression. Even it seems an easy thing for humans. You are right, the suggestion is not 100% right, we may need an extra follow-up fix after applying the hint, which is also a common thing in rustc diagnostics.
Code change:
match outlives_bound { OutlivesBound::RegionSubRegion(r1, r2) => { <ins> // `where Type:` is lowered to `where Type: 'empty` so that // we check `Type` is well formed, but there's no use for // this bound here. if let ty::ReEmpty = r1 { return; } </ins> // The bound says that `r1 <= r2`; we store `r2: r1`. let r1 = self.universal_regions.to_region_vid(r1); let r2 = self.universal_regions.to_region_vid(r2);

Related discussion:
text: Found as a byproduct of work on backtrace: Compiles on stable 1.35.0.
triage: Looks like matthewjasper is on top of this. Marking P-high just so I don't have to think about it further right now. Removing nomination tag.
Code change:
match outlives_bound { OutlivesBound::RegionSubRegion(r1, r2) => { <ins> // `where Type:` is lowered to `where Type: 'empty` so that // we check `Type` is well formed, but there's no use for // this bound here. if let ty::ReEmpty = r1 { return; } </ins> // The bound says that `r1 <= r2`; we store `r2: r1`. let r1 = self.universal_regions.to_region_vid(r1); let r2 = self.universal_regions.to_region_vid(r2);

Related discussion:
text: Happens on stable 1.34.2, 1.35.0 and current nightly (2019-05-28). . Results in:
Reduced:
Compiles fine on 1.34.0; haven't tested 1.34.1.
both my repro and your reduced one do ICE on (and ) for me, can you verify that again?
Happens all the way back to 1.30.0 (with ) for me, as long as is passed to rustc.
Ah of course! is needed for NLL on older versions... :) I forgot that godbolt doesn't have that by default.
Code change:
} /// `parent_module` refers to the parent of the re-export, not the original item <del> fn merge_attrs( </del> <ins> pub(crate) fn merge_attrs( </ins> cx: &mut DocContext<'_>, parent_module: Option<DefId>, old_attrs: Attrs<'_>,

Related discussion:
text: From Given the following Rust code with in-line annotations of the expected behaviour: On: does not seem to be able to generate feature requirement labels on types in private modules () that are publicly reexported (). The labels do not show up on the module overview nor page, but do propagate into items like functions for the given type. This renders the type without any feature requirement, neither in the module overview: ! Nor on the page: ! Note that the label is propagated onto (does not have an explicit ), at least understood that! It is supposed to render the feature requirement for like , both in the module overview above as on the page: ! It seems tricky to combine feature requirements on the and reexport. In the case above they are the same, but what if: The type is only publicly available when and are specified. Specifying is fine but makes the contents of unreachable through the current module, specifying only should result in a "module not found" error. CC
This also affects re-exports of entire crates. Unfortunately there the fix is not clear at all, since the "parent" crate is obviously not guaranteed to have the same features as the crate being re-exported.
Within the same crate as well; it's not about the features that are enabled (though it is relevant which are available) but about the combined restrictions that are placed on the definition and reexport. Simplest I can think of is a union of all features (but gets complicated quick when inversions and vs is used) and later perhaps simplifying based on feature relations (if implies there is no need to display as requirement, if either definition or reexport requires ). That's necessary to cleanly solve crate reexports, since you effectively want to ensure that the top-level crate feature implies feature and hide it. If the whole resolver is made smart enough (perhaps this already exists, I'm not too familiar with Cargo) it could even throw warnings when there exist feature combinations that would lead to a compiler error (ie. explicitly reexporting a symbol that is not available for a certain set of features).
I wonder if this is just an ordering issue of the passes: The private modules have disappeared by the point where we pass all the data down so we don't see them.
Code change:
} /// `parent_module` refers to the parent of the re-export, not the original item <del> fn merge_attrs( </del> <ins> pub(crate) fn merge_attrs( </ins> cx: &mut DocContext<'_>, parent_module: Option<DefId>, old_attrs: Attrs<'_>,

Related discussion:
text: Thanks for the suggestion - I moved before and (I've never built rustc/rustdoc from source, pleasantly surprised that only took just under 7min on a ThreadRipper :partyingface:) but it doesn't change anything to the generated output unfortunately :(
I observe this on public items as well: Does not show the badge at re-exports.
So from the following code: is stripped and then inlined. The stripped version contains all the correct information but the inlined one doesn't. Checking what's the best course here: either cloning the stripped item or propagating when inlining.
Code change:
<ins> // Nested impl-traits can impose different member constraints on the same region variable. // check-pass trait Cap<'a> {} impl<T> Cap<'_> for T {} // Assuming the hidden type is `[&'_#15r u8; 1]`, we have two distinct member constraints: // - '_#15r member ['static, 'a, 'b] // from outer impl-trait // - '_#15r member ['static, 'a]     // from inner impl-trait // To satisfy both we can only choose 'a. fn pass_early_bound<'s, 'a, 'b>(a: &'s u8) -> impl IntoIterator<Item = impl Cap<'a>> + Cap<'b> where 's: 'a, 's: 'b, { [a] } // Same as the above but with late-bound regions. fn pass_late_bound<'s, 'a, 'b>( a: &'s u8, _: &'a &'s u8, _: &'b &'s u8, ) -> impl IntoIterator<Item = impl Cap<'a>> + Cap<'b> { [a] } fn main() {} </ins>

Related discussion:
text: The following code should pass regardless of the declaration order of lifetimes: This is related to but it's different in that we do have a lower bound region, , but we fail to recognize that because , which is responsible for calculating from , assumes that the outlive relation is a total order, which is not true. Here is the graph of : ! So we need an efficient algorithm that works for partial order relations, but the one that comes to mind is . The perf may not be really important here but I'm curious to see the alternatives. label C-bug T-compiler A-borrow-checker E-mentor E-help-wanted <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Here is the code of concern The code should calculate the from a set of universal regions (). The relations are encoded in and are guaranteed to be transitive and reflexive. The relation graph may have cycles and can be sparse. The goal here is to find a unique minimum choice that is known to be outlived by all other regions. If none can be found, the function returns . Regions that have cycles between them are considered equivalent so we can pick either one of them as a unique choice. e.g. , we can pick either one of as a minimum choice.