jiebi/CodeConvo huggingface dataset:
Change:
|     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = help: use `crate::empty_helper` to refer to this attribute macro unambiguously <del> error[E0659]: `empty_helper` is ambiguous (derive helper attribute vs any other name) --> $DIR/derive-helper-shadowing.rs:22:7 | LL |     #[empty_helper] |       ^^^^^^^^^^^^ ambiguous name | note: `empty_helper` could refer to the derive helper attribute defined here --> $DIR/derive-helper-shadowing.rs:20:10 | LL | #[derive(Empty)] |          ^^^^^ note: `empty_helper` could also refer to the attribute macro imported here --> $DIR/derive-helper-shadowing.rs:10:5 | LL | use test_macros::empty_attr as empty_helper; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = help: use `crate::empty_helper` to refer to this attribute macro unambiguously error[E0659]: `empty_helper` is ambiguous (derive helper attribute vs any other name) --> $DIR/derive-helper-shadowing.rs:26:11 | LL |         #[empty_helper] |           ^^^^^^^^^^^^ ambiguous name | note: `empty_helper` could refer to the derive helper attribute defined here --> $DIR/derive-helper-shadowing.rs:20:10 | LL | #[derive(Empty)] |          ^^^^^ note: `empty_helper` could also refer to the attribute macro imported here --> $DIR/derive-helper-shadowing.rs:10:5 | LL | use test_macros::empty_attr as empty_helper; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = help: use `crate::empty_helper` to refer to this attribute macro unambiguously error: aborting due to 7 previous errors </del> <ins> error: aborting due to 5 previous errors </ins> For more information about this error, try `rustc --explain E0659`.

Discussion:
So pointed out to me that some recent changes in name resolution seem to have broken . They pointed me at dealing with the fallout -- maybe you can leave a few notes as to what errors you were seeing before this commit? cc -- could this be the recent changes around name resolution of helper attributes in macros? It seems the relevant code is stuff like:
(Nominated for discussion around the breakage policy/implications here.)
Duplicate of , I'll prepare a fix.
fix Or rather a "tiebreaker" for the ambiguity, since both names are indeed in scope and create ambiguity, which is correctly detected after .
Fixed in

