jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: expected expression, found keyword `struct` --> $DIR/issue-34421-mac-expr-bad-stmt-good-add-semi.rs:3:9 | LL |         struct $a; |         ^^^^^^ expected expression ... LL |     make_item!(A) |     ------------- in this macro invocation | = note: the macro call doesn't expand to an expression, but it can expand to a statement = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) help: add `;` to interpret the expansion as a statement | LL |     make_item!(A); |                  ^ error: expected expression, found keyword `struct` --> $DIR/issue-34421-mac-expr-bad-stmt-good-add-semi.rs:3:9 | LL |         struct $a; |         ^^^^^^ expected expression ... LL |     make_item!(B) |     ------------- in this macro invocation | = note: the macro call doesn't expand to an expression, but it can expand to a statement = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) help: add `;` to interpret the expansion as a statement | LL |     make_item!(B); |                  ^ error: aborting due to 2 previous errors </ins>

Discussion:
This is a regression from stable to beta and nightly. This code is wrong (missing semicolons): Stable prints: Beta and nightly both print: Notice that not only is all the useful information gone, but the compiler aborts after the first error instead of finding the rest. It does not matter whether is on or off. cc
cc me
So this fell through the cracks, and was a stable to nightly/beta regression. It still is a regression, in a way, but only of diagnostics. Could you take a look?
Nominating for prioritization.
So this part of the (previous) stable message: feels like a bug to me anyhow. This part: is sort of good. It'd be nice to preserve a backtrace, at least. And ideally we'd suggest adding a .
Given how much time has past, we're going to call this P-medium for now. However, will try to write up some mentoring instructions (or maybe fix it). He has a plan. =) triage: P-medium
I think the best path forward here is to try parsing an expression macro expansion as a statement before emitting an error. If the macro expansion parses as a statement successfully, we can emit a more helpful error suggesting that the user add a semicolon to the macro invocation.
I'm interested in this but I need informations to understand what to do :)
Current output:
Diagnostics meeting triage: lowering priority as the current error is pretty good, even if not ideal yet.
Current output: (Notice that we recover -- it's not a fatal error now.)
Change:
Wrapping(self.0.wrapping_shr((other & self::shift_max::$t as $f) as u32)) } } <ins> forward_ref_binop! { impl Shr, shr for Wrapping<$t>, $f, #[stable(feature = "wrapping_ref_ops", since = "1.39.0")] } </ins> #[stable(feature = "op_assign_traits", since = "1.8.0")] impl ShrAssign<$f> for Wrapping<$t> {

Discussion:
The other day I noticed that only implements and co. for , which contradicts that without the shift amount can be any type. So, I think it may be useful to create tests which use macros to shove together all the types we expect to have impls for and check that we're consistent there. What I've noticed: For every operation three extra impls are , with the combinations of single-level references on both sides, e.g. , , for . Assignment ops do the same as the above, with only one extra impl, e.g. for . , , , , exist for all int and float types with themselves , , exist for all int types and bool and allow any integer type for both the left and the right side exists for all ints and floats exists for all ints and bool should mimic all of the above, where references are of the form and not . Like, I wouldn't be surprised if rearranging some macros might add or remove impls for these and adding comprehensive tests might help make sure we covered everything. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seems like a simple but useful task, I will try to finish it.
I am reformulating the task to make sure it is clear (to myself at least) : Create tests using a set of macros to check that every numerical instances of for the following operations are implemented for every combination of numerical instances (, , ...) : with : * having the integer and float types with themselves, ¤ having the integer and bool types with themselves, having the integer and float types with themselves, and Am I correct ? How does this relate to ?(e.g. is it possible to bypass the bug and still implement the test ? I could not see from the issue if a solution had been found)
claim isn't implemented for and /. So this is probably only useful for integer types.
This doesn't actually fix the issue; it should be tested for all types, not just .
Hi ! Are you or anyone else working on adding the missed tests?
They're free for anyone to implement right now!
Nope, not right now. Feel free to take over.

It should be pretty similar to , just add the missing types (bool, fp) and operators (bit wise operators).
Thank you very much and , I'll send a PR.
unassign
claim I'll try to get a PR in by next weekend, If nothing happens past that I'm afraid I may have been too busy so [anyone] feel free to overtake :smile:
claim
Hi, are you still working on this issue
I'm sorry, I couldn't do it. Please feel free to reassign this.
No worries release-assignment
Change:
<del> Subproject commit 2c4de6c2492d5530de3f19f41d8f88ba984c2fe2 </del> <ins> Subproject commit 606bc11367b475542bd6228163424ca43b4dbdbc </ins>

Discussion:
You get an error like this: I didn't investigate it further. It never worked in the past and I assumed it's due to the old mingw version on CI, but it still doesn't work after and the actual error doesn't look like it's caused by a toolchain version.
It happens only with LLD but i haven't investigated. At MSYS2 we had to remove M68k to maskę it build with LLD but since 1.67 we no longer got this issue:
cc do either of you know what LLD is doing differently compared to LD? is this something rustc controls? It would help to have a minimization smaller than "all of rustc and llvm" ...
I don't know the answer to any of those questions but this issue stopped happening at MSYS2 so it could have been some LLVM 16 change (MSYS2 uses LLVM 15 but backports important patches from LLVM 16) that fixed this problem there.
Looks like we're currently using LLVM 15: label +S-blocked
Yup, I plan to try once is merged.
This is still an issue with LLVM 17.0.5.
There's an ODR violation in M68k's , its base class doesn't have a virtual method while for all other targets including PPC do. So it's not a linker's problem, actually complains about this too, it just reports it as a warning instead of an error. The simplest fix is to rename the structure (instead of adding virtual methods). I wish I tried to debug this a few years eariler.
Could someone submit this to LLVM? I'm not familiar with their processes. cc
You can simply open pull request to Otherwise I can do it this or next weekend.
Opened a pull request with the fix -
Fixed in
Change:
fn_metadata: fn_metadata, argument_counter: Cell::new(1), source_locations_enabled: Cell::new(false), <ins> source_location_override: Cell::new(false), </ins> };

