jiebi/CodeConvo huggingface dataset:
Change:
test_40569(); test_35650(); test_24189(); <ins> test_51477(); </ins> }

Discussion:
This is similar to the same buggy behavior we saw for matchers fixed in 1.20.0. For example in Rust 1.19 the following code fails to compile with the message , but correctly prints followed by as of 1.20. The matcher is currently broken in the same way. rustc 1.28.0-nightly ( 2018-06-09)
The ident issue was , so mentioning who fixed that one in . Would you be interested in taking a look at this similar case?
Duplicate of . should still be working on it I think?
Thanks! Let's continue to track this as part of .

is not valid lifetime, so using specifier should not cause local ambiguity. Example: cc tracking issue for $:lifetime matcher:
The problem is that currently a lifetime "may start with anything" because we haven't spelled out the rules. Edit , and insert the case into the function. You may also want to review this function to see if any case did not consider and recent syntax additions.
I'd like to take this issue
I'm on a train right now with limited connectivity, so I cant push my PR, but I have a change that I've compiled and tested, and I'm not sure if it's working correctly, I could use some more background. I this to maybeginwith, compiled and set as a custom toolchain all good so far I created a new cargo bin project (I didn't see any tests for macro_parser or any test dirs in the libsyntax directory, not sure if there's a better way to do this) and made the main function define that macro and use it, as in the original example. With nightly it showed the expected ambiguity error. Then I used rustup overrides with my custom toolchain and rebuilt, and it compiled with no errors. Is this the expected behavior when parsing the macro? I'm unclear on how the macro parser works in rust. Is it that, before adding this branch, when parsing they both matched the specifier. But after adding the bit that says "no that ain't a lifetime," it no longer gets caught by that arm of the macro, and when parsing the , it just skips it and doesn't complain? I guess I was expecting it to say something like "lifetimes cant start with #" instead of the local ambiguity, not for it to just stop being an error. Also, you mentioned reviewing the rest of the function to see if other things didn't consider lifetime or other new syntax additions, but I'm not sure what other syntax additions there are to consider.
Yes this is the expected behavior. When returns false, the parser knows that is definitely not a and thus stop matching against . The original template expects a next, which it matched, and thus everything goes fine. This is similar to the behavior of Basically to check the interaction with all other fragment specifiers, e.g. Interpolated lifetimes are encoded as which I don't see listed in the function.