This is a dependency of . I was trying to compile ; it failed on both the master branch and the current published version. is ambiguous (derive helper attribute vs any other name) Indeed, the code does seem to treat as simultaneously a derive macro and an attribute macro. It works fine on stable.
Example of failing builds:
modify labels: +E-needs-bisection It'd be nice if somebody pinpointed specific PR (or nightly at least). Maybe has a clue what could have caused it.
Seems to be introduced at nightly-2019-11-17. Unfortunately I'm not able to bisect that further because cargo-bisect-rustc is telling me:
Likely
This is a consequence of , I'll provide a ASAP.
Fixed in
Change:
<ins> error[E0637]: `&` without an explicit lifetime name cannot be used here --> $DIR/issue-109071.rs:8:17 | LL |     type Item = &[T]; |                 ^ explicit lifetime name needed here error[E0107]: missing generics for struct `Windows` --> $DIR/issue-109071.rs:7:9 | LL | impl<T> Windows { |         ^^^^^^^ expected 1 generic argument | note: struct defined here, with 1 generic parameter: `T` --> $DIR/issue-109071.rs:5:8 | LL | struct Windows<T> {} |        ^^^^^^^ - help: add missing generic argument | LL | impl<T> Windows<T> { |                +++ error[E0658]: inherent associated types are unstable --> $DIR/issue-109071.rs:8:5 | LL |     type Item = &[T]; |     ^^^^^^^^^^^^^^^^^ | = note: see issue #8995 <https://github.com/rust-lang/rust/issues/8995> for more information = help: add `#![feature(inherent_associated_types)]` to the crate attributes to enable error: aborting due to 3 previous errors Some errors have detailed explanations: E0107, E0637, E0658. For more information about an error, try `rustc --explain E0107`. </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
Minimized with : label +S-bug-has-mcve
searched toolchains through Regression in
Alternative: Would the error change if the compiler is built with ?
Triage: This is no longer ICE since today's nightly, I assume fixed it. Marking as E-needs-test just in case regression tests there didn't cover this case. labels: +E-needs-test
Change:
<ins> error: `&'static [u32]` is forbidden as the type of a const generic parameter --> $DIR/issue-73727-static-reference-array-const-param.rs:9:15 | LL | fn a<const X: &'static [u32]>() {} |               ^^^^^^^^^^^^^^ | = note: the only supported types are integers, `bool` and `char` = help: more complex types are supported with `#![feature(adt_const_params)]` error: aborting due to previous error </ins>

Discussion:
<!-- 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
This works with because the type is forbidden. However, it continues to ICE with .
No longer ICEs since
Change:
<ins> error: expected identifier, found keyword `break` --> $DIR/raw-name-use-suggestion.rs:3:12 | LL |     pub fn break() {} |            ^^^^^ expected identifier, found keyword | help: you can escape reserved keywords to use them as identifiers | LL |     pub fn r#break() {} |            ^^^^^^^ error: expected identifier, found keyword `let` --> $DIR/raw-name-use-suggestion.rs:7:10 | LL |     foo::let(); |          ^^^ expected identifier, found keyword | help: you can escape reserved keywords to use them as identifiers | LL |     foo::r#let(); |          ^^^^^ error[E0425]: cannot find function `break` in this scope --> $DIR/raw-name-use-suggestion.rs:8:5 | LL |     r#break(); |     ^^^^^^^ not found in this scope | help: possible candidate is found in another module, you can import it into scope | LL | use foo::r#break; | error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0425`. </ins>

Discussion:
Right now the raw ident suggestion when using a reserved keyword somewhere where it is not allowed is context free, leading to misleading output: The parser should perform some lookahead to see if it could actually continue parsing if a raw identifier had been supplied in its place and if so, only then suggest raw idents.
Or we shouldn't suggest using raw identifiers if we cannot do that easily and reliably.
Change:
//! assert_eq!(Duration::new(5, 0), Duration::from_secs(5)); //! ``` <del> use fmt; </del> <ins> use {fmt, u64}; </ins> use iter::Sum; use ops::{Add, Sub, Mul, Div, AddAssign, SubAssign, MulAssign, DivAssign};

Discussion:
Attempting to compile this: will give this error: I was thinking that a clearer error could be something along the lines of: and give this hint:
This should be straightforward to add a help message for. This error message is emitted here: The immediately afterwards is responsible for giving suggestions relevant to the particular type. You'd need to add a new case for () and emit an appropriate message (there are examples for other types in the expression), if the field is numeric. If anyone'd like to tackle this, just post a reply here — I can give more details as needed (but it's always useful to try working things out yourself first, to get a feel for where to find things).
I don't have any experience with Rustc's codebase, but I would be willing to give it a try.
great! If you need any help, you can post a comment here, or ask on or #rustc. Once you add the help message, you'll need to add a test for it (there are plenty of examples in — you can run to test and produce the output).

Do you have some more info? Is this something users experience? Or is it mostly custom drivers running into problems?
When implementing myself I accidentally tried to parse a different file type. This returned an error from , but the error was never printed to the user, instead it said ...`.
It's possible if an rlib/dylib gets corrupt, because then it won't say the file is corrupt. Yes
Change:
let ExprUseVisitor { ref mc, body_owner: _, delegate: _ } = *self; let mut needs_to_be_read = false; for pat in pats { <del> return_if_err!(mc.cat_pattern(discr_place.clone(), pat, |place, pat| { </del> <ins> mc.cat_pattern(discr_place.clone(), pat, |place, pat| { </ins> match &pat.kind { PatKind::Binding(.., opt_sub_pat) => { // If the opt_sub_pat is None, than the binding does not count as

Discussion:
<details</summary</details<!-- 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. --:
I will try to reduce this to an MCVE.
Changing to appears to avoid the ICE, so that may be a useful place to focus.
Minimized it down to 60 lines without any dependencies. Maybe it can be minimized further but it's getting really hard. I've also left a few comments to say what's going on. <details<summary"Minimized" </summary</details
This appears to have regressed in Rust 1.64
This continues to ICE on beta and nightly
I bisected the regression, here is the output of : searched nightlies: from nightly-2022-06-24 to nightly-2022-08-05 regressed nightly: nightly-2022-07-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
Out of these seems the most likely, cc
Zooming onto changeset.
Found MVCE: <details<summaryOutput from Rust Playground</summary</details
Change:
mir, ty::{self, FloatTy, Ty}, }; <del> use rustc_target::abi::Integer; </del> <ins> use rustc_target::abi::{Integer, Size}; </ins> use crate::*; use atomic::EvalContextExt as _;

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

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

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

as per a FIXME.
Ok, so, the strings "globalenv" and "getglobalenvchan" don't appear in the source anymore, so I'm going to close this bug...
Change:
<ins> error[E0004]: non-exhaustive patterns: type `bool` is non-empty --> $DIR/drop-tracking-error-body.rs:6:11 | LL |     match true {} |           ^^^^ | = note: the matched value is of type `bool` help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern as shown | LL ~     match true { LL +         _ => todo!(), LL ~     } | error: aborting due to previous error For more information about this error, try `rustc --explain E0004`. </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
regression in cc
Hmm, I guess that before this function just received broken MIR and carried on, but exited due to the HIR errors without trying to dump it. Now that we return an error body for broken code we're getting a panic
Change:
<del> Subproject commit 42263494d29febc26d3c1ebdaa7b63677573ec47 </del> <ins> Subproject commit d404cba4e39df595710869988ded7cbe1104b52f </ins>

Discussion:
() never finishes building the crate (0.11.3) when building with optimizations. Regression is exactly in the LLVM 17 upgrade: <details<summaryBacktrace</summary<p</p</details modify labels: +regression-from-stable-to-nightly -regression-untriaged
WG-prioritization assigning priority (). is it clear by looking at he stacktrace what kind of code is involved that causes the issue? I'm thinking if a smaller reproducible can help. label -I-prioritize +P-high
Can reproduce also with (to skip installing the asm dependency)
Problematic IR: Based on output, it looks like we go into an infinite loop unswitching loop.
Here is a test case for :
I've filed This appears to be related to the new invariant condition injection.
Change:
<ins> // check-pass use std::error::Error as StdError; use std::pin::Pin; use std::task::{Context, Poll}; pub trait Stream { type Item; fn poll_next(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Option<Self::Item>>; fn size_hint(&self) -> (usize, Option<usize>) { (0, None) } } pub trait TryStream: Stream { type Ok; type Error; fn try_poll_next( self: Pin<&mut Self>, cx: &mut Context<'_>, ) -> Poll<Option<Result<Self::Ok, Self::Error>>>; } impl<S, T, E> TryStream for S where S: ?Sized + Stream<Item = Result<T, E>>, { type Ok = T; type Error = E; fn try_poll_next( self: Pin<&mut Self>, cx: &mut Context<'_>, ) -> Poll<Option<Result<Self::Ok, Self::Error>>> { self.poll_next(cx) } } pub trait ServerSentEvent: Sized + Send + Sync + 'static {} impl<T: Send + Sync + 'static> ServerSentEvent for T {} struct SseKeepAlive<S> { event_stream: S, } struct SseComment<T>(T); impl<S> Stream for SseKeepAlive<S> where S: TryStream + Send + 'static, S::Ok: ServerSentEvent, S::Error: StdError + Send + Sync + 'static, { type Item = Result<SseComment<&'static str>, ()>; fn poll_next(self: Pin<&mut Self>, _cx: &mut Context) -> Poll<Option<Self::Item>> { unimplemented!() } } pub fn keep<S>( event_stream: S, ) -> impl TryStream<Ok = impl ServerSentEvent + Send + 'static, Error = ()> + Send + 'static where S: TryStream + Send + 'static, S::Ok: ServerSentEvent + Send, S::Error: StdError + Send + Sync + 'static, { SseKeepAlive { event_stream } } fn main() {} </ins>

Discussion:
Trying to build  0.2.5 with latest nightly results in an ICE. Bisected the regression to , cc I have tried to minimize it. This still requires 0.3, I'm not sure how to minimize if further. <!-- 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
Seems like a duplicate of
I don't think that is related, neither the error matches nor is it a recent regression. Did you link the wrong issue? fixes this ICE
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Still needs a backport
(assigning self to ensure backport happens.)
Also seen in the latest (): zebra-consensus: https://crater- warp v0.3.1: https://crater- linkerd: https://crater- Along with a number of others.
Backport () was merged.
Change:
builder.ensure(crate::core::build_steps::llvm::Lld { target }); let src_bindir = builder.llvm_out(target).join("bin"); <del> // If updating this list, you likely want to change </del> <ins> // If updating this, you likely want to change </ins> // src/bootstrap/download-ci-llvm-stamp as well, otherwise local users // will not pick up the extra file until LLVM gets bumped. <del> for bin in &[ "llvm-config", "llvm-ar", "llvm-objdump", "llvm-profdata", "llvm-bcanalyzer", "llvm-cov", "llvm-dwp", "llvm-nm", "llvm-dwarfdump", "llvm-dis", "llvm-tblgen", ] { tarball.add_file(src_bindir.join(exe(bin, target)), "bin", 0o755); </del> <ins> // We should include all the build artifacts obtained from a source build, // so that you can use the downloadable LLVM as if you’ve just run a full source build. if src_bindir.exists() { for entry in walkdir::WalkDir::new(&src_bindir) { let entry = t!(entry); if entry.file_type().is_file() && !entry.path_is_symlink() { let name = entry.file_name().to_str().unwrap(); tarball.add_file(src_bindir.join(name), "bin", 0o755); } } </ins> } // We don't build LLD on some platforms, so only add it if it exists

Discussion:
The profile is intended not just for people working on LLVM itself, but also anyone who touches codegen but not LLVM. For example, anyone who modifies or is only changing the IR we send to LLVM, not LLVM itself. We should keep on for them but not for , but ideally we wouldn't build LLVM from source if it's unmodified. points out some things that we should fix before enabling that option by default for the profile: Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Should all 3 tasks be in one PR or is it 3 separate PR's?
I'd say it depends how challenging they are - if it's simple to fix all three in one PR that seems fine, but if it takes a more than a day to do one of the tasks, it probably makes sense to open a PR for it early.
I think I can tackle points 1 and 3 by tonight so I'll make that into one PR. I'll open a separate PR for the second point, since I think it has more work involved, if that's alright :)
release-assignment
Change:
<del> Subproject commit 07e0df2f006e59d171c6bf3cafa9d61dbeb520d8 </del> <ins> Subproject commit c954202c1e1720cba5628f99543cc01188c7d6fc </ins>

Discussion:
Results in a crash (after a perfectly reasonable error message): This was tested with rustc 0.1. Building from HEAD on nyus now to try to get a more helpful backtrace and to verify that it hasn't since been fixed.
Here's a more helpful backtrace. Repros at .
Looks exactly like to me.

On the pull request for (), had a good suggestion for what I think would make a good additional function: "a version of frombytes which doesn't fail on invalid input but rather offers some sort of error recovery options. Like maybe it can return the partly converted string with an index to the invalid position. Or perhaps, a callback function to handle the error, etc." At a glance the easy way to do this would be with a callback to, e.g., drop, replace, or coerce offending sequences into UTF-8 or else return a ... But is this a recipe for complex callbacks? Perhaps providing sensible callback functions like , , , and so on would make this simple enough to use. Maybe those should just be simple functions for whole byte vector conversion, anyways. What do you think?
I don't have a strong opinion about it, but I guess I would prefer to wait until somebody actually needs something like this.
Not RFC-level proposal. Just a library wishlist item. Might accept a patch; but it seems a bit overwrought. Anyone need such a thing yet?
I think this is subsumed in ; we might well adopt a dynamic-handler mechanism while working through that bug. This would be a special case.
Change:
rustc_lexer::TokenKind::Caret => token::BinOp(token::Caret), rustc_lexer::TokenKind::Percent => token::BinOp(token::Percent), <del> rustc_lexer::TokenKind::Unknown | rustc_lexer::TokenKind::InvalidIdent => { </del> <ins> rustc_lexer::TokenKind::Unknown | rustc_lexer::TokenKind::InvalidIdent | rustc_lexer::TokenKind::InvalidPrefix => { </ins> // Don't emit diagnostics for sequences of the same invalid token if swallow_next_invalid > 0 { swallow_next_invalid -= 1;

Discussion:
In the 2015 and 2018 editions, the following compiles (with warnings): ` [playground] The is taken as an identifier, although emoji aren't generally permitted in identifiers in any edition. I tested with 1.77.1. I think the underlying problem is that and in distinguish "identifiers" containing emoji (as rather than ), but don't have a way to make that distinction for . [playground]:
Regression from 1.57 to 1.58 (stable to stable). Very likely in , cc Regression from error to pass. Previous error: .
WG-prioritization assigning priority (). label -I-prioritize +P-low
thank you for the detailed report. will fix this.
Change:
.optflag("", "nocapture", "") .optflag("h", "help", "show this message") .reqopt("", "channel", "current Rust channel", "CHANNEL") <ins> .optflag("", "git-hash", "run tests which rely on commit version being compiled into the binaries") </ins> .optopt("", "edition", "default Rust edition", "EDITION"); let (argv0, args_) = args.split_first().unwrap();

Discussion:
stable is fine: but beta and nightly are no longer showing commit-hash and commit-date information: ` <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
it's weird because the info is still displayed correctly in the very first oneliner-summary, but if there was some tool that reads the data by looking at or we still should display the right thing.
This appears to have been introduced by . The issue is that the macro uses CFGVERDATE/CFGVERHASH which is only set when compiling rustc. One option is to try to share some code with . Another option is to go the other way and get rustc to share some code with .
Mentoring instructions: set in (Maybe we should try to unify those functions so they don't duplicate so much code and problems like this don't happen in the future?)
I think it should be possible to write a run-make test ensuring this works properly.
claim
Hi im starting my journey of contributing to Rust, i found this issue a good starter for myself, do you think you would be open to let me take this chance to get familiar with the code base?
Hey! Go for it!
Alternatively, you could check out . I THINK that might be more straightforward. But I'll let you decide(:
claim
I tried doing this change in Then i did a and tried running this command on the stage2 rustodc But it appears that the commit-hash and commit-date is still unknown. Im wondering if the issue is that is passed as true in This is my first time making changes and testing in this project, please feel free to correct me if im testing / building in the wrong way.
I'd suggest changing to use instead of so it's easier to tell when these variables are unset without having to build a full stage 2 compiler.
Retagging as stable/stable regression, this already shipped in 1.67 as far as I can tell.
Are you still (interested in) working on this issue? I'd like to claim it otherwise.
please go ahead and claim it!
claim