Discussion:
Rust version: OS: Gentoo Linux AMD64
cc
The same thing happens with openssl-sys 0.4.1:
For anyone running into this, you can disable debug info to work around the issue until it's fixed:
Same problem here. Rust version: rustc 1.0.0-nightly ( 2015-02-17) (built 2015-02-18) Operating System: OS X Yosemite 10.10.2
It looks like I have the same problem: Compiling mio v0.2.1 () Running 1:1 error: internal compiler error: debuginfo: Could not find scope info for node NodeExpr(Expr { id: 5326, node: ExprStruct(Path { span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() }, global: false, segments: [PathSegment { identifier: StaticMutex, parameters: AngleBracketedParameters(AngleBracketedParameterData { lifetimes: [], types: [], bindings: [] }) }] }, [Field { ident: Spanned { node: lock, span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }, expr: Expr { id: 5327, node: ExprPath(Path { span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() }, global: false, segments: [PathSegment { identifier: sys, parameters: AngleBracketedParameters(AngleBracketedParameterData { lifetimes: [], types: [], bindings: [] }) }, PathSegment { identifier: MUTEXINIT, parameters: AngleBracketedParameters(AngleBracketedParameterData { lifetimes: [], types: [], bindings: [] }) }] }), span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }, span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }, Field { ident: Spanned { node: poison, span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }, expr: Expr { id: 5328, node: ExprPath(Path { span: Span { lo: BytePos(0),

hi: BytePos(0), expnid: ExpnId() }, global: false, segments: [PathSegment { identifier: poison, parameters: AngleBracketedParameters(AngleBracketedParameterData { lifetimes: [], types: [], bindings: [] }) }, PathSegment { identifier: FLAGINIT, parameters: AngleBracketedParameters(AngleBracketedParameterData { lifetimes: [], types: [], bindings: [] }) }] }), span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }, span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }], None), span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }) #![allow(noncamelcasetypes, nonuppercaseglobals, nonsnakecase)] ^ Rust version: rustc 1.0.0-nightly ( 2015-02-17) (built 2015-02-18) OS: 3.13.0-24-generic -Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x8664 x8664 x86_64 GNU/Linux
A minimized version:
Minimized a bit further actually, perhaps you could publish a version which uses instead of on the vector of ?
Er, nevermind, I have against rust-openssl to temporarily fix this.
I encountered a similar problem with constants in match patterns. This very probably has the same root cause, which is that the AST of constants gets substituted for the constant-reference during trans, but then we suddenly have a bunch of unrelated AST node ids in there. I'll try to fix this this week.
My minimal case:
Change:
<ins> #![stable(feature = "foo", since = "1.33.0")] #![feature(staged_api)] #![feature(const_compare_raw_pointers)] #![feature(const_fn)] #[stable(feature = "foo", since = "1.33.0")] #[rustc_const_unstable(feature = "const_foo", issue = "none")] const fn unstable(a: *const i32, b: *const i32) -> bool { a == b //~^ pointer operation is unsafe } fn main() {} </ins>

