jiebi/CodeConvo huggingface dataset:
Change:
= note: the return type of a function must have a statically known size error[E0308]: mismatched types <del> --> $DIR/async-block-control-flow-static-semantics.rs:51:44 </del> <ins> --> $DIR/async-block-control-flow-static-semantics.rs:50:44 </ins> | LL | fn rethrow_targets_async_block_not_fn() -> Result<u8, MyErr> { |    ----------------------------------      ^^^^^^^^^^^^^^^^^ expected enum `std::result::Result`, found ()

Discussion:
With: you get: Note how it references "a closure" which seems confusing for a user who doesn't presume the implementation. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I'm assuming its ok to leave this as the same error code of E0267 - in essence it's the same error, just more specific text.
Yeah I think it's fine.
Change:
pub trait Vehicle { type Color; <ins> //~^ NOTE ambiguous `Color` from `Vehicle` //~| NOTE ambiguous `Color` from `Vehicle` //~| NOTE ambiguous `Color` from `Vehicle` </ins> fn go(&self) {  } } pub trait Box { type Color; <ins> //~^ NOTE ambiguous `Color` from `Box` //~| NOTE ambiguous `Color` from `Box` //~| NOTE ambiguous `Color` from `Box` // </ins> fn mail(&self) {  } }

Discussion:
Currently, E0221 can give an error like: This isn't terribly helpful. Ideally, we'd like to show where these associated types that cause ambiguity are coming from: cc
I'd be up to mentor this. The message is reported by some code in , which has the job of converting the HIR representation of a type into the compiler's internal representation. The challenge here is that the HIR types have spans (because they are basically the things that the user wrote) whereas the internal representations do not. Right now, the routine in question, , only has access to a list of the representations in internal form (. To give better spans, we have to trace those spans in (so e.g. we want ). What this routine does is, given a type like , it selects what traits the associated type might have been defined in, and tries to pick one. The list is the list of traits that implements. So e.g. it might include something like , which would suggest that could be expanded to . But if there was another bound, say , that also defines an associated type , that'd be an amiguity. If you look at the callers, there aren't that many (3, I think). Two of those are for trait objects, I think, where the bounds come from the supertraits of the trait object. Probably we could give those the spans of the trait type itself, though we may want to get the spans out of the trait definition where the supertraits come from (but that could be in another crate). That last part is a bit tricky because we'd have to extend the . Let's assume we're not doing that for now, and we're willing to give a span referring to a trait when in fact the item lies in a supertrait where . The other is the more general case of a type parameter. I think the major piece of work then is to augment this routine in the trait: so that it returns a , where we would thread through the spans whence each bound was derived. Anyway, this is non-trivial, but seems to me to be achievable if anyone wants to dig in. If so, ping me (either on IRC, , or here) and I'll try to give more hints.

:)
I'll try, I need some time to look around
gettypeparameterbounds in callerbounds contains vec of Predicate w/o spans. May be is it easy only for error case in oneboundforassociatedtype get spans from astmap (hir::map) by DefId extracted from TypeTraitItems like traitdefinesassociatedtype_named do?
I've updated it But what do you think about trait from extern crate?
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> // ignore-test the unsized enum no longer compiles </ins> enum A { B(char), C([Box<A>]),

Discussion:
Backtrace: This seems to occur when using a non-struct type that contains an unsized type. This is probably because  only handles and the base unsized types. This should be extended to handle enums and tuples as well.
This is still happening. Does this mean we should avoid using DSTs for complex custom types for now?
Visiting for triage This is still an issue:
ICE also happens with a tupled trait object:
I've seen this too with: Reproducer: Version: Backtrace:
No longer reproduces but the other tests do.
cc
Is this the same as or related to ?
leads to . As mentioned inline, using the correct type works (). I'm using the Ubuntu PPA "rust-nightly", version ~~vivid.
Does not compile for other reasons that the ICE anymore. I've adjusted to the following and could not reproduce it anymore.
Another example hitting this same ICE:
Bugs similar to this one have been reported numerous times (most of the references to this issue are duplicates). Although it would be nice for reporters to search for similar issues before filing a new one, it's hard to blame them, since the ICE message from rustc tells people to file an issue. This issue itself was opened over two years ago. Separate from fixing the underlying problem, we should at least investigate displaying a real error instead of an ICE.
Change:
} /// Returns an iterator over `size` elements of the slice at a <del> /// time. The chunks do not overlap. If `size` does not divide the </del> <ins> /// time. The chunks are slices and do not overlap. If `size` does not divide the </ins> /// length of the slice, then the last chunk will not have length /// `size`. ///

Discussion:
I know that it's implied by the , but it wasn't immediately obvious to me that the chunks returned by can (I'm avoiding use of the term "recursive" here) have or called on themselves (). Is there any interest in a PR that makes this explicit? It seems that especially when working with threads and work-stealing, this is something that users want to do.
Is it enough to stress that each chunk is itself a slice (or mutable slice)?
Hm. What would be the distinction between stressing it and showing it? In theory, it should be obvious that because the chunk is a slice, you can call on it. At the same time, it depends on the intended audience; For the beginner, it means that there's no need to go off to the playpen or ask a question (which may or may not be a good thing, depending on your point of view). Either option is an improvement, and I'm probably over-thinking the whole thing now.
In general, API docs usually are written for an intermediate/advanced user: we don't generally mention "oh and because this has a return type of foo you can call these other things on it." Where does this stop and end?
Fair point. But what about explicitly stating that the functions return slices, as opposed to "an iterator"?
It does return an iterator - an iterator over slices.
Undeniably true, but I don't think it's clear; The docs say "an iterator over / elements_ of the slice".
I'm not sure one would be able to use and correctly without understanding that they yield slices. Once you understand that you can use to divide a slice into more slices, surely it makes sense that one can divide those slices in yet more slices, In much the same way that one can add two numbers and use the result for further addition.
Yes we should clarify the docs to say it returns an iterator whose elements are slices.
Change:
<ins> error[E0720]: cannot resolve opaque type --> $DIR/infinite-cycle-involving-weak.rs:3:10 | LL | type T = impl Copy; |          ^^^^^^^^^ cannot resolve opaque type error: aborting due to previous error For more information about this error, try `rustc --explain E0720`. </ins>

Discussion:
This triggers a stack overflow of rustc (even without the TAIT feature gate, i.e. on stable too) (): <details<summaryBacktrace</summary<p</p</details
(side-note: doesn't overflow in the new trait solver )
I'm gonna look into this
Change:
// NOTE: remove after next snapshot #[cfg(stage0)] <ins> pub use self::fail_ as fail; // NOTE: remove after next snapshot #[cfg(stage0)] </ins> #[cold] #[inline(never)] // this is the slow path, always #[lang="fail_"] fn fail_(expr_file_line: &(&'static str, &'static str, uint)) -> ! {

Discussion:
These appear all the time and result in large code bloat. At least the file and line should be combined into a static.
Also, and result in inefficient codegen and code bloat because they call into the string formatter when they don't need to.
This seems to be done for . The macro in still uses the string formatter for all invocations, but I don't even know how to use those.
Change:
this.write_bytes_ptr(ptr, iter::repeat(val_byte).take(byte_count.bytes_usize()))?; } <ins> "ptr_mask" => { let [ptr, mask] = check_arg_count(args)?; let ptr = this.read_pointer(ptr)?; let mask = this.read_scalar(mask)?.to_machine_usize(this)?; let masked_addr = Size::from_bytes(ptr.addr().bytes() & mask); this.write_pointer(Pointer::new(ptr.provenance, masked_addr), dest)?; } </ins> // Floating-point operations "fabsf32" => { let [f] = check_arg_count(args)?;

Discussion:
Specifically, this manifested with indexing into a dvec. Not all of the code that was manipulating s was handling the case. Already fixed it, about to check in a fix. Thanks to for the test case.

It's currently ignored on Windows.
The code in question looks like: When I commented-out the ignore and a then this test passed on my Windows machine (Mingw32 + 64 bit Windows 7). So perhaps this particular issue is no more?
Fixed in

A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

as per a FIXME.
Ok, so, the strings "globalenv" and "getglobalenvchan" don't appear in the source anymore, so I'm going to close this bug...
Change:
fn tys(&mut self, a: Ty<'tcx>, b: Ty<'tcx>) -> RelateResult<'tcx, Ty<'tcx>> { self.infcx.probe(|_| { <del> if a.is_ty_infer() || b.is_ty_infer() { </del> <ins> if a.is_ty_var() || b.is_ty_var() { </ins> Ok(a) } else { self.infcx.super_combine_tys(self, a, b).or_else(|e| {

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:
} }; <del> let is_last = i == path.len() - 1; </del> <ins> let is_last = i + 1 == path.len(); </ins> let ns = if is_last { opt_ns.unwrap_or(TypeNS) } else { TypeNS }; let name = ident.name;

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details
works with any tool attr also compiles but it probably... shouldn't.
label +S-bug-has-mcve
Triaged with . Steps performed: Reproduced: Formatted: No change, already formatted Reduced: Bisected: Regression in nightly-2022-04-17 couldn't nail down the particular commit: <details<summaryDetails</summary<prustc version: Icemelter version: v0.2.0 Icemelter command line: Do you have feedback about this report? Please ! </p</details
another one `
Change:
macro_rules! on_error { ($value:expr, $error_message:expr) => { <del> $value.or_else(|e| { </del> <ins> $value.or_else(|e| { // FIXME(85000): no coverage in closure macros </ins> let message = format!($error_message, e); if message.len() > 0 { println!("{}", message);

Discussion:
I expect something that looks like the result, for a similar (non-macro) closure: But instead we get results like the following: This issue is demonstrated in the coverage results from the test: I have a new PR in progress to show more examples, and those examples expose the fact that the coverage for is actually being to the macro's source itself. Note that there were 5 macro calls with missing coverage in the corresponding test case, and the coverage report shows 5 . So all are taken into account. Nevertheless, this is a function-like macro, and it should behave like a function call, and show the coverage at the calling site.
I suspect the problem is related to how the expansion is handled for the macro body. When defined without braces, it is (likely) "de-sugared" (adding braces perhaps?) in a way that confuses the macro expansion handling in .
+A-code-coverage fyi:
I looked into this (reviewing debug logs) and the issue it not exactly a macro problem, I think. The closure tests I used all call , and that macro is defined as follows: Note the expansion starts with . That creates a closure that looks like it starts: Since the opening brace comes from the macro, the closure MIR body source starts within the macro. Generating the coverage relative to the source that contains the first character of the function body is generally reasonable, and even in this case it might be hard to argue that it's wrong. But it's probably not right either. The issue is, where should coverage be generated? If the macro is more complex, instrumenting the macro is good. If the caller (which could be another macro, by the way) is more complex, instrumenting the caller source is often better. For example, intuitively we want the coverage results of the two macros below to look similar. Putting the coverage results in the source for the macro loses a lot of coverage span detail! I'm not exactly sure what to do. I'm thinking of treating closures (at least closures that start with a macro) as a special case (at least, when coverage is enabled), and find some way of handling the body span as if it included its own block braces.
Change:
<ins> // Copyright 2017 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. macro_rules! get_opt { ($tgt:expr, $field:ident) => { if $tgt.has_$field() {} } } fn main() { get_opt!(bar, foo); //~^ ERROR expected `{`, found `foo` } </ins>

Discussion:
My code is about 500 lines long. I'm running up against an assignment deadline, so I don't have time right now to make a minimal demonstration. But if needed I can do so after Thursday, if someone hasn't gotten to it already. Sorry to dump and run. I normally try to be better about bug reports. :/ I expect this to be related to my copy paste error with repeated if clause: EDIT: Removed code, as there is a minimal example below.
Minimal example: Gives output:
I like to check back in on my issues from time to time to ensure that they haven't become invalid. I found that this issue still exists in the 2017/12/11 nightly ().

The following code ICEs on x8664 linux Suspect that it's this line (expecting that a struct with size 8 has 1 field) ICE message: cc
This isn't fixed, example should have had a or a attribute to make sure that the function is exported.
. CC
These "components" are not exactly struct fields, but rather hardware registers. The alignment padding probably triggers an edge case, I'll have to look deeper.

I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

$ RUST_BACKTRACE=1 rustc $ cat $ rustc --version --verbose
Looks like this was fixed. Output with current nightly as per playground:
Yeah, this was fixed. Marking as E-needstest.
Change:
// each trait in the system to its implementations. <del> use metadata::csearch::{each_impl, get_impl_trait}; </del> <ins> use metadata::csearch::{each_impl, get_impl_trait, each_implementation_for_trait}; </ins> use metadata::csearch; use middle::ty::get; use middle::ty::{ImplContainer, lookup_item_type, subst};

Discussion:
Some days ago, I wrote some code involving char as HashMap key. At that time, char didn't implement the IterBytes trait, so I implemented it locally myself. After updating rust, my code failed to compile with a somewhat less than obvious error. Example: Produces the following errors: Note that there is no way to know that the problem is the duplicate implementation of IterBytes.
Reproduced as of
Bumping to 0.7, though.
Not critical for 0.7. Nominating for milestone 5, production-ready.
accepted for production-ready milestone
Still reproduces: It has a bunch of other non-bug errors too, but it still exhibits this bug.
Accepted for P-high.
Change:
LL |     extern "rust-call" fn call_mut(&mut self, args: Args) -> Self::Output; |                           ^^^^^^^^ <ins> error[E0308]: mismatched types --> $DIR/overloaded-calls-bad.rs:31:17 | LL |     let ans = s("burma", "shave"); |                 ^^^^^^^ expected `isize`, found `&str` </ins> error[E0057]: this function takes 1 argument but 2 arguments were supplied --> $DIR/overloaded-calls-bad.rs:31:15 |

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code from <!-- 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<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched toolchains through Regression in probably cc
I can look into this claim
Change:
let size = u64::try_from(self.force_bits(size, pointer_size)?).unwrap(); let align = vtable.read_ptr_sized(pointer_size * 2)?.check_init()?; let align = u64::try_from(self.force_bits(align, pointer_size)?).unwrap(); <del> let align = Align::from_bytes(align) .map_err(|e| err_ub_format!("invalid vtable: alignment {}", e))?; </del> <ins> let align = Align::from_bytes(align).map_err(|e| err_ub!(InvalidVtableAlignment(e)))?; </ins> if size >= self.tcx.data_layout.obj_size_bound() { <del> throw_ub_format!( "invalid vtable:  size is bigger than largest supported object" ); </del> <ins> throw_ub!(InvalidVtableSize); </ins> } Ok((Size::from_bytes(size), align)) }

Discussion:
The following code ICEs: To fix this, this code here needs to properly catch the "invalid size/align" error and turn it into a validation failure: But for this we first need to make these errors catchable by introducing separate variants into this enum: You can use the existing variant as a model; it does the same job for invalid drop function pointers in the vtable. Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'll take care of this claim
Change:
# Just copy the docs to a folder under dist with the appropriate name # for uploading to S3 <del> dist-docs: docs compiler-docs </del> <ins> dist-docs: docs </ins> $(Q) rm -Rf dist/doc $(Q) mkdir -p dist/doc/ $(Q) cp -r doc dist/doc/$(CFG_PACKAGE_VERS)

Discussion:
I got the message above,how to fix it?
Urgh. This should never have gotten through the CI bots. Some rules must be being built by the install target that aren't under the normal build.
I will try to look into this today while I'm investigating other nightly breakage.
I assume this is being introduced by the doc comment I wrote here: So the two bugs here are: the above doc comment in dropck. (Presumably just replace the indents with nested bullets.) rules do we need to change to synchronize with the CI bots (to catch this kind of case in the future) -- presumably its happening because attempts to build documentation for rust itself ... which sounds a lot like good old: ; see also
I posted a PR to stop building compiler docs. It does not fix the bug in the docs though.
Fixed.
Er, oh yeah, the underlying problem is not fixed, that the docs have broken examples.
Sigh, actually, I'll call this fixed since the title of the bug is about install failure and that works now. Broken examples in the rustc crate are nbd to me atm.

Just downloaded a fresh install from git and ran on a virgin arch linux box running on AWS and getting this error again cfg: using CC=gcc (CFGCC) cfg: disabling valgrind run-pass tests cfg: including prepare rules cfg: including dist rules cfg: including install rules cleaning destination tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/bin prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/lib prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/lib/rustlib/etc prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/share/man/man1 rustc: x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-gnu/lib/librustc recipe for target 'x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-' failed make[1]:  [x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-] Killed make[1]: Leaving directory '/root/Downloads/rust' recipe for target 'install' failed make:  [install] Error 2 any ideas
Change:
[(); return while let Some(n) = Some(0) {}]; //~^ ERROR return statement outside of function body <del> //~^^ WARN irrefutable while-let pattern </del> }

Discussion:
Super-High-Level Instructions: Replace with And then follow up by making sure that the compiler doesn't ICE anywhere (e.g. during MIR building). It should probably "just work" nowadays. A crater run isn't necessary, as this will only ICE if an error wasn't handled properly. Successfully compiling code is unaffected.
I took a look at this and all tests seem fine in just dropping in the code you have above as you said. However I just wanted to check is no longer needed? Pretty unfamiliar with this code so I wanted to confirm before submitting as it's not explicitly mentioned in the other thread that it should be removed.
Yes that should be removed, too. It will automatically be run when fetching the MIR of the current constant.
ok, cool! I have filed a PR for this in Let me know if anything needs to be updated!