jiebi/CodeConvo huggingface dataset:
Change:
let name = tcx.item_name(def_id); Ok(match name { sym::type_name => { <ins> if tp_ty.needs_subst() { throw_inval!(TooGeneric); } </ins> let alloc = type_name::alloc_type_name(tcx, tp_ty); ConstValue::Slice { data: alloc, start: 0, end: alloc.len() } }

Discussion:
I tried this code: I expected the code to run without errors Instead, the assertion failed. Compiler version: 1.46.0-nightly (2020-07-01 )
Seems something wrong with the intrinsics evaluation.
I think the issue is that is in place when we try to hash . I am not very familiar with the code here but I think this might be evaluated before monomorphization which causes this issue.
Another example showing this is pre-monomorphization: rustc happily compiles this, but I would expect something like .
I was trying to do something somewhat similar with const type_id when I filed . There seem to be some inconsistencies in what combinations of generics and patterns are allowed, which might be contributing to the problem.
I have no idea what is going on, but it certainly looks odd... Cc
needs to monomorphize the type before evaluating it I'd guess (an assert checking for would make sense there, too I'd think).
I wonder if instead of we should more explicitly check for "type or const params", but I think it's mostly about aesthetics thanks to miri working with lifetime-erased types. You said "assert" but I think the type is already monomorphized and what we need to do is return if it's not monomorphic. Same for , actually - any reflection that doesn't rely on will have this problem.
oh right, this may be an evaluation happening too early, so is totally reasonable to emit here. I'm always wary of emitting .
Doesn't that mean that the code samples above will be forbidden?
No, just evaluating the consts early will fail. Once everything is monomorphized it will work.
I have an attempt here: It prevents OP's snippet from compiling:
hmm... maybe const prop is interfering here. Can you try running the same build with and ?
Ah, so this is a different issue. It's the same issue (even if a different symptom) of running
Patterns need to be monomorphic, you can never have a pattern that depends on generic parameters. We may lift this restriction in the future, but it's a separate issue and needs a language RFC afaik
in stable and gives in nightly. We will need a better diagnostics for the TooGeneric error.
works on stable, so the old diagnostic was wrong. It's specifically associated constants that depend on generic parameters.

so is the approach of returning all we need to do here? If so would you be happy to open your branch as a PR so we could look at adding some ui tests and whatnot?
The thing I worried is that the error isn't very helpful. Maybe fixing that diagnostics should be a separate PR?
Yea, cleaning up the diagnostics can be done after fixing the bug
Change:
Function, /// `m!` Macro, <ins> /// `foo` without any disambiguator RemoveDisambiguator, </ins> } impl Suggestion {

Discussion:
Unfortunately I don't have an easy-to-repro case. This happened while working on Rocket's docs. I renamed a method which made a previously valid link invalid and I got this ICE. Fixing the doc link fixes the error. Backtrace from rustc 1.54.0-nightly ( 2021-05-21) follows: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If someone can compile a build of rustdoc that comments out this line: you should get a much better error message that says exactly what went wrong (it will start with "incompatible link kind"), and that should give an idea of where the bug is.
can you link to the exact commit of Rocket that caused the ICE?
This is the current tip, You may be able to replicate this by referencing in the struct's docs in and then changing the method's name to something else. If this fails, I will try to create a reproducible case.
MCVE: label -E-needs-mcve
claim
Error: Parsing relabel command in failed: ...'needs-MCVE' '): rs'... Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'needs-mcve' '): rs'... Please let know if you're having trouble with this bot.
Change:
You should see the version number, commit hash, commit date and build date: ```bash <del> rustc 1.0.0-beta (9854143cb 2015-04-02) (built 2015-04-02) </del> <ins> rustc 1.0.0 (a59de37e9 2015-05-13) (built 2015-05-14) </ins> ``` If you did, Rust has been installed successfully! Congrats!

Discussion:
The rust book currently links to, an old beta version of rust, causing some problems using the tutorial. Example: Dining philosophers will not compile.
What's your rust version?
According to the installer: 1.0.0-beta. On windows x64.
It compiles on 1.0.0-beta.2 and up. You should update your compiler.
I believe is right here, so closing, but thanks for the report!
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-118809.rs:6:10 | LL | #[derive(Deserialize)] |          ^^^^^^^^^^^ |          | |          expected `u64`, found `u32` |          arguments to this enum variant are incorrect | help: the type constructed contains `u32` due to the type of the argument passed --> $DIR/issue-118809.rs:6:10 | LL | #[derive(Deserialize)] |          ^^^^^^^^^^^ this argument influences the type of `Some` note: tuple variant defined here --> $SRC_DIR/core/src/option.rs:LL:COL = note: this error originates in the derive macro `Deserialize` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Short code to reproduce the issue.
Change:
<ins> pub trait Trait { /// [`u8::clone`] fn method(); } </ins>

Discussion:
Run on this and get an ICE. Note that documenting itself does not panic, and that the is necessary. <!-- 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. --: Also reproduces on Linux (GitHub Actions) with the same nightly version. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +T-rustdoc -T-compiler
It looks like this started after commit . () I was able to create a MCVE: <details<summaryBacktrace:</summary</details
cc
Further minimized: The issue disappears if the private is removed. Looks like some logic in rustdoc is over-eager to pull in stuff through private imports, links in 's methods are not visible in the generated documentation and shouldn't be resolved at all.
--are responsible for including the trait into the rustdoc's crate representation, still unclear why.
Fixed in
Change:
<del> Subproject commit fb33fad08e8f08c032b443bab0df299ce22fe61b </del> <ins> Subproject commit d2f51228152a139a2a8aaba59b8a4e68f498ff26 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
I'm going to guess that is to blame; cc
The fix is mostly to replace by . But really RLS shouldn't be using such implementation details...
The logs look like the failure is in clippy, not RLS? I am confused. (Great logs as usual, thanks Travis.)
breaking breaks RLS, AFAIK.
will fix it, only needs ci to pass.
Change:
continue 'each_last; } IsInFollow::Yes => {} <del> IsInFollow::No(ref possible) => { </del> <ins> IsInFollow::No(possible) => { </ins> let may_be = if last.tokens.len() == 1 && suffix_first.tokens.len() == 1 {

Discussion:
E.g. in a vec is created, only to be thrown away if the macro actually works out. I think we can just turn most places into an early return in the happy path and then only allocate in the error path. Do not work on this issue before is merged. Also, hasn't had its docs updated to reflect the source changes.
Are there any reasons to not use constant/static slices and convert them to vecs on demand? Or maybe even convert to something like so there's no need to allocate vecs (In all cases) anymore?
That's a great idea! I haven't checked whether it'll work everywhere, but I think it should.
Change:
#![feature(allocator_internals)] #![feature(allow_internal_unsafe)] #![feature(allow_internal_unstable)] <del> #![feature(async_stream)] </del> #![feature(arbitrary_self_types)] #![feature(array_error_internals)] #![feature(asm)] #![feature(assert_matches)] #![feature(associated_type_bounds)] <ins> #![feature(async_stream)] </ins> #![feature(atomic_mut_ptr)] <ins> #![feature(auto_traits)] </ins> #![feature(bench_black_box)] #![feature(box_syntax)] #![feature(c_variadic)]

Discussion:
See for an example of the problem. Here we panic without any landing pads available upstack, because we are already the top-most(-ish) frame in the first place. This is UB.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Playground link with full code:
FWIW, Miri does detect this. :)
Change:
<del> // check-pass </del> <ins> trait Foo: 'static { } </ins> <del> use std::any::Any; </del> <ins> trait Bar<T>: Foo { } </ins> <del> trait A<T>: Any { fn m(&self) {} } impl<S, T: 'static> A<S> for T {} </del> <ins> fn test1<T: ?Sized + Bar<S>, S>() { } </ins> <del> fn call_obj<'a>() { let obj: &dyn A<&'a ()> = &(); obj.m(); </del> <ins> fn test2<'a>() { // Here: the type `dyn Bar<&'a u32>` references `'a`, // and so it does not outlive `'static`. test1::<dyn Bar<&'a u32>, _>(); //~^ ERROR the type `(dyn Bar<&'a u32> + 'static)` does not fulfill the required lifetime </ins> } <del> fn main() {} </del> <ins> fn main() { } </ins>

Discussion:
Found in () Errors: modify labels: T-compiler, C-bug, A-traits, A-dst, A-associated-items, A-typesystem and please add “I-unsound ”
cc - this looks like it might be related to some of your work.
Assigning as discussed as part of the and removing .
Without the keyword, the function type-checks since Rust 1.0.0. And a function like e.g. leads to reading a bunch of memory and segfaulting on every Rust version, as far as I can tell (at least in debug builds).
To me, this is the same root cause as : we unconditionally say that any type is well-formed and implements without checking the actual where clauses declared on the trait, so you can deduce contradictory things with the help of implied bounds (to be fair, already introduced some checks). Except that I was wrong in my saying that an easy fix for our current limited form of implied bounds would be to just check transitive lifetime requirements. Obviously, example shows that implied bounds for super traits play a role as well.
Change:
// So peel off one-level, turning the &T into T. match base_ty.builtin_deref(false, ty::NoPreference) { Some(t) => t.ty, <del> None => { return Err(()); } </del> <ins> None => { debug!("By-ref binding of non-derefable type {:?}", base_ty); return Err(()); } </ins> } } _ => base_ty,

Discussion:
hi, my code used to compile last week. I updated the compiler today and now it crashes note that you can get my code here ()
note: going back to nightly-2017-04-01; everything work again. 'nightly-2017-04-17 is not ok. so troubles started somewhere in between.
cc
not too sure what to do with this message. can I help you with something ? I can do a small dichotomy to figure out the last working nightly if this can help.
Minified:
there is a pending fix (), no action needed on your part
triage: P-high
Change:
// Panic with `ExplicitBug` to avoid "unexpected panic" messages. if !no_bugs { <del> panic::panic_any(ExplicitBug); </del> <ins> panic::panic_any(panic_with); </ins> } }

Discussion:
With beta but nightly does not show backtraces: edits this is with prioritize
can you share your example code, as it doesn't seem that all ICEs are missing backtraces: on the same nightly and beta, and which has a backtrace on both. (if you have the time to do so and a master checkout, it'd be interesting to know whether ThinLTO could be involved like in ; bisection would also be worthwhile)
Hmm interesting, maybe its' something that only happens with :thinking: does not show a backtrace for me ! I also can't force it with or anything :(
This backtrace was removed on purpose in because it's useless. It just points at the place in the error machinery where delayed bugs get flushed, which is either just noise or misleading at worse.
This also affects explicit calls too -- these should be restored in . Regarding s backtraces being useless, see .
Change:
--enable-profiler  --disable-docs <del> ENV SCRIPT python3 ../x.py dist --host $HOSTS --target $HOSTS </del> <ins> ENV SCRIPT python3 ../x.py dist --host $HOSTS --target $TARGETS </ins>

Discussion:
When downloading the (and variant) target, the that ships with the compiler is broken: Upon further inspection, the symbols are indeed built for x86-64 and not LoongArch: It's not clear what causes this, but contains no corresponding definitions for . This issue appears related, in that it would catch whatever causes this:
cc
Change:
#[stable(feature = "rust1", since = "1.0.0")] #[cfg_attr(not(test), rustc_diagnostic_item = "write_macro")] macro_rules! write { <del> ($dst:expr, $($arg:tt)*) => { $dst.write_fmt($crate::format_args!($($arg)*)) }; </del> <ins> ($dst:expr, $($arg:tt)*) => {{ let result = $dst.write_fmt($crate::format_args!($($arg)*)); result }}; </ins> } /// Write formatted data into a buffer, with a newline appended.

Discussion:
https://crater- https://crater- https://crater- https://crater- https://crater- https://crater- is likely cause (cc
I'll fix this.
Fixed on beta with and on master. will be a more complete change and will likely land in 1.63 (or later).
Change:
/// The original type being checked, before we recursed /// to any other types it contains. base_ty: Ty<'tcx>, <del> /// Number of times we recursed while checking the type recursion_depth: usize, </del> } enum FfiResult<'tcx> {

Discussion:
The windows-rs crate is getting a whole bunch of spurious FFI-safe warnings: See: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc which introduced the recursion limit.
Repro:
Anyways I'll put up a revert PR claim
Change:
<ins> trait Mumbo { pure fn jumbo(&self, x: @uint) -> uint; fn jambo(&self, x: @const uint) -> uint; fn jbmbo(&self) -> @uint; } impl uint: Mumbo { // Cannot have a larger effect than the trait: fn jumbo(&self, x: @uint) { *self + *x; } //~^ ERROR expected pure fn but found impure fn // Cannot accept a narrower range of parameters: fn jambo(&self, x: @uint) { *self + *x; } //~^ ERROR values differ in mutability // Cannot return a wider range of values: fn jbmbo(&self) -> @const uint { @const 0 } //~^ ERROR values differ in mutability } fn main() {} </ins>

Discussion:
Right now, a fn implementing an iface method must match the purity of the iface method exactly. This is too strict. We should allow a pure fn to implement an impure fn, and both pure/impure to implement an unsafe fn. UPDATE: Updated title to reflect the real problem here. There is a FIXME in the code in the relevant area. If one declares a trait like: then in the impl, the method should take one type parameter with an bound. We don't really check this correctly though. As far as I can tell, we just check that has one type parameter with one bound, but not precisely what kind of bound it is.
Similarly, in , we require that the bounds on the method parameters be precisely equivalent, which is stronger than necessary. It is sufficient (I believe) that the bounds on the trait be stronger than the bounds on the implementation.
Is this still an issue? It seems to be fixed now.
Still an issue with respect to type parameter bounds.
I don't believe this is backwards incompatible, renominating.
accepted for feature-complete milestone
The following appears to work, but I assume that this is what was talking about:
triage bump. nothing to add.
Accepted for P-backcompat-lang
Added UPDATE to main bug description above.
I had a look at this issue and tried to create a test case. does test case covers the issue you mentioned? This test case fails because it seems like the parameter types are checked in
what error does it fail with? In the you need to use a different type bound for in order to test this issue. To be more precise, the bounds of the implementation should be implied by the bounds of the trait. For example, this should fail:
thanks for the hint, I guess your updated example should indeed test this issue. I'll start working on a patch.
Change:
<ins> // run-rustfix #![allow(dead_code)] pub fn foo(x: &str) -> Result<(), Box<dyn std::error::Error>> { Err(format!("error: {x}").into()) //~^ ERROR mismatched types } macro_rules! outer { ($x: expr) => { inner!($x) } } macro_rules! inner { ($x: expr) => { format!("error: {}", $x).into() //~^ ERROR mismatched types } } fn bar(x: &str) -> Result<(), Box<dyn std::error::Error>> { Err(outer!(x)) } macro_rules! entire_fn_outer { () => { entire_fn!(); } } macro_rules! entire_fn { () => { pub fn baz(x: &str) -> Result<(), Box<dyn std::error::Error>> { Err(format!("error: {x}").into()) //~^ ERROR mismatched types } } } entire_fn_outer!(); macro_rules! nontrivial { ($x: expr) => { Err(format!("error: {}", $x).into()) //~^ ERROR mismatched types } } pub fn qux(x: &str) -> Result<(), Box<dyn std::error::Error>> { nontrivial!(x) } fn main() {} </ins>

Discussion:
The suggestion converts the code to: which is invalid. It should suggest: The suggestion works correctly for non-macro string values. This suggestion was introduced in . No response
It cannot be reproduced on .
I'm able to reproduce it locally. It seems to be suggesting a change in : (note the path) I assume that this is due to macro expansion. It might not be working on the playground because the playground doesn't have the component installed but that's a total guess.
The presence of only affects the human-readable rendering. The important part to me is the JSON output which has even without rust-src. Ideally it would be something closer to what it looks like with :
It seems to affect all macro expansions ():
Is the solution to just disable this suggestion for macro-expanded code? As an aside, perhaps the playground should get , especially because of its prevalence in sharing code which might need the additional context.
I think it's possible to achieve the desired output found in the description, although I'm not sure how exactly. Typically, you would use on the span to peel away the layers of macro invocations, though for that you would need to provide a parent to mark the end of the chain. doesn't need such a stopper but here its use would be incorrect if the macro call itself (e.g. ) was inside of a macro expansion. Since we don't have a parent (afaiaa), earlier I briefly tried to create a parent for via I think but that didn't work. Maybe could work, not sure. This approach is a catch-22 I believe.
Yeah, would that be the desired solution though? Can this be generalized to all the other type mismatch suggestions?
That's a good question. It was mostly an experiment to see if this specific issue can be solved with .
Change:
<ins> // run-pass // Eventually this will be rejected (when the future-compat lints are turned into hard errors), and // then this test can be removed. But meanwhile we should ensure that this works and does not ICE. struct NoDerive(i32); #[derive(PartialEq)] struct WrapEmbedded(*const NoDerive); const WRAP_UNSAFE_EMBEDDED: &&WrapEmbedded = &&WrapEmbedded(std::ptr::null()); fn main() { let b = match WRAP_UNSAFE_EMBEDDED { WRAP_UNSAFE_EMBEDDED => true, //~^ WARN: must be annotated with `#[derive(PartialEq, Eq)]` //~| previously accepted _ => false, }; assert!(b); } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: shouldn't have created a ValTree for const NoDerive', 'error: internal compiler error: shouldn't have created a ValTree for const NoDerive' 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<!-- query stack: [valtreetoconstval] converting type-level constant value to mir constant value [mirdropselaboratedandconstchecked] elaborating drops for [analysis] running analysis passes on this crate --
Regression in cc
Should be fixed by
label -needs-triage
Change:
<ins> error: expected one of `.`, `:`, `;`, `?`, `for`, `loop`, `while`, `{`, `}`, or an operator, found `,` --> $DIR/issue-93282.rs:2:9 | LL |     f<'a,> |         ^ expected one of 10 possible tokens | help: use `::<...>` instead of `<...>` to specify lifetime, type, or const arguments | LL |     f::<'a,> |      ++ error: aborting due to previous error </ins>

Discussion:
Reproducible at . <details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems to be introduced in :
Thanks for the report! A compiler panic is probably best reported in rust-lang/rust, even though it's being surfaced by a dev tool. I'll check with infra to see if it makes sense to move the issue We actually haven't made any changes to rustfmt in that window and the were highly minimal and certainly don't strike me as anything that would be the root cause. As such I suspect this is due to changes made elsewhere within the compiler mods, and would at least like for those folks to be aware (even if we need to make changes on the rustfmt side to address/work around) Would you be up for trying to boil it down to a more simple repro case?
Sure! Here is a MRE:
I have bisected to . cc I noticed that rustfmt is exiting with 0 even though it panicked. Is that normal?
I'll look into it today or tomorrow! claim
Outside a macro, no, (as was the case in the original full repro), but yes within the context of a macro as in the minimal rerpo. We have our calls to rustcparse internals wrapped in so the panic isn't really surfacing here, but rustfmt is still displaying the underlying error text prior to emitting formatting. This is done partly due to the fact that there are scenarios where those internals panic that we want to wrap to an error type, and partly due to there being some scenarios we want to ignore for the purposes of formatting due to how we attempt to deal with macros in the pre-expansion world where rustfmt lives. The latter being a result of limited macro support and leaving macros it can't handle alone, while carrying on formatting the rest of the file/crate/workspace
It looks like I'm still getting this error with (Coming from that was closed due to this one) Playground seems to produce it also:
I'll take another look then.
Yeah, this continues to ICE even in rustc. Fixed in another PR.
Change:
adt_consider_insignificant_dtor(tcx), true, ) <ins> .filter(filter_array_elements(tcx, query.param_env)) </ins> .next() .is_some(); debug!("has_significant_drop_raw({:?}) = {:?}", query, res);

Discussion:
I tried this code: I expected it to compile successfully. Instead, this happened: It most recently worked on 1.72 Regressed in cc Originally reported in cc modify labels: +regression-from-stable-to-beta -regression-untriaged
WG-prioritization assigning priority (). label -I-prioritize +P-high