jiebi/CodeConvo huggingface dataset:
Change:
<ins> #![allow(unused)] fn test_if() -> i32 { let x = if true { eprintln!("hello"); 3; } else { 4; }; x //~ ERROR mismatched types } fn test_if_without_binding() -> i32 { if true { //~ ERROR mismatched types eprintln!("hello"); 3; } else { //~ ERROR mismatched types 4; } } fn test_match() -> i32 { let v = 1; let res = match v { 1 => { 1; } _ => { 2; } }; res //~ ERROR mismatched types } fn test_match_match_without_binding() -> i32 { let v = 1; match v { 1 => { 1; } //~ ERROR mismatched types _ => { 2; } //~ ERROR mismatched types } } fn test_match_arm_different_types() -> i32 { let v = 1; let res = match v { 1 => { if 1 < 2 { 1 } else { 2 } } _ => { 2; } //~ ERROR `match` arms have incompatible types }; res } fn test_if_match_mixed() -> i32 { let x = if true { 3; } else { match 1 { 1 => { 1 } _ => { 2 } }; }; x //~ ERROR mismatched types } fn test_if_match_mixed_failed() -> i32 { let x = if true { 3; } else { // because this is a tailed expr, so we won't check deeper match 1 { 1 => { 33; } _ => { 44; } } }; x //~ ERROR mismatched types } fn main() {} </ins>

Discussion:
The code below has superfluous semicolons in the branches of the if expression: The error message that results is: This can be confusing to beginners, who may not understand unit type. However, since the expressions and can be shown to have no side effects, the code (as is) can't be what the user intended. Could the compiler produce a more targeted error message that mentions the superfluous semicolon? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label T-compiler A-diagnostics D-newcomer-roadblock D-terse
claim
Thinking more about this, I don't think we should extend the "remove semicolon to make tail expression" suggestion to cover this case, since we don't know the expected type of at the point at which the suggestion would be made. For example, we don't make the suggestion to change to here: But that's just a guess based on my limited knowledge of type mismatch suggestions. Maybe someone else could weigh in?
Change:
<ins> #![feature(inline_const, const_type_id)] use std::alloc::Layout; use std::any::TypeId; use std::mem::transmute; use std::ptr::drop_in_place; pub struct VTable { layout: Layout, type_id: TypeId, drop_in_place: unsafe fn(*mut ()), } impl VTable { pub fn new<T>() -> &'static Self { const { //~^ ERROR the parameter type `T` may not live long enough //~| ERROR the parameter type `T` may not live long enough &VTable { layout: Layout::new::<T>(), type_id: TypeId::of::<T>(), drop_in_place: unsafe { transmute::<unsafe fn(*mut T), unsafe fn(*mut ())>(drop_in_place::<T>) }, } } } } fn main() {} </ins>

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. --: (latest nightly as of today) </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label: +F-inline_const
Note the missing bound. requires , and should throw a lifetime bounds error, but I think the inline const block is tripping something up. It works fine if you require or without the inline const block.
claim
Change:
} } } <ins> let sp = sp.with_ctxt(sp.ctxt().apply_mark(cx.current_expansion.mark)); </ins> base::MacEager::expr(cx.expr_str(sp, Symbol::intern(&accumulator))) }

Discussion:
If any linting or suggestion is done in this case, it should suggest cc this has been in rustc forever, but clippy is only lately going crazy on it. Could this have come from your PR, too?
Hmm, shouldn't have been affected, but I'll investigate.
this is messing up clippy pretty bad. Any idea where to start looking?
So I tried to figure out what's going on, but I got lost in the code. As far as I can see it should be setting the expansion info. But it appears the passed to doesn't contain the expansion info. So maybe we need to generate a new span here with the from ?
The span passed to is the call site span, so it shouldn't contain the expansion info. The issue here is that is using the call site span directly in the expansion ( is call site span). To fix this, the macro should add expansion info to the call site span like does . Adding that line in should fix this issue. Are there other built-in macros that also have this problem in practice or is it just ?
I'd assume others have it too, but I'll check. So the passed call site span should only be used directly for error reporting, but never for creating ast items?
Right, unless you want an AST item with the raw (unexpanded) call site span -- I don't think we ever want that.
Change:
#![feature(iter_partition_in_place)] #![feature(iter_is_partitioned)] #![feature(iter_order_by)] <del> #![feature(cmp_min_max_by)] </del> #![feature(iter_map_while)] #![feature(const_mut_refs)] #![feature(const_pin)]

