jiebi/CodeConvo huggingface dataset:
Change:
rhs: @ast::Expr, // Used only in the error case expected_result: Option<ty::t>, <del> allow_overloaded_operators: AllowOverloadedOperatorsFlag </del> <ins> is_binop_assignment: IsBinopAssignment </ins> ) { let tcx = fcx.ccx.tcx;

Discussion:
OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:
Change:
self.add_id_checked(id, Kind::is_trait, "Trait"); } <del> fn add_struct_enum_union_id(&mut self, id: &'a Id) { self.add_id_checked(id, Kind::is_struct_enum_union, "Struct or Enum or Union"); </del> <ins> fn add_type_id(&mut self, id: &'a Id) { self.add_id_checked(id, Kind::is_type, "Type (Struct, Enum, Union or Typedef)"); </ins> } /// Add an Id that appeared in a trait

Discussion:
Produces json (abridged) which is correct, but fails for this modify labels: +A-rustdoc-json +A-testsuite +T-rustdoc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This was found while working on , as it causes jsondoclint to fail for core (in addition to it catching the linked issue)
Change:
.collect::<Vec<_>>(), errors::UnusedVariableTryPrefix { label: if !suggestions.is_empty() { Some(pat.span) } else { None }, <del> sugg: errors::UnusedVariableTryPrefixSugg { spans: non_shorthands, name, }, </del> <ins> name, sugg, </ins> string_interp: suggestions, }, );

Discussion:
Consider the following file in a cargo package: Cargo will warn that is not used. Upon running , cargo will change the second parameter from to , making the compilation fail. Even worse, if contained a field then would change the variable without producing any warning. a new cargo binary project with the above snippet in (presumably with ) No response No response
just applies any  suggestion produced by . In this case, the suggestion from is to replace with . I went ahead and ran to see if it could help me understand what is going on better: ` (I cleaned up the expanded code slightly, but it is the same) Looking at the expanded code, it makes me think that is seeing in as the source of the problem since it expands to and is unused in this case. The normal suggestion is to add an underscore to so it would not be "unused". So suggests to change the being passed to the macro call as it does not understand that the warning is really coming from within the macro, not the call itself. It also could be suggesting this as is not valid rust (macro?) syntax. If you change your example slightly, correctly suggests the problem comes from within the macro call. To me, this seems like a problem with , but I do not know enough about the compiler internals to be 100% certain.
Transferred to rust-lang/rust, since the suggestions are generated by the compiler.
Yes, this issue comes from rustc. The lint is emitted from here Maybe we only point out that there is an unused variable coming from , but without the suggestion? I'm not sure what is a proper lint for this test case. any thoughts on it?
The quick and straightforward way to fix this would be to only emit the suggestion in this lint if the span has the root context, but then a subset of valid suggestions wouldn't be emitted. I had an older PR that I'm having trouble finding that would automatically do that for every diagnostic, but IIRC it had some negative perf impact when not implementing it very simplistic. In this we can probably instead check that all of the spans involved have the same . If they don't, don't suggest changes.
Change:
<del> # only-macos # # Check that a set deployment target actually makes it to the linker. # This is important since its a compatibility hazard. The linker will # generate load commands differently based on what minimum OS it can assume. include ../tools.mk ifeq ($(strip $(shell uname -m)),arm64) GREP_PATTERN = "minos 11.0" else GREP_PATTERN = "version 10.13" endif OUT_FILE=$(TMPDIR)/with_deployment_target.dylib all: env MACOSX_DEPLOYMENT_TARGET=10.13 $(RUSTC) with_deployment_target.rs -o $(OUT_FILE) # XXX: The check is for either the x86_64 minimum OR the aarch64 minimum (M1 starts at macOS 11). # They also use different load commands, so we let that change with each too. The aarch64 check # isn't as robust as the x86 one, but testing both seems unneeded. vtool -show-build $(OUT_FILE) | $(CGREP) -e $(GREP_PATTERN) </del>

Discussion:
Repro: The same happens for 1.23-stable.
does this still reproduce?
no repro for .
Change:
macro_rules! negative(( $ e : expr ) => { $ e < 0 }); fn main() { (1 as i32) < 0; }

Discussion:
Since the check no longer panics on failure. It is obvious in the commit that the invocation is removed from the check, and no other changes are made in the function to remedy it. It can be verified by adding a new pretty test case like: The resulting pretty printed file is slightly different, the comparison fails and the message is logged, but the test continues into the type check, which fails for a different reason and then panics. If you fix the type check (by adding the module and fn main) then the whole test passes and the error message is swallowed even though the source comparison is still not matching.
Change:
} } <ins> /// Recover `$path::(...)` as `$path(...)`. /// /// ```ignore (diagnostics) /// foo::(420, "bar") ///    ^^ remove extra separator to make the function call /// // or /// match x { ///    Foo::(420, "bar") => { ... }, ///       ^^ remove extra separator to turn this into tuple struct pattern ///    _ => { ... }, /// } /// ``` fn recover_fn_call_leading_path_sep( &mut self, style: PathStyle, prev_token_before_parsing: Token, error: &mut Diag<'_>, ) { if ((style == PathStyle::Expr && self.parse_paren_comma_seq(|p| p.parse_expr()).is_ok()) || (style == PathStyle::Pat && self .parse_paren_comma_seq(|p| { p.parse_pat_allow_top_alt( None, RecoverComma::No, RecoverColon::No, CommaRecoveryMode::LikelyTuple, ) }) .is_ok())) && !matches!(self.token.kind, token::ModSep | token::RArrow) { error.span_suggestion_verbose( prev_token_before_parsing.span, format!( "consider removing the `::` here to {}", match style { PathStyle::Expr => "call the expression", PathStyle::Pat => "turn this into a tuple struct pattern", _ => { return; } } ), "", Applicability::MaybeIncorrect, ); } } </ins> /// Parses generic args (within a path segment) with recovery for extra leading angle brackets. /// For the purposes of understanding the parsing logic of generic arguments, this function /// can be thought of being the same as just calling `self.parse_angle_args()` if the source

