jiebi/CodeConvo huggingface dataset:
Change:
/// but shebang isn't a part of rust syntax. pub fn strip_shebang(input: &str) -> Option<usize> { // Shebang must start with `#!` literally, without any preceding whitespace. <del> if input.starts_with("#!") { let input_tail = &input[2..]; // Shebang must have something non-whitespace after `#!` on the first line. let first_line_tail = input_tail.lines().next()?; if first_line_tail.contains(|c| !is_whitespace(c)) { // Ok, this is a shebang but if the next non-whitespace token is `[` or maybe // a doc comment (due to `TokenKind::(Line,Block)Comment` ambiguity at lexer level), // then it may be valid Rust code, so consider it Rust code. let next_non_whitespace_token = tokenize(input_tail).map(|tok| tok.kind).find(|tok| !matches!(tok, TokenKind::Whitespace | TokenKind::LineComment | TokenKind::BlockComment { .. }) ); if next_non_whitespace_token != Some(TokenKind::OpenBracket) { // No other choice than to consider this a shebang. return Some(2 + first_line_tail.len()); } </del> <ins> // For simplicity we consider any line starting with `#!` a shebang, // regardless of restrictions put on shebangs by specific platforms. if let Some(input_tail) = input.strip_prefix("#!") { // Ok, this is a shebang but if the next non-whitespace token is `[` or maybe // a doc comment (due to `TokenKind::(Line,Block)Comment` ambiguity at lexer level), // then it may be valid Rust code, so consider it Rust code. let next_non_whitespace_token = tokenize(input_tail).map(|tok| tok.kind).find(|tok| !matches!(tok, TokenKind::Whitespace | TokenKind::LineComment | TokenKind::BlockComment { .. }) ); if next_non_whitespace_token != Some(TokenKind::OpenBracket) { // No other choice than to consider this a shebang. return Some(2 + input_tail.lines().next().unwrap_or_default().len()); </ins> } } None