But maybe adding a case is sufficient to disambiguate the above examples. (For new syntax I'd like to reserve alongside in , though that would be off-topic and could also be a breaking change.)
apparently not
Change:
<ins> // edition: 2021 use u8 as imported_u8; use unresolved as u8; //~^ ERROR unresolved import `unresolved` 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. --need <!-- 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
Crashes on but not on
Regression in nightly-2023-07-01 Regression in Regression in cc
reduced:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
ENV RUN_CHECK_WITH_PARALLEL_QUERIES 1 ENV SCRIPT python3 ../x.py --stage 2 test src/tools/expand-yaml-anchors &&  <del> python3 ../x.py check --target=i686-pc-windows-gnu --host=i686-pc-windows-gnu --all-targets &&  </del> <ins> python3 ../x.py check --target=i686-pc-windows-gnu --host=i686-pc-windows-gnu &&  </ins> python3 ../x.py build --stage 0 src/tools/build-manifest &&  python3 ../x.py test --stage 0 src/tools/compiletest &&  python3 ../x.py test --stage 0 core alloc std test proc_macro && 

Discussion:
Because currently it doesn't. has a handful of problems which are reported elsewhere, but discovering problems with MIR optimizations is often as simple as building the compiler with the optimization enabled and . So we should do that in CI. Note that all MIR opt levels are supposed to be sound, and known unsoundness is supposed to be gated behind , which I am not suggesting we test with. Currently attempting to build the standard library with these flags results in pages of this error: Which looks to me like <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
also mentioned to me that some opts are using as a minimum threshold, it may be helpful to test that as well (maybe in a separate builder). does not change the output of the compiler and should be ok to turn on unconditionally for libstd; we might want to be more selective about where we enable it for the compiler itself, though, since it's a lot slower. We should also have at least one builder where we enable for UI tests.
Mentoring instructions: new option to and This option should pass unconditionally for libstd. Test it works locally with , you should see the ICE posted above. that new option on all builders around here: You can test that works by opening a PR (please put in the description) and making sure it shows the same ICE. that works, we can figure out whether we want to enable this for rustc as well on some builders; maybe we should have separate and configs? And for turning it on in compiletest?
claim
Reproduced it on the PR.
Change:
})) } <ins> pub fn debug_hygiene_data(verbose: bool) -> String { HygieneData::with(|data| { if verbose { format!("{:#?}", data) } else { let mut s = String::from(""); s.push_str("Expansions:"); data.expn_data.iter().enumerate().for_each(|(id, expn_info)| { let expn_info = expn_info.as_ref().expect("no expansion data for an expansion ID"); s.push_str(&format!( "n{}: parent: {:?}, call_site_ctxt: {:?}, kind: {:?}", id, expn_info.parent, expn_info.call_site.ctxt(), expn_info.kind, )); }); s.push_str("nnSyntaxContexts:"); data.syntax_context_data.iter().enumerate().for_each(|(id, ctxt)| { s.push_str(&format!( "n#{}: parent: {:?}, outer_mark: ({:?}, {:?})", id, ctxt.parent, ctxt.outer_expn, ctxt.outer_transparency, )); }); s } }) } </ins> impl SyntaxContext { #[inline] pub const fn root() -> Self {

Discussion:
E.g. becomes Specifically, the syntax contexts of and are linked (the s refer to the same identifier, even with hygiene) but this is not represented in the output at all, so one might interpret them as being distinct identifiers.
There is no more pretty=hygene, was it replaced with something?
Closing. is apparently no longer a thing, and the output looks sufficiently different with that I don't think it's the same.
There is a FIXME related to this issue, Now that the issue is closed can the FIXME be fix, or made more specific?
Looks like is a thing though so reopening... output today is below. I'm not completely sure whether this is fixed or not --- the output looks the same for the two s, I guess? Not sure which are being referred to either...
Change:
snapshot.bump(); // `(` match snapshot.parse_struct_fields(path, false, token::Paren) { Ok((fields, ..)) if snapshot.eat(&token::CloseDelim(token::Paren)) => { <del> // We have are certain we have `Enum::Foo(a: 3, b: 4)`, suggest </del> <ins> // We are certain we have `Enum::Foo(a: 3, b: 4)`, suggest </ins> // `Enum::Foo { a: 3, b: 4 }` or `Enum::Foo(3, 4)`. *self = snapshot; let close_paren = self.prev_token.span; let span = lo.to(self.prev_token.span); <del> err.cancel(); self.struct_span_err( span, "invalid `struct` delimiters or `fn` call arguments", ) .multipart_suggestion( &format!("if `{}` is a struct, use braces as delimiters", name), vec![(open_paren, " { ".to_string()), (close_paren, " }".to_string())], Applicability::MaybeIncorrect, ) .multipart_suggestion( &format!("if `{}` is a function, use the arguments directly", name), fields .into_iter() .map(|field| (field.span.until(field.expr.span), String::new())) .collect(), Applicability::MaybeIncorrect, ) .emit(); </del> <ins> if !fields.is_empty() { err.cancel(); let mut err = self.struct_span_err( span, "invalid `struct` delimiters or `fn` call arguments", ); err.multipart_suggestion( &format!("if `{}` is a struct, use braces as delimiters", name), vec![ (open_paren, " { ".to_string()), (close_paren, " }".to_string()), ], Applicability::MaybeIncorrect, ); err.multipart_suggestion( &format!("if `{}` is a function, use the arguments directly", name), fields .into_iter() .map(|field| (field.span.until(field.expr.span), String::new())) .collect(), Applicability::MaybeIncorrect, ); err.emit(); } else { err.emit(); } </ins> return Some(self.mk_expr_err(span)); } Ok(_) => {}

Discussion:
I'm seeing an internal compiler error on the following input, found by : Affected versions: I tried nightly 2021-12-01 and stable 1.57 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
slightly simpler example not using attributes the name outside the parentheses and the name between the two colons can be arbitrary, the parentheses, underscore, and comma all appear to matter
I found a fix for this, but currently i am only emitting a suggestion for transforming the input into a struct: how do you guys think should i do a function suggestion? Should i just remove the parameter? Or should i remove the function suggestion altogether and just emit the struct suggestion? or something completely different? here is an example how the same diagnostic's output looks like for a more sane input:
I wouldn't give much thought to suggestions, as it's unlikely that a human will enter this input. So I would just remove the suggestions if they are most likely wrong. For example the struct suggestion is invalid code because structs cannot use as a field name (right?). And I'm not sure what kind of code would use two colons , it's most likely a weird typo, so a generic "unexpected token" error should be fine.
claim
Change:
/// assert_eq!(squared, Poll::Ready(Ok(144))); /// ``` #[stable(feature = "futures_api", since = "1.36.0")] <ins> #[inline] </ins> pub fn map_ok<U, F>(self, f: F) -> Poll<Result<U, E>> where F: FnOnce(T) -> U,

Discussion:
I noticed that in one of my project, inlining [] manually reduces some binary size, then I noticed is not marked . Since both [] and [] are marked , I wonder whether this is an oversight. I failed to reproduce the binary size reduction effect with an example code, but maybe the reason behind inlining and also applies to ? How about [] and []? []: []: []: []: []:
That's surprising. Can you share your project?
Unfortunately, it is a private project, I cannot share it.
Ah okay. I find it suspicious that these functions aren't inlining already. Did you try building your project against a modified standard library with to those functions? Do you still get a code size improvement from manual inlining if you compile with and/or in your release profile? The functions in question ought to already be eligible for inlining, but by default the release profile has multiple codegen units per crate, which can result in surprising failures to inline things. How big are these functions once they are compiled in your crate? The third-party tool can help out here, can you share the output of (of course trimming that down a bit if there are type names in there you don't want to fully disclose) If for whatever reason these functions end up looking big to LLVM after other things are inlined into them, that may explain what's going on here, and your manual inlining has effectively changed in what order LLVM considers inlining things.
I have done some tests on my project, using to check for symbols: Using , does not get inlined; Using , gets inlined; Using and , add to standard library source code, gets inlined; All configurations above are using and . reports that each is about 68 to 96 bytes.
What about and to the standard library code, but without using ? If that configuration gets these functions inlined I think this is worth doing because it unlocks additional useful optimizations for users, but if the optimization is gated behind it's a bit less certain if this is a win. Do you or any other LLVM folks have insight into why would be impactful here? Are we relying on the hint part of its behavior?
It seems that changing standard library source code only works with . Do I need to compile a customized version of Rust in order to test it?
That's what I do. It's a very slow workflow.
Change:
} } <del> fn resolve_and_cache_rustdoc_path(&mut self, path_str: &str, ns: Namespace) -> bool { </del> <ins> fn resolve_and_cache_rustdoc_path(&mut self, path_str: &str, ns: Namespace) -> Option<Res> { </ins> // FIXME: This caching may be incorrect in case of multiple `macro_rules` // items with the same name in the same module. // Also hygiene is not considered. let mut doc_link_resolutions = std::mem::take(&mut self.r.doc_link_resolutions); <del> let res = doc_link_resolutions </del> <ins> let res = *doc_link_resolutions </ins> .entry(self.parent_scope.module.nearest_parent_mod().expect_local()) .or_default() .entry((Symbol::intern(path_str), ns))

Discussion:
Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details
Change:
let output_ty = match *ret_ty.kind() { ty::Infer(ty::TyVar(ret_vid)) => { <del> self.obligations_for_self_ty(ret_vid).find_map(|(_, obligation)| { </del> <ins> self.obligations_for_self_ty(ret_vid).find_map(|obligation| { </ins> get_future_output(obligation.predicate, obligation.cause.span) })? }

Discussion:
Repro: Output:
cc
What's causing this is that we currently inspect the obligations in scope for obligations, but in this case the obligation is (which implies a obligation as a supertrait). This is expected but unfortunate, yes. We could probably fix this particular case in a relatively straightforward way by trying to upcast each pending obligation to a obligation.
I imagine that atm this could be worked around by changing: to
Today, this gives a completely different error about not implementing ...
Updated code to not give the unrelated error (by removing bounds everywhere), still gives the type must be known error.
This comes up for me fairly regularly. It would be really nice to fix it. (e.g., it came up recently in )
We discussed this in the types team 'backlog bonanza' meeting today. Our conclusion was that this is a "nice to have" and that directly fixing this issue felt like a types team FCP, because it's a tweak to the inference rules. TL;DR right now we say If there is some trait obligation , then we take the args from it seems reasonable to say If there is some trait obligation that implies (through the "invariants", in terms) , then we take the args from that would fix this example (types team FCP would be required). However, I believe that beyond this specific example, most people who wind up here are trying to do something a bit more sophisticated, such as having an argument that might be a closure but might not, or have extended varieties of closures (). It is possible that just making the above change would fix those problems, but it's likely that further changes would be required. Those scope feels like a lang-team initiative. Still may be worth making this change just to screen out the easy cases, mind you!
Change:
#![feature(generators, generator_trait, untagged_unions)] #![feature(move_ref_pattern)] <ins> #![feature(bindings_after_at)] </ins> #![allow(unused_assignments)] #![allow(unused_variables)]

Discussion:
The feature which allows for patterns, is implemented in The PR doesn't have as good coverage of the dynamic semantics as we might like. Once the PR lands, we should try to improve things before we stabilize the feature. Notable tests to include: [x] Dynamic drop () cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is now unblocked as has landed.
I would like to work on this one
Go for it :) assign
Now that has landed, I think we can close this once also lands.
Change:
argc, argv, ) <ins> .into_ok() </ins> }

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:
<ins> // Caused an infinite loop during SimlifyCfg MIR transform previously. // // build-pass fn main() { loop { continue; } } </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. --repo @ Rustc simply hangs when running Edit: while rustc is crunching on the hang:
cc ? edit: I assume this is due to
O_o yea, I'll have a look
Wild speculation: might have the same cause (EDIT: Backtrace says yes)
Change:
} .docblock li { <del> margin-bottom: .8em; </del> <ins> margin-bottom: .4em; </ins> } <del> .docblock li p { margin-bottom: .1em; </del> <ins> .docblock li p:not(:last-child) { /* This margin is voluntarily smaller than `.docblock li` to keep the visual list element items separated while also having a visual separation (although smaller) for paragraphs. */ margin-bottom: .3em; </ins> } /* "where ..." clauses with block display are also smaller */

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I ran the following commands: <details<summaryOn 2024-10-01, this renders like this</summary! </details<details<summaryOn 2024-10-02, this renders like this</summary! </detailsNote that the bullet points are spaced farther apart. I'm assuming this is a regression?
I think this is a consequence of which was intended to address . GG is adding a UI regression test for the spacing in for . cc
It's indeed something that we changed on purpose.
Little modification: the changes are improving the situation but introducing some new other issues. Talking about it currently to figure out what's the best solution.
I opened Please don't hesitate to take a look. Hopefully I was able to improve the current situation without going back to the original issue.
Certainly seems better than before!
Change:
} else { &maybe_sysroot }; <del> let libdir = sysroot.join(libdir(&compiler.host)); </del> <ins> let libdir = self.rustc_libdir(compiler); </ins> // Customize the compiler we're running. Specify the compiler to cargo // as our shim and then pass it some various options used to configure

Discussion:
To reproduce, make sure you have an entirely clean checkout -- I did . Then run This will go on for a while and ultimately fail with Notably, it doesn't seem to build LLVM at all -- which may be why it can't find a codegen-backend...
Turns out that works fine. However, stage 0 tests with doctests still seem pretty much broken. Can these even reasonably work without having a "bootstrap rustdoc"?
Cc
Note that it fails in stage 1 as well -- both of these fail:
Change:
<del> //@ known-bug: #130413 #![feature(transmutability)] trait Aaa { type Y; } trait Bbb { type B: std::mem::TransmuteFrom<()>; } impl<T> Bbb for T where T: Aaa, { type B = T::Y; } </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'not implemented: NormalizationFailure(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. }), Type(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. })))'', 'thread 'rustc' panicked at 'not implemented: NormalizationFailure(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. }), Type(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. })))'' 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: [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2024-08-22 seems to bisect to
Slightly more reduction:
(Note that this reduction should drop the feature gate, as this ICEs without the feature gate)
claim
Change:
<ins> // Copyright 2014 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. enum Foo { Bar } fn main() { Foo::Bar.a; //~^ ERROR: attempted access of field `a` on type `Foo`, but no field with that name was found } </ins>

Discussion:
Slightly smaller example:
Running with code block code block I can't reproduce the ICE. Can this be closed?
Tests in .
Should be closed now,
Change:
}; if let Some(stmt) = stmt { stmts.push(stmt); <del> } else if self.token == token::Eof { break; </del> } else { // Found only `;` or `}`. continue;

Discussion:
I tried this code: first outputs some error messages and then hangs up trying to allocate a large amount of memory. :
modify labels: regression-from-stable-to-nightly
Error: Label regression-from-stable-to-nightly can only be set by Rust team members Please let know if you're having trouble with this bot.
Rust 1.34.0 and before is OK:
triage: P-medium. Removing nomination. Assigning to self and for initial investigation.
I'm seeing the same behavior on the following programs: and These were found with the help of .
Another program that I also observe to make run out of memory:
The original report is caused due to growing unbounded in a bad parser code path, in part due to it being a and not a (which it can't be at the moment). Now that I have a clue at what causes the behavior, I'll dig deeper for the trigger.
Change:
sp, "disambiguate the associated function", format!( <del> "{}::{}({}{})", trait_name, segment.ident.name, self_adjusted, args </del> <ins> "{}::{}{}({}{})", trait_name, segment.ident.name, if let Some(args) = segment.args.as_ref().and_then(|args| self .sess() .source_map() .span_to_snippet(args.span_ext) .ok()) { // Keep turbofish. format!("::{}", args) } else { String::new() }, self_adjusted, args, </ins> ), Applicability::MachineApplicable, );

Discussion:
Given the following code: The lint provides two suggestions, both of which fail with different errors. The first: fails with "type annotations needed" because the generics in the path are lost. The second: fails with "the trait bound is not satisfied". Ideally I think the suggestions should be: Found in the 2021 crate run migrating https://crater-
Looks like the turbofishes are swimming away! grabs turbofish food