Discussion:
Given an invalid call such as: The following diagnostic is issued: This gets much worse on multiline calls: Which just prints out a diagnostic nowhere near the error: Ideally this should mention something about either missing a missing turbofish (e.g. ), or a missing identifier (e.g. ). This would at least get the error pointing to the correct spot. Latest playground nightly (2024-02-09) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oh, wow, it didn't even occur to me until now that the expression is syntactically valid .< Edit: Wow, even is syntactically well-formed.
This should pretty easy to fix, basically if we fail to parse a type here we should first of all attach a label to the saying something akin to while parsing this list of parenthesized type arguments starting here and we should suggest removing the trailing path separator if the is , the parenthesized generics aren't followed by or and if the list of non-types we encountered can be successfully parsed as a list of expressions (using a snapshot parser). Furthermore, if the is we can try to reparse the list as a list of patterns and provide the same structured suggestion. I will gladly mentor & review any PR for this.
claim
Hello , is this issue still open for mentoring? I can see that already claimed the issue, but there seems to be no progress.
I read the code but no time to finish it at the moment. You can do it.
Change:
<ins> error: expected at least one digit in exponent --> $DIR/issue-91434.rs:2:11 | LL |     [9; [[9E; h]]]; |           ^^ error[E0425]: cannot find value `h` in this scope --> $DIR/issue-91434.rs:2:15 | LL |     [9; [[9E; h]]]; |               ^ not found in this scope error: constant expression depends on a generic parameter --> $DIR/issue-91434.rs:2:9 | LL |     [9; [[9E; h]]]; |         ^^^^^^^^^ | = note: this may fail depending on what value the parameter takes error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0425`. </ins>

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting a malformed float error, so low priority. Note that slight modifications of the input fix the panic. For example using instead of results in no panic. Also there is no panic if compling only the string . Affected versions: I tried nightly 2021-11-30 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Might be related? Formatting of "1e-15" behavior seems to have changed on nightly for f64 and f32.
It may have a common cause, but you should open a separate issue because the pull request that fixes this doesn't fix your problem.
Change:
only appear at the root of your crate, not inside `mod`. This ensures that `$crate` is a single identifier. <del> # A final note </del> <ins> # The deep end </ins> <del> Macros, as currently implemented, are not for the faint of heart. Even ordinary syntax errors can be more difficult to debug when they occur inside a macro, and errors caused by parse problems in generated code can be very tricky. Invoking the `log_syntax!` macro can help elucidate intermediate states, invoking `trace_macros!(true)` will automatically print those intermediate states out, and passing the flag `--pretty expanded` as a command-line argument to the compiler will show the result of expansion. </del> <ins> The introductory chapter mentioned recursive macros, but it did not give the full story. Recursive macros are useful for another reason: Each recursive invocation gives you another opportunity to pattern-match the macro's arguments. As an extreme example, it is possible, though hardly advisable, to implement the [Bitwise Cyclic Tag](http://esolangs.org/wiki/Bitwise_Cyclic_Tag) automaton within Rust's macro system. ```rust #![feature(trace_macros)] macro_rules! bct { // cmd 0:  d ... => ... (0, $($ps:tt),* ; $_d:tt) => (bct!($($ps),*, 0 ; )); (0, $($ps:tt),* ; $_d:tt, $($ds:tt),*) => (bct!($($ps),*, 0 ; $($ds),*)); // cmd 1p:  1 ... => 1 ... p (1, $p:tt, $($ps:tt),* ; 1) => (bct!($($ps),*, 1, $p ; 1, $p)); (1, $p:tt, $($ps:tt),* ; 1, $($ds:tt),*) => (bct!($($ps),*, 1, $p ; 1, $($ds),*, $p)); // cmd 1p:  0 ... => 0 ... (1, $p:tt, $($ps:tt),* ; $($ds:tt),*) => (bct!($($ps),*, 1, $p ; $($ds),*)); // halt on empty data string ( $($ps:tt),* ; ) => (()); } fn main() { trace_macros!(true); # /* just check the definition bct!(0, 0, 1, 1, 1 ; 1, 0, 1); # */ } ``` Exercise: use macros to reduce duplication in the above definition of the `bct!` macro. # Procedural macros </ins> If Rust's macro system can't do what you need, you may want to write a [compiler plugin](plugins.html) instead. Compared to `macro_rules!` macros, this is significantly more work, the interfaces are much less stable, <del> and the warnings about debugging apply ten-fold. In exchange you get the </del> <ins> and bugs can be much harder to track down. In exchange you get the </ins> flexibility of running arbitrary Rust code within the compiler. Syntax extension plugins are sometimes called *procedural macros* for this reason.