Discussion:
We fail to parse this (admittedly questionable) code as of beta: This broke one repository (not crate) in the beta crater run: https://crater-
cc I personally suspect that we may want to ask T-lang if we're good accepting this as expected breakage. Alternatively I guess we can adjust the shebang detection to not require a non-empty shebang.
Assigning .
For reference, here's the code responsible for parsing shebang in Linux kernel - (Fully whitespace (including empty) line isn't considered a shebang.)
I am inclined to close as won't fix; let's cc as the author of that repository as well. I'm going to go ahead and nominate this so that we can get a :+1: (or not) at the T-compiler meeting confirming won't fix status.
I made a fix in , which also has a benefit of simplifying the rules slightly.
Thanks guys, was more of a spelling mistake/leftover from previous version than unclear explanation of how to use shebang with rust as your previous explanation on how to use it worked fine in something else I was playing around with. But thank you very much for letting me know. Sent with Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Change:
LL |     for ( elem in vec ) { |                ^^ expected one of `)`, `,`, `@`, or `|` <del> error: unexpected closing `)` --> $DIR/recover-for-loop-parens-around-head.rs:10:23 </del> <ins> error: unexpected parenthesis surrounding `for` loop head --> $DIR/recover-for-loop-parens-around-head.rs:10:9 </ins> | LL |     for ( elem in vec ) { <del> |         --------------^ |         | |         opening `(` |         help: remove parenthesis in `for` loop: `elem in vec` </del> <ins> |         ^             ^ | help: remove parenthesis in `for` loop | LL -     for ( elem in vec ) { LL +     for  elem in vec  { | </ins> error[E0308]: mismatched types --> $DIR/recover-for-loop-parens-around-head.rs:13:38

Discussion:
Roughly according to cc
Some notes: I think this is not worth fixing as it would require hacks deep in the general sequence parser. We should try to still have suggestions; notes that there are special purpose methods for doing that. "Unnecessary" is semantically misleading here as this is a hard error, not a lint.
Change:
sm.span_extend_while(seg1.ident.span.shrink_to_hi(), |c| c == ':').unwrap(), "you may have meant to call an instance method", ".".to_string(), <del> Applicability::MaybeIncorrect </del> <ins> Applicability::MaybeIncorrect, </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. --This is new, introduced between (older) and (newer) src/tools/miri/tests/pass- <!-- 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
prioritize
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
where T: Relate<'tcx>, { <del> self.fields.higher_ranked_sub(a, b, self.a_is_expected)?; self.fields.higher_ranked_sub(b, a, self.a_is_expected) </del> <ins> if a.skip_binder().has_escaping_bound_vars() || b.skip_binder().has_escaping_bound_vars() { self.fields.higher_ranked_sub(a, b, self.a_is_expected)?; self.fields.higher_ranked_sub(b, a, self.a_is_expected) } else { // Fast path for the common case. self.relate(a.skip_binder(), b.skip_binder())?; return Ok(a.clone()); } </ins> } }

Discussion:
The following takes approximately one year to compile: (This estimate was derived from observing that compile time scales seemingly exponentially in the depth of the instantiated closure. At level 23 it took about 25 seconds, and at 22 only 13. Extrapolating this doubling-per-depth leads us to about a year at level 43 which is depicted above).
Flamegraph:
Yields: cc
Change:
}) .collect(); } <del> StmtKind::Expr(ref e) => { hir::Stmt { hir_id: self.lower_node_id(s.id), node: hir::StmtKind::Expr(P(self.lower_expr(e))), span: s.span, } }, StmtKind::Semi(ref e) => { hir::Stmt { hir_id: self.lower_node_id(s.id), node: hir::StmtKind::Semi(P(self.lower_expr(e))), span: s.span, } }, </del> <ins> StmtKind::Expr(ref e) => hir::StmtKind::Expr(P(self.lower_expr(e))), StmtKind::Semi(ref e) => hir::StmtKind::Semi(P(self.lower_expr(e))), </ins> StmtKind::Mac(..) => panic!("Shouldn't exist here"), <ins> }; smallvec![hir::Stmt { hir_id: self.lower_node_id(s.id), node, span: s.span, </ins> }] }

Discussion:
See:
for future reference: is referencing my PR which changed the r-value temporary rules with respect to the temporaries in the of
Even beside the part the loop desugaring is so complex. It would be nice to document what every employed trick changes compared to the naive desugaring.
PR itself was motivated (or at least spawned off of) PR . I'm actually trying to find out what the actual motivation for the described change was. The change, as described, was that the temporaries within would previously live until the end of the enclosing block. So if you consider the following code (): which, when it is accepted by the compiler (as written it requires NLL), it should print this: notably, we drop all of {, , } immediately after the for-statement, but before the at the end of the block. The breakage I would be concerned about, if we made for-loops no longer a terminating scope for their , is that all of the temps would live until the end of the block, and thus the drops of {, , } would happen after the "end of enclosing block", which would be an observable change. has relayed to me in private conversation that they tried examples like this under variants of their desugaring and did not witness any change in behavior. Our best guess as to why this is, is because the desugaring is, in the end, turning into a which is itself a terminating scope for the temporaries in the -input, and so you don't need to recreate such an effect by other means.
Note: it is nonetheless possible that the distinction here is more subtle and my above example isn't quite right. in particular, I'm a little worried that there may have been a reason that the example from PR puts the for-expression in the tail expression of a block, and that examples that don't take similar care might fail to pick up on a relevant distinction here...
Change:
<ins> // aux-build:intra-link-cross-crate-crate.rs // build-aux-docs #![crate_name = "outer"] extern crate inner; // @has outer/fn.f.html '//a[@href="../inner/fn.g.html"]' "crate::g" pub use inner::f; </ins>