Discussion:
Some operations, such as raw pointer comparisons, require when inside a const context. To my knowledge, none of these operations have been const-stabilized. Accordingly, the fails to compile due to a missing unsafe block. However, the check does not run for functions. The following : This is an easy problem to fix, but the root cause here is poor naming. Specifically, should be renamed and should be . We have had other issues due to this in the past. cc to weigh in on the renaming.
Yeah I recall being confused by those names in the past, too. Definite :+1: for changing them. As for concrete proposals, I don't actually remember what these queries are doing, but your suggestions sound reasonable. :)
Oh, the names are different than in the email I got because you edited.^^ So does take the context (feature flags etc) into account? The name sounds like it would. What about , to make it a bit shorter?
Damn. I was hoping no one would catch me :smile:. would indeed take feature flags into account to mirror the current behavior of . I originally had , but that's not really correct, since it would also return if the function was unstable but the requisite feature flags were set.
Change:
use rustc::hir::def_id::{DefId, CrateNum, LOCAL_CRATE, INVALID_CRATE, CRATE_DEF_INDEX}; use rustc::session::config; use rustc::ty::TyCtxt; <ins> use rustc_allocator::ALLOCATOR_METHODS; </ins> use syntax::attr; /// The SymbolExportLevel of a symbols specifies from which kinds of crates

Discussion:
Since bumped the bootstrap compiler, stage0 libstd fails to build when jemalloc is disabled: I believe it needs to restore the logic removed here: I tried to add this to : Then stage0 passed, but stage1 std failed like:
cc
We should probably add a builder for this...
or just get on with evicting jemalloc...
is not the right way to fix this - I that so I could build rust with a local rust that does not have jemalloc i.e. unless the following two conditions are true: you're using a local rust (as opposed to the automatic stage0 download) and your local rust does not have jemalloc (you compiled the whole thing yourself with ) it's irrelevant. Edit: to be clear, by "not the right way to fix this" I mean "it worked fine before I that flag, so its removal is probably not the root cause". That's doesn't exclude the possibility that we could perform some incantations with this flag and fix the issue. Edit2: sorry, I thought you were exclusively referring to rather than all the logic. I read and thought this issue was about the same thing.
Generally, the two conditions you list are actually true for me. I build Fedora's rustc without jemalloc, and I use that as the local stage0 to build the next release. And i think the force flag does come into play too, because if we need to rebuild the current release then the local rust gets treated as a stage1. But right now it's more direct. I am using the downloaded stage0, which wants to default to jemalloc. Since I'm disabling that for my build, stage0 can't find it.
Interesting, I kinda figured I was the only one! Rereading , I see I'm wrong about my two conditions above - it actually applies when trying to build something without jemalloc, from something that defaults to it. Anyway, it should all be fixed soonish...
Change:
<del> Subproject commit daa2a05ebe7b8d07a309e8891ebc548652362954 </del> <ins> Subproject commit 655a137a8bd0dda1cc71fb82661446e215563d6f </ins>