Discussion:
As of the original docs on recursive macros are gone. We should have an example that clearly illustrates the increased power vs. the built-in repetition operator.
Change:
let mut rpo = traversal::reverse_postorder(mir); let temps = promote_consts::collect_temps(mir, &mut rpo); rpo.reset(); <ins> let param_env = tcx.param_env(def_id); let mut temp_qualif = IndexVec::from_elem(None, &mir.local_decls); for arg in mir.args_iter() { let mut qualif = Qualif::NEEDS_DROP; qualif.restrict(mir.local_decls[arg].ty, tcx, param_env); temp_qualif[arg] = Some(qualif); } </ins> Qualifier { mode, span: mir.span,

Discussion:
These currently compile, even if they can be used from compile-time code to trigger a drop: cc
Change:
use rustc::hir::def_id::DefId; use rustc::hir::map::Map; use rustc::hir::intravisit::{self, Visitor, NestedVisitorMap}; <del> use rustc::hir::{self, Node, Destination}; </del> <ins> use rustc::hir::{self, Node, Destination, GeneratorMovability}; </ins> use syntax::struct_span_err; use syntax_pos::Span; use errors::Applicability;

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:
<ins> // check-pass #![feature(type_alias_impl_trait)] fn foo() { struct Foo<'a> { x: &'a mut u8, } impl<'a> Foo<'a> { fn foo(&self) -> impl Sized {} } // use site let mut x = 5; let y = Foo { x: &mut x }; let z = y.foo(); let _a = &x; // invalidate the `&'a mut`in `y` let _b = z; // this should *not* check that `'a` in the type `Foo<'a>::foo::opaque` is live } fn bar() { struct Foo<'a> { x: &'a mut u8, } // desugared type FooX<'a> = impl Sized; impl<'a> Foo<'a> { fn foo(&self) -> FooX<'a> {} } // use site let mut x = 5; let y = Foo { x: &mut x }; let z = y.foo(); let _a = &x; // invalidate the `&'a mut`in `y` let _b = z; // this should *not* check that `'a` in the type `Foo<'a>::foo::opaque` is live } fn main() {} </ins>

Discussion:
This code should pass but it doesn't: This is resurrected. Cc label F-typealiasimpl_trait C-bug T-compiler T-types
Oh heh, I fixed the situation for registering the hidden type but didn't allow implying anything from that.
Change:
|         | |         required by a bound introduced by this call | <del> = note: consider using `Box::pin` </del> <ins> = note: consider using the `pin!` macro consider using `Box::pin` if you need to access the pinned value outside of the current scope </ins> note: required because it appears within the type `Sleep` --> $DIR/pin-needed-to-poll-2.rs:8:8 |

Discussion:
Consider the following code, taken from the (): Local pin construction was stabilized in . We should update the diagnostics to suggest this instead of the more expensive call. No response cc/ This is probably a "good first issue" as well. If someone can tag it as such? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
In some cases, works but does not (e.g., if you want ownership of the pinned future), so I think it's better to suggest both. Or something like:
claim
Alright, the suggestion has been in . IDK how to link a PR to an issue though, should I just reference the issue in the description of the PR?
if you put " in the PR description, it will automatically close this issue when the PR is merged :)
Change:
fn visit_terminator(&mut self, terminator: &Terminator<'tcx>, location: Location) { match &terminator.kind { TerminatorKind::Goto { target } => { <del> self.check_bb(location, *target); </del> <ins> self.check_edge(location, *target, EdgeKind::Normal); </ins> } TerminatorKind::SwitchInt { targets, values, .. } => { if targets.len() != values.len() + 1 {

Discussion:
Blocks that are part of unwinding code always need to marked as . This seems like an easy thing to check in the validation pass. I believe this would have caught a bug in the generator transform (a pretty long time ago). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Good point! Moreover, cleanup block terminators should also only jump to cleanup blocks, and other terminators should only jump to non-cleanup blocks. Basically, unwind edges must be the only ones that cross the "cleanup to non-cleanup" boundary. (Miri is already checking this.)
claim
Change:
#![feature(unboxed_closures)] #![feature(generator_trait)] #![feature(fn_traits)] <del> #![feature(int_bits_const)] </del> #![feature(min_specialization)] #![feature(auto_traits)] #![feature(nll)]

Discussion:
Tracking issue for as introduced by Gated behind .
modify labels: +T-libs
Error: Label P can only be set by Rust team members Please let know if you're having trouble with this bot.
This has been in a few releases, is used in many places in rustc itself, and there's no open questions so far. Time to stabilize? merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
We agreed in the libs meeting just now to revert stablization, since the is significant throughout the ecosystem, through . :( We can stabilize it again once that is solved upstream.
Closing this since has been merged.
Change:
*boxed = 42; assert!(*boxed == 42); <del> *boxed </del> <ins> *Box::leak(boxed) </ins> }; assert!(VALUE == 42);

Discussion:
() Note that this works even if implements in a non- way. This seems hightly problematic, especially provided we eventually want to support constructing at compile time. Relevant PR: Of course that impl claims to be unstable, but as we all know trait implementations are never unstable, unless the trait is unstable. (For ordinary traits, implementations of are thus unstable merely due to the fact that no user can use any such implementations in stable code yet.) label regression-from-stable-to-stable The fix should be straightforward: Remove the implementation (i.e. revert it to be non-), and add a test.
cc
that impl should be illegal, shouldn't it? I would expect us to need an explicit here. But also, reverting and maybe even backporting that impl for now seems like the right choice to me
Good catch! Actually calling this leads to odd behavior: It doesn't even say what went wrong. I expected an error saying a non-const function was called as part of the drop glue.
Change:
// except according to those terms. fn main() { <del> "".chars().fold(|_, _| (), ()); //~^ ERROR cannot determine a type for this expression: unconstrained type </del> <ins> "".chars().fold(|_, _| (), ()); //~ ERROR is not implemented for the type `()` </ins> }

Discussion:
Hello folks, I'm dutifully reporting this as the compiler told me to so. The bug is the same reported already by and , although it appeared on a different circumstance. I have this simple program (I'm a Rust newbie so It's very likely I'm doing things terribly wrong): Expected outcome: The compile to tell me how wrong I am Actual outcome: Meta Shows up with latest beta as well:
cc me
Minified: We do write tyerr to node 11 (). Apparently we somehow don't report an error.
triage: P-medium
Whoops. There is indeed an error, which is indeed gets to reportselectionerror, but when we do (), we get an error, and think this one was a duplicate.
no_std version:
You don't even need the trait:
Change:
} fn check_def(&mut self, sp: Span, id: ast::NodeId) { <del> let tty = match self.cx.tcx.ast_ty_to_ty_cache.borrow().get(&id) { Some(&t) => t, None => panic!("ast_ty_to_ty_cache was incomplete after typeck!") }; let tty = infer::normalize_associated_type(self.cx.tcx, &tty); </del> <ins> let tty = ast_ty_to_normalized(self.cx.tcx, id); </ins> match ImproperCTypesVisitor::check_type_for_ffi(self, &mut FnvHashSet(), tty) { FfiResult::FfiSafe => {}

Discussion:
made the lint trigger for tuples, but as far as I understand, returning is equivalent to returning cvoid, and therefore should be allowed. Here is an example:
Yes, stupid mistake; I'll fix it. (As a workaround, you can write .)
since was merged i'm closing
Change:
} /// Given the id of some node in the AST, finds the `LocalDefId` associated with it by the name <ins> /// resolver (if any). fn orig_opt_local_def_id(&self, node: NodeId) -> Option<LocalDefId> { self.resolver.node_id_to_def_id.get(&node).map(|local_def_id| *local_def_id) } fn orig_local_def_id(&self, node: NodeId) -> LocalDefId { self.orig_opt_local_def_id(node) .unwrap_or_else(|| panic!("no entry for node id: `{:?}`", node)) } /// Given the id of some node in the AST, finds the `LocalDefId` associated with it by the name </ins> /// resolver (if any), after applying any remapping from `get_remapped_def_id`. /// /// For example, in a function like `fn foo<'a>(x: &'a u32)`,

Discussion:
This is an attempt to reproduce a minimal example of a regression problem (backwards compatibility not assured) from a closed-source company codebase. I tried this code: - I expected to see the code building (This code is old and was building for years on rust 1.54, and builds on rust 1.63. the code works as intended in the proprietary codebase) Instead, this happened: It most recently worked on: 1.63 (from my repo, commit : ) It does not work anymore on version 1.64: (from my repo, commit : ) Including the backtrace by setting does not change anything to the error message. I do not know why this problem occured though. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
searched nightlies: from nightly-2022-08-01 to nightly-2022-10-01 regressed nightly: nightly-2022-08-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsOut of the rollup, this was probably caused by ?
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Reopening to track backports.
can this be closed? was backported to stable, right? cc (unsure who to ping)
I have no involvement with this whatsoever.^^ is usually doing backports.
was beta backported to 1.65, which is now released. We won't be having a 1.64.1 release. So this should be considered "fixed", since it is resolved on the current stable release of Rust.
Change:
@$(call E, cp: $@) $(Q)cp -a $< $@ 2> /dev/null <ins> HTML_DEPS += doc/favicon.inc doc/favicon.inc: $(D)/favicon.inc | doc/ @$(call E, cp: $@) $(Q)cp -a $< $@ 2> /dev/null </ins> doc/full-toc.inc: $(D)/full-toc.inc | doc/ @$(call E, cp: $@) $(Q)cp -a $< $@ 2> /dev/null <del> HTML_DEPS += doc/favicon.inc doc/favicon.inc: $(D)/favicon.inc | doc/ </del> <ins> HTML_DEPS += doc/footer.inc doc/footer.inc: $(D)/footer.inc | doc/ @$(call E, cp: $@) $(Q)cp -a $< $@ 2> /dev/null doc/footer.tex: $(D)/footer.tex | doc/ </ins> @$(call E, cp: $@) $(Q)cp -a $< $@ 2> /dev/null

Discussion:
Per we should have the docs licensed correctly. Nominating.
I can have a look at this.