Discussion:
Crate exports from . is documented in quit and has no documentation in quitmacros. When that documentation has a link to , which is only in crate quit, it is unresolved. However, is resolved. Rustdoc gives no warnings with either. You can see the result with quit version 1.1.1 . cc cc
<details<summaryAll of this was wrong, I forgot to use +nightly</summaryThis isn't related to scopes, rustdoc will also fail to resolve these links: Something about the re-export itself is messing it up. </details
The good news is this is unrelated to proc-macros. Here's what I found: This is really strange. I would have expected it to resolve relative to , not relative to the current crate.
Ok, I found the issue: rustdoc and resolve disagree about which crate this is in For , rustdoc passes the original module of String, , and resolve correctly says there's no item named . But for , resolve thinks that refers to the current crate, not to alloc. This explains a lot of other broken links I've been seeing actually: anything that has will be wrong. So you were actually correct to start that this was the same issue as ;) The fix will be a little tricky ... there's no 'change ' button for resolve. There are a few things rustdoc can do: all links relative to the current module (the status quo before ). This is a no-go, because it means links will break on re-exports (). all links relative to the original module. This is what I thought was the current behavior. It means that additional documentation can't refer to things in the current lexical scope, which is non-intuitive (cc ). links in lexical scope: the original docs get resolved in the original module; the new docs get resolved in the module with the re-export. This is the ideal fix but somewhat hard to do because rustdoc doesn't distinguish between the two internally. A possible way to implement 2. is by stripping wherever we see it and resolving relative to the crate root instead of the current module. This is slightly_ hacky but should work fairly reliably.
Marking as P-high after discussing with ; it would be unfortunate to still have this bug on the first release after stabilization.
Change:
<ins> trait Hello { fn example(&self, input: &i32); // should suggest here } struct Test1(i32); impl Hello for Test1 { fn example(&self, input: &i32) { // should not suggest here *input = self.0; //~ ERROR cannot assign } } struct Test2(i32); impl Hello for Test2 { fn example(&self, input: &i32) { // should not suggest here self.0 += *input; //~ ERROR cannot assign } } fn main() { } </ins>

Discussion:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///
Change:
clippy_info: channel::GitInfo, miri_info: channel::GitInfo, rustfmt_info: channel::GitInfo, <ins> in_tree_llvm_info: channel::GitInfo, emscripten_llvm_info: channel::GitInfo, </ins> local_rebuild: bool, fail_fast: bool, doc_tests: DocTests,

Discussion:
Which means that programs that run from a build script, or from cargo in some other way, fail. Steps to Reproduce: a clang binary pointing to clang-8 installed and in your path. install nightly clone && cd $ test Actual results: /usr/bin/clang: relocation error: symbol ZTIN4llvm14FoldingSetBaseE version LLVM8 not defined in file libLLVM-8.so with link time reference Expected results: not so This only happens if ran from cargo, if I run the test executable manually then stuff works, so I suspect this is some LDLIBRARYPATH mungling that cargo or rustup do under the hood. This is technically a regression from , same problem does not exist with rust stable / beta and clang 7. There's a slight chance that there's an issue on how clang-8 is built in Fedora, so I also filed , but I think it's unexpected that clang when called from cargo / build scripts uses rust's , and probably should be avoided. cc
Is invoked from a build script? It is possible that cargo neglects removing the unnecessary or similar environment variables before invoking the script in question. EDIT: oh you wrote that in the report already. I remember there being an issue like this in cargo repo from a long long time ago, but cannot find it now.
cc
See also . We should probably set a custom suffix per . Maybe even include the Rust version to help avoid bootstrap issues like what commit saw. (cc
Yep, I think a suffix of rust version (or maybe LLVM submodule commit?) would be good. I think we'd appreciate a PR for something like that; I would expect it to be a matter of making the version suffix default be or something along those lines.
Sure, that sounds good, I can give that a shot.
I sent with a change that I hope will address this, but see there why I cannot confirm it will :)
triage: P-high, assigning to
Change:
fn visit_statement(&mut self, statement: &Statement<'tcx>, location: Location) { trace!("visit_statement: statement={:?} location={:?}", statement, location); <del> match statement.kind { StatementKind::Assign(..) | StatementKind::SetDiscriminant { .. } => { self.super_statement(statement, location); } </del> <ins> self.super_statement(statement, location); match statement.kind { </ins> StatementKind::LlvmInlineAsm { .. } => { <del> self.super_statement(statement, location); </del> self.check_op(ops::InlineAsm); } <del> StatementKind::FakeRead(..) </del> <ins> StatementKind::Assign(..) | StatementKind::SetDiscriminant { .. } | StatementKind::FakeRead(..) </ins> | StatementKind::StorageLive(_) | StatementKind::StorageDead(_) | StatementKind::Retag { .. }

Discussion:
The code below compiles as of 1.46, but I'm not sure it should, since it dereferences a raw pointer in a const block, which is only allowed in nightly with the flag:
modify labels to +A-raw-pointers +A-const-fn
cc
Ah, that looks like the const version of the old "uninhabited match" problem... The MIR for is So somehow the deref already vanished, and hence the const analysis cannot catch it. But doesn't unsafety checking also happen on the MIR? Why does that work?
It seems that whenever the dereference is not bound to a variable, it compiles, but whenever bound to a variable, it fails to compile:
I don't believe this is an unsoundness. Unsafe code is required to cause anything here. That's the final MIR, since without this will fail to compile, it must be there for unsafety checking, thus it must also be there for const checking. Not sure why we fail to catch this.
Agreed. This is a case of "oops a nightly-only feature is available on stable", which is bad, but it is not an unsoundness.
Assigning and removing as in the prioritization working group.
The initial MIR looks like this: So probably the issue is that const-checking ignores ?
oh... yea.. we ignored it on purpose... "because it doesn't actually do anything" :upsidedownface: I guess we should visit all places within statements that we otherwise ignore during const-checking?
Well, at least we need to visit . ;)
Do we really? The check is done in , which should be called even for the projection in the place in the fake read.
Oh wait, we don't call unconditionally! That seems like... a problem.^^
Proposed a fix:
Change:
} fn is_internal_abi(&self, abi: SpecAbi) -> bool { <del> matches!(abi, SpecAbi::Rust | SpecAbi::RustCall | SpecAbi::RustIntrinsic) </del> <ins> matches!( abi, SpecAbi::Rust | SpecAbi::RustCall | SpecAbi::RustCold | SpecAbi::RustIntrinsic ) </ins> } /// Find any fn-ptr types with external ABIs in `ty`.