Discussion:
Tracking issue for the feature, which adds the / / / functions to . PR:
Is there anything blocking this from stabilizing?
Doesn't look like it! If somebody would like to open a stabilization PR then we can start a FCP
Stabilization PR up at
Change:
// same `JoinInner` as this closure meaning the mutation will be // safe (not modify it and affect a value far away). unsafe { *their_packet.result.get() = Some(try_result) }; <ins> // Here `their_packet` gets dropped, and if this is the last `Arc` for that packet that // will call `decrement_num_running_threads` and therefore signal that this thread is // done. drop(their_packet); // Here, the lifetime `'a` and even `'scope` can end. `main` keeps running for a bit // after that before returning itself. </ins> }; if let Some(scope_data) = &my_packet.scope {

Discussion:
Scopes threads as currently implemented are potentially unsound due to passing a reference to a function where the memory the reference points to is potentially deallocated while the function still runs. Specifically, takes as implicit argument its closure environment, which contains . That environment might just be a reference to some memory that is allocated in the caller stack frame. However the function can keep running after got dropped (implicitly at the end of ). Then the scope might end and the memory might be deallocated all while is still running. If the environment is just a reference, it ends up being a newtype and we will (AFAIK) add the attribute, meaning deallocation while the function runs is actually LLVM UB. Miri found the error in , where the invalidates the reference that was passed to the forked-off threads. ( doesn't actually get deallocated, it just has a unique reference created to it, but deallocation is also a possibility). To fix this properly, I think we need a language extension: we want a way to store references in a type without having alias guarantees for that reference. In terms of Stacked Borrows this means Stacked Borrows will stop recursing at that type during retags. In terms of the LLVM IR we generate it means we must not add or attributes for references inside that type. We don't have such a type currently but I think it makes sense to make that type (or even if we add a new type for this, should use it). Also see .
I believe included a fix for this.
Doesn't look like it -- the user-provided closure seems to be handled exactly the same as currently?
Ah, I read too quickly and misunderstood, apologies. It solves a different potential unsoundness (one more similar to the Arc drop issue).
Yeah, it looks like an alternative fix for the part of
While the , I am proposing a preliminary fix in
Change:
<ins> warning: the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/const-projection-err.rs:4:26 | LL | #![cfg_attr(gce, feature(generic_const_exprs))] |                          ^^^^^^^^^^^^^^^^^^^ | = note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information = note: `#[warn(incomplete_features)]` on by default error[E0271]: type mismatch resolving `<T as TraitWAssocConst>::A == 1` --> $DIR/const-projection-err.rs:14:11 | LL |     foo::<T>(); |           ^ expected `0`, found `1` | note: required by a bound in `foo` --> $DIR/const-projection-err.rs:11:28 | LL | fn foo<T: TraitWAssocConst<A = 1>>() {} |                            ^^^^^ required by this bound in `foo` error: aborting due to previous error; 1 warning emitted For more information about this error, try `rustc --explain E0271`. </ins>

Discussion:
thread panicked at 'called on a value', <details<summaryBacktrace</summary</detailsRegression in nightly-2022-12-04, in rollup , likely from (
Change:
<ins> // Regression test for #77179. #![feature(type_alias_impl_trait)] type Pointer<T> = impl std::ops::Deref<Target=T>; fn test() -> Pointer<_> { //~^ ERROR: the type placeholder `_` is not allowed within types Box::new(1) } fn main() { test(); } </ins>

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
The backtrace suggests that ICE is caused by error formatting machinery. This is a corner case that should be fixed, but my original intention was to provide a concrete type. Sadly, it didn't work out either: results in: Will this be possible one day? My intuition tells me that the snippet above should work. Apologies if this is an improper place for such questions.
The original no longer ICEs since , however the following does Maybe a different ICE?
And the above no longer ICEs since
Change:
#![feature(rustdoc_internals)] #![doc(rust_logo)] #![doc(html_root_url = "https://doc.rust-lang.org/nightly/nightly-rustc/")] <ins> #![cfg_attr(bootstrap, feature(c_str_literals))] </ins> #![feature(exact_size_is_empty)] #![feature(extern_types)] #![feature(hash_raw_entry)]

Discussion:
hello everyone, I got this error when I bootstrap the current rust-beta branch: There was a lot of pushing and reverting changesets relevant to the c literals stabilization, I tried to get an overview of what backport might be missing here, but I failed and am at a loss. I am on linux x86_64, with musl as my libc, I doubt the later is causing the issues.
What are you using as your bootstrap compiler? We only support using the previous release.
I think I understand what is going on. If you try to bootstrap 1.77 from 1.76, it will fail. We were intending to have c-string literals stabilized in 1.76, but that got reverted. However, the revert did not include the appropriate parts of I can probably put something together to fix it.
Posted with a fix.
Change:
#llvm-tools = true # Indicates whether the `self-contained` llvm-bitcode-linker, will be made available <del> # in the sysroot </del> <ins> # in the sysroot. It is required for running nvptx tests. </ins> #llvm-bitcode-linker = false # Whether to deny warnings in crates

Discussion:
With the latest , when I run a run-make test twice in a row, bootstrap rebuilds and : This has to be a recent regression, it didn't happen until ~yesterday. Confirmed with that it also happens for them.
Sounds suspiciously similar to
Yeah this is again caused by being enabled :laughing: Do you think that there's some more general solution to the rebuild problem?
Thanks for notifying me about this. I am travelling this weekend, meaning i might not have a chance to thoroughly investigate before Monday. (But I will at the latest be able to look on Monday). The last time it was due to dependency on the same crates with different rustflags. One from llbc-linker and one from some other tool (rustdoc?). The two different invocations maps to the same cache entry but is invalid between each other and thus triggers a rebuild. The solution last time was to mimic the rustflags being used other places in llbc-linker. That might be a good short term solution now as well. I don't know about the long term solution but it seems like either caching multiple versions of a crate or unifying the rustflag somewhere might be alternatives?
Of course, there's no rush, I just wanted to let you know, given that you already have some experience in debugging this :laughing: This seems rather brittle though, as you mention. I wonder what's so unique about this tool that it causes these rebuilds so often. You mentioned that we cannot share flags between all Step invocations. But maybe it would make sense to better share flags between at least this tool and other steps, rather than hardcoding selected flags? (as was done last time with the parallel compiler).
Actually, I wonder if we really need to enable this linker by default in all four bootstrap profiles.
Sure, seems fine to me. I didn't expect it to be a problem this frequently.
posted instead to disable this flag by default, I don't think it should be enabled for most contributors.
Change:
if is_async { "async fn" } else { "impl Trait" }, ); <del> if let Ok(snippet) = tcx.sess.source_map().span_to_snippet(span) { if snippet == "Self" { err.span_suggestion( span, "consider spelling out the type instead", format!("{:?}", ty), Applicability::MaybeIncorrect, ); } </del> <ins> for (span, name) in visitor.selftys { err.span_suggestion( span, "consider spelling out the type instead", name.unwrap_or_else(|| format!("{:?}", ty)), Applicability::MaybeIncorrect, ); </ins> } err.emit(); }

Discussion:
Following the improvement for the diagnostic of the error reported in this issue , it would be nice (depending on how is prioritized) to have the same error message when instead of returning the function returns . When is returned I get a nice error message (on rustc 1.47): But if is used I get: with no suggestion to spell the type.
remove-assignment feel free to re-claim if you are working on this.
Change:
use syntax::ast; use syntax::attr; use syntax::feature_gate::{AttributeGate, AttributeType, Stability, deprecated_attributes}; <del> use syntax_pos::Span; </del> <ins> use syntax_pos::{Span, SyntaxContext}; </ins> use syntax::symbol::keywords; use rustc::hir::{self, PatKind};

Discussion:
If any linting or suggestion is done in this case, it should suggest cc this has been in rustc forever, but clippy is only lately going crazy on it. Could this have come from your PR, too?
Hmm, shouldn't have been affected, but I'll investigate.
this is messing up clippy pretty bad. Any idea where to start looking?
So I tried to figure out what's going on, but I got lost in the code. As far as I can see it should be setting the expansion info. But it appears the passed to doesn't contain the expansion info. So maybe we need to generate a new span here with the from ?
The span passed to is the call site span, so it shouldn't contain the expansion info. The issue here is that is using the call site span directly in the expansion ( is call site span). To fix this, the macro should add expansion info to the call site span like does . Adding that line in should fix this issue. Are there other built-in macros that also have this problem in practice or is it just ?
I'd assume others have it too, but I'll check. So the passed call site span should only be used directly for error reporting, but never for creating ast items?
Right, unless you want an AST item with the raw (unexpanded) call site span -- I don't think we ever want that.
Change:
target_cpu: Option<String> = (None, parse_opt_string, [TRACKED], "select target processor (`rustc --print target-cpus` for details)"), target_feature: String = (String::new(), parse_string, [TRACKED], <del> "target specific attributes (`rustc --print target-features` for details)"), </del> <ins> "target specific attributes. (`rustc --print target-features` for details).  This feature is unsafe."), </ins> passes: Vec<String> = (Vec::new(), parse_list, [TRACKED], "a list of extra LLVM passes to run (space separated)"), llvm_args: Vec<String> = (Vec::new(), parse_list, [TRACKED],

Discussion:
When discussing in the compiler team triage meeting, it became clear that target-features ought to be considered generally unsafe. We should document this fact in the and in the . Ideally, we'd also start listing out known gotchas. For example, in noted that: and had a . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Compiler triage meeting: Marking as P-medium
claim
The reference section about mentions this: The link to the section of the reference mentions this as well: So maybe the could point people to the reference?
That is one way in which targetfeature is unsafe, but it's not the one which was the subject of so just pointing at the reference as it is is insufficient. Plus, it's also more about than (where the compiler will hit you in the face with ). So the rustc book is a better place for it than the reference IMO.
I think that for users to better properly understand the UB involved, it might be more educational to say that stamps on all functions, but with the subtle difference that it doesn't make them , so no unsafe-check happens when this triggers UB. The reference does not document all current perils of using . In particular, it does not document that these can change the function call ABI, and that rustc neither checks that nor handles it correctly - we just currently assume people don't do that. Independently of whether we document that in the rustc book as well or not, that bit should also probably be documented in the reference, because it is easy to trigger this. On stable Rust, I think one can indeed only trigger this via and the reference should say so, but on nightly one can definitely trigger this with bare within a single Rust crate.
Change:
use rustc_index::vec::{Idx, IndexVec}; use rustc_middle::mir::{self, traversal, BasicBlock}; use rustc_middle::mir::{create_dump_file, dump_enabled}; <ins> use rustc_middle::ty::print::with_no_trimmed_paths; </ins> use rustc_middle::ty::TyCtxt; use rustc_span::symbol::{sym, Symbol};

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
Are you able to fill out the requested details of the crash?
updated
Can you provide the dependencies in use? From what I can tell they aren't supported on Linux, but I'm unsure if I'm looking at the correct crate
tokio 0.1.21
Reduced this a little to It looks like somewhere down the line, a constant is being pretty printed into the .dot with path trimming, which later causes an ICE since no error is actually being emitted
Change:
} } <del> let args = cap.name("args").map_or(vec![], |m| shlex::split(m.as_str()).unwrap()); </del> <ins> let args = cap.name("args").map_or(Some(vec![]), |m| shlex::split(m.as_str())); let args = match args { Some(args) => args, None => { print_err( &format!( "Invalid arguments to shlex::split: `{}`", cap.name("args").unwrap().as_str() ), lineno, ); errors = true; continue; } }; </ins> if !cmd.validate(&args, commands.len(), lineno) { errors = true;

Discussion:
The following comment causes a panic in jsondocck currently: Expected: Pretty error like 'Invalid split pattern on line X' Current: Giant stack trace, only obvious if you know what that line is doing. Opening this for tracking and so I don't forget to fix it <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assign (since you said "so I don't forget to fix it")
Change:
/// Inserts the given element just after the element most recently returned by `.next()`. /// The inserted element does not appear in the iteration. /// <del> /// # Examples /// /// ``` /// #![feature(linked_list_extras)] /// /// use std::collections::LinkedList; /// /// let mut list: LinkedList<_> = vec![1, 3, 4].into_iter().collect(); /// /// { ///     let mut it = list.iter_mut(); ///     assert_eq!(it.next().unwrap(), &1); ///     // insert `2` after `1` ///     it.insert_next(2); /// } /// { ///     let vec: Vec<_> = list.into_iter().collect(); ///     assert_eq!(vec, [1, 2, 3, 4]); /// } /// ``` </del> <ins> /// This method will be removed soon. </ins> #[inline] #[unstable( feature = "linked_list_extras", reason = "this is probably better handled by a cursor type -- we'll see", issue = "27794" )] <ins> #[rustc_deprecated( reason = "Deprecated in favor of CursorMut methods. This method will be removed soon.", since = "1.47.0" )] </ins> pub fn insert_next(&mut self, element: T) { match self.head { // `push_back` is okay with aliasing `element` references

Discussion:
This is a tracking issue for the unstable methods in the standard library. cc perhaps you can fill this in some more? The specific methods in question are: -
This is basically a lame version of cursors, which is what we should use instead imo. It's not 1:1 though -- this api lets you have all the elements yielded at once. Classic iterator tradeoff.
Triage: these are still unstable.
There are some ideas for a more complete API in
seems misnamed. Doesn't it do exactly what we call elsewhere?
I'm going to echo thoughts: An iterator conceptually represents a (double-ended) range of elements. The only operation that it supports is popping an element off the end of that range. A cursor on the other hand represents a position in a collection, and can be moved backwards or forwards in the collection. The cursor can be used to insert or remove an element at any given position in the collection. I strongly oppose adding insertion/deleting methods to since they do not fit at all with existing iterator usage patterns ( loops and functional-style methods). As I mentioned in the linked thread, a design based on the types in could be used.
Since we now have cursors, I think these methods should be removed.
Reopening since we only deprecated the methods instead of removing them. I'd say give it about 2 weeks then remove them.