Discussion:
The nightly builds are currrently failing as the cargo install as part of the nightly want to unconditionally place stuff in : the log file above says:
As a side-question: Is it not feasible to use a pre-built Rust (e.g. installed through ) for Compiler Explorer, instead of installing it from source?
- I'm not installing via source here (I don't think?). I'm running and then manaully patching the to let me run the binaries directly by path. CE installs to a shared NFS drive that all the various instances all mount. If can be made to install somewhere "shared" like this, I can move to it. Importantly I need to be able to execute the full path to the rust compiler ( or similar) without any per-compiler environment variables being required.
Sorry, I misunderstood. Interesting. I'm not really knowledgeable on rustup and environments like this. Perhaps or could answer this. <sAlthough... Now that I think about it, I think rustup just invokes when installing a toolchain, so this would be broken with rustup too.</s
Probably related to in .
rustup doesn't use (it supports windows) you can use and to control where the toolchains and rustup proxies are installed respectively. I'm not sure if this will solve your use-case?
Or more precisely, rust-lang/rust-installer defines . I understand why that's not under the prefix (like ), but it seems surprising that it doesn't at least respect . cc
Actually, I think it should use by default, then let users choose if they're sure they want it installed globally. just puts these files in .
When using x.py it respects DESTDIR just like all the others (libdir, bindir, etc). Is there a way to reproduce?
$ wget $ tar xf cargo-nightly-x8664-unknown-linux- $ ./cargo-nightly-x8664-unknown-linux- --prefix=./usr install: creating uninstall script at install: installing component 'cargo' install: backing up existing file at /etc/bashcompletion.d/cargo mv: cannot move '/etc/bashcompletion.d/cargo' to '': Permission denied install: error: failed to back up /etc/bash_completion.d/cargo. see logs at ''
I think it should just be like this to be prefixed by default: (i.e.

don't assume that we really want the global by default)
See It seems pretty standard not to respect prefix for sysconfdir, but not respecting DESTDIR was indeed a mistake
Change:
See the specification for the [task list extension] for more details. <ins> ### Smart punctuation Some ASCII punctuation sequences will be automatically turned into fancy Unicode characters: | ASCII sequence | Unicode | |----------------|---------| | `--`           | –       | | `---`          | —       | | `...`          | …       | | `"`            | “ or ”, depending on context | | `'`            | ‘ or ’, depending on context | So, no need to manually enter those Unicode characters! </ins> [`backtrace`]: https://docs.rs/backtrace/0.3.50/backtrace/ [commonmark markdown specification]: https://commonmark.org/ [commonmark quick reference]: https://commonmark.org/help/

Discussion:
Split off from . modify labels: T-rustdoc C-enhancement <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Uh, it looks like rustbot is editing my message and adding weird comments:
Cc
It looks like smart punctuation doesn't work in headers: ! wasn't able to reproduce this in pulldown itself; I'm guessing rustdoc is doing something special with headers. Cc
Triagebot does that as a way of easily storing data per-issue (we could do it in the database now, we didn't have one back then). But it's expected and shouldn't really be a problem.
Is this a good thing? Wouldn't keeping things as it is is better?
I think if you want to argue against doing this, giving reasons would be helpful. I personally think given that we already use emoji and otherwise non-ASCII characters readily, it should be reasonable for us to generate smart quotes as well.
I do think emoji and other non-ASCII characters if specified would be good except for smart quote. It's like saying to use greek question mark which is the same as semi-colon when a semi-colon was seen in documentation to make it look a bit cooler. One thing is copying, when others are copying the text, it will copy the utf-8 version of smart quotes which when displayed in terminals which in turn will make it look ugly and hard for text processing. Auto changing text to emoji I am okay with that. But not automatically changing single quotes, double quotes and semi-colons. Personally I don't see much benefit to that, usually if users want it they would specifically type it out but otherwise it would be similar. In my humble opinion, looks wise the smart quotes are more ugly, but easier to distinguish opening and closing quotes, but still when copied and pasted it may not look so good.
Change:
let item_ = ast::ItemMod(testmod); let mod_ident = token::gensym_ident("__test"); <ins> let allow_unstable = { let unstable = P(nospan(ast::MetaWord(InternedString::new("unstable")))); let allow = P(nospan(ast::MetaList(InternedString::new("allow"), vec![unstable]))); attr::mk_attr_inner(attr::mk_attr_id(), allow) }; </ins> let item = ast::Item { ident: mod_ident, <del> attrs: Vec::new(), </del> id: ast::DUMMY_NODE_ID, node: item_, vis: ast::Public, span: DUMMY_SP, <ins> attrs: vec![allow_unstable], </ins> }; let reexport = cx.reexport_test_harness_main.as_ref().map(|s| { // building `use <ident> = __test::main`

Discussion:
With a file like: And then running , these warnings are inserted: cc
I believe was working on this.
Nominating though, when we deny warnings in beta I've gotta be able to test my code still!
I've been using , and this blocks me from testing. For now, I have to comment out that line...
Change:
lo.line != hi.line } <del> pub fn span_to_lines(&self, sp: Span) -> FileLinesResult { debug!("span_to_lines(sp={:?})", sp); </del> <ins> pub fn is_valid_span(&self, sp: Span) -> Result<(Loc, Loc), SpanLinesError> { </ins> let lo = self.lookup_char_pos(sp.lo()); debug!("span_to_lines: lo={:?}", lo); let hi = self.lookup_char_pos(sp.hi()); debug!("span_to_lines: hi={:?}", hi); if lo.file.start_pos != hi.file.start_pos { return Err(SpanLinesError::DistinctSources(DistinctSources { begin: (lo.file.name.clone(), lo.file.start_pos), end: (hi.file.name.clone(), hi.file.start_pos), })); } <ins> Ok((lo, hi)) } pub fn span_to_lines(&self, sp: Span) -> FileLinesResult { debug!("span_to_lines(sp={:?})", sp); let (lo, hi) = self.is_valid_span(sp)?; </ins> assert!(hi.line >= lo.line); let mut lines = Vec::with_capacity(hi.line - lo.line + 1);

Discussion:
(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.
Change:
)) .unwrap(); <del> let mut current = None; </del> let mut all_targets = HashSet::new(); let mut all_archs = HashSet::new(); let mut all_oses = HashSet::new();

Discussion:
Prior to , compiletest would take into account when determining whether a test target can unwind. It did so by calling , which changes the reported panic strategy depending on the flags: After the PR, compiletest calls which always reports the default panic strategy for the target (even if are passed): This causes a problem for us because we run the compiler test suite against a toolchain built with . Compiletest will run tests marked with even though they panic (and thus fail). I see a few options for fixing this issue: Have respect any additional flags passed. Parse specifically for and modify the return value of to take it into account. Add some new configuration flags to compiletest to control panic strategy for the selected target. cc who authored the original PR
This seems like the best solution to me.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Agree with jyn here on the solution. Unfortunately I won't have much time myself in the coming weeks to address this :(
Change:
use rustc_ast::ast; use rustc_ast::util::lev_distance::find_best_match_for_name; use rustc_data_structures::fx::FxHashMap; <ins> use rustc_data_structures::stack::ensure_sufficient_stack; </ins> use rustc_errors::ErrorReported; use rustc_errors::{pluralize, struct_span_err, Applicability, DiagnosticBuilder, DiagnosticId}; use rustc_hir as hir;

Discussion:
First reported to me at I believe the stack overflow is in rustc itself. when compiled yields: where nightly today is:
Assigning as and removing .
It would be nice to bisect this one if possible ... ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched nightlies: from nightly-2020-05-05 to nightly-2020-07-22 regressed nightly: nightly-2020-05-08 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
cc for anyone wanting to fix this, these kind of bugs are very easy to fix. You run rustc in until you get a stack overflow, then you look at the backtrace and look for recursion in there. Then you break the recursion overflow by inserting a use of at the recursive call site.
That sounds a good first bug to me. I'll give it a shot.