Discussion:
() Like and the other ABIs, should not trigger and for non-FFI-safe types. Related: , ; tracking issue . No response No response_
Change:
fn compare_source(&self, expected: &str, actual: &str) { if expected != actual { <del> self.error("pretty-printed source does not match expected source"); println!( "n </del> <ins> self.fatal(&format!( "pretty-printed source does not match expected sourcen </ins> expected:n ------------------------------------------n {}n

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:
// "function" here means "anything callable" rather than `DefKind::Fn`, // this is not precise but usually more helpful than just "value". Some(ExprKind::Call(call_expr, _)) => match &call_expr.kind { <ins> // the case of `::some_crate()` ExprKind::Path(_, path) if path.segments.len() == 2 && path.segments[0].ident.name == kw::PathRoot => { "external crate" } </ins> ExprKind::Path(_, path) => { let mut msg = "function"; if let Some(segment) = path.segments.iter().last() {

Discussion:
Test program: This produces the following error messages: Both the error and the help seem entirely unhelpful. The error suggests that it looked for a function in the crate root, but in fact it looked for a crate . The whole "possible candidate" help seems incorrect, and adding that line would lead to a compilation failure.
cc
This is still an issue, but at least the incorrect help message is no longer displayed:
Change:
(&ty::Infer(ty::TyVar(vid)), _) => self.relate_ty_var((vid, b)), (&ty::Opaque(a_def_id, _), &ty::Opaque(b_def_id, _)) if a_def_id == b_def_id => { <del> infcx.commit_if_ok(|_| infcx.super_combine_tys(self, a, b)).or_else(|err| { </del> <ins> infcx.super_combine_tys(self, a, b).or_else(|err| { </ins> self.tcx().sess.delay_span_bug( self.delegate.span(), "failure to relate an opaque to itself should result in an error later on",

Discussion:
Valid according to stable (1.64.0), but ICEs beta (1.65.0-beta.4) and : Reduced from a mutation of Two ICEs: <details<summary<strongFull output with both backtraces</strong</summary<p</p</details: Bisected with <a href=''cargo-bisect-rustc</aon x8664-apple-darwin: searched nightlies: from nightly-2022-08-23 to nightly-2022-10-26 regressed nightly: nightly-2022-08-31 searched commit range: regressed commit: (rollup) Among the commits in the rollup, my guess is (CC It the function (frame 19 on the first stack). It with some similarities: an unconditionally recursive function with in return position. label +regression-from-stable-to-beta +A-impl-trait
yup, ez fix incoming
Change:
import tarfile import tempfile <del> from time import time </del> <ins> from time import time, sleep </ins> # Acquire a lock on the build directory to make sure that # we don't cause a race condition while building

Discussion:
Since I started using vscode, it is now often the case that the which vscode runs is still not done when I alt-tab back to my terminal to do (for example) . That regularly leads to errors like this: In those cases, just running again solves the problem -- but it would still be better if having vscode run in background would not break what I do in the terminal. Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
So there's several solutions to this: Don't support this, tell people to run x.py check in a different directory so the build directory goes elsewhere. Add a global lock like Cargo's on the build directory Specialize x.py check to use different sysroot for stage0 - i.e. don't fix x.py build and test running simultaneously etc I am interested in hearing which you think would be preferable. Cc
If they could run truly in parallel that would be great. However, a separate build dir also means the bootstrap rustc is downloaded again, right? That would not be great.
Yes, option 1 would duplicate the stage0 rustc downloads. Option 3, though, would not - it's probably the right choice I think since x.py check is somewhat unique in being the most likely to be invoked in parallel.
in an ideal world, would fixing also fix this?
Not really. It might even make things worse. rustbuild uses the same stamps for both check and build steps (and sysroots etc) so when both are running simultaneously we will stomp all over the other, which is going to lead to incorrect behavior.
I was not able to replicate this. On my machine running both in parallel gives
Ok, I figured out when this happens: you need one terminal to be building the compiler while the other is building libstd. If both are building libstd this error doesn't show up.
I think this can also lead to losing the build cache... at least I just had a case where after showing this error, it then (on the next attempt) proceeded to rebuild the crate graph rustc depends on, instead of just the crate that I changed.

FYI option 3 was seen as too big a hammer in ; the proposed fix was to use a build lock on the sysroot instead, the same way cargo has a build lock for .
I think that's not quite accurate, in the specialization was too specific (i.e., the problem is more widespread, any two x.py runs can touch shared files currently). "Insufficiently big hammer" is probably the right description of option 3.
claim
I am afraid this is still not working properly: when I run in the terminal while there is a vscode running in the background, I get but once vscode is done, all that happens is that the in the terminal starts using 100% CPU. It does not actually start running though.
Ah: looks like it missed actually breaking out of that loop -- happy to accept a PR to do so.
is that something you could take a look at?
Change:
} pub unsafe fn make_handler() -> Handler { <ins> if !NEED_ALTSTACK { return Handler::null(); } </ins> let mut stack = mem::zeroed(); sigaltstack(ptr::null(), &mut stack); // Configure alternate signal stack, if one is not already set.

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: and compiled it with: I expected to see asan report a bad pointer use and give a backtrace. Instead I just got a raw sigsegv: Running with verbose output shows that AddressSanitizer is intercepting the signal. It looks like is also installing a signal handler, which is overriding the AddressSanitizer one. <!-- 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. --: </p</details
(set handler and prevent override) is a workaround, but I think the Rust runtime shouldn't stomp SIGSEGV in the sanitizer case.
cc