jiebi/CodeConvo huggingface dataset:
Change:
p.expect(&token::OpenDelim(token::DelimToken::Paren))?; while !p.eat(&token::CloseDelim(token::DelimToken::Paren)) { <del> if p.eat(&token::Ident(sym::pure, false)) { </del> <ins> if p.eat_keyword(sym::pure) { </ins> try_set_option(p, args, sym::pure, ast::InlineAsmOptions::PURE); <del> } else if p.eat(&token::Ident(sym::nomem, false)) { </del> <ins> } else if p.eat_keyword(sym::nomem) { </ins> try_set_option(p, args, sym::nomem, ast::InlineAsmOptions::NOMEM); <del> } else if p.eat(&token::Ident(sym::readonly, false)) { </del> <ins> } else if p.eat_keyword(sym::readonly) { </ins> try_set_option(p, args, sym::readonly, ast::InlineAsmOptions::READONLY); <del> } else if p.eat(&token::Ident(sym::preserves_flags, false)) { </del> <ins> } else if p.eat_keyword(sym::preserves_flags) { </ins> try_set_option(p, args, sym::preserves_flags, ast::InlineAsmOptions::PRESERVES_FLAGS); <del> } else if p.eat(&token::Ident(sym::noreturn, false)) { </del> <ins> } else if p.eat_keyword(sym::noreturn) { </ins> try_set_option(p, args, sym::noreturn, ast::InlineAsmOptions::NORETURN); <del> } else if p.eat(&token::Ident(sym::nostack, false)) { </del> <ins> } else if p.eat_keyword(sym::nostack) { </ins> try_set_option(p, args, sym::nostack, ast::InlineAsmOptions::NOSTACK); <del> } else { p.expect(&token::Ident(sym::att_syntax, false))?; </del> <ins> } else if p.eat_keyword(sym::att_syntax) { </ins> try_set_option(p, args, sym::att_syntax, ast::InlineAsmOptions::ATT_SYNTAX); <ins> } else { return p.unexpected(); </ins> } // Allow trailing commas

Discussion:
The : pointed me to -- cc I see that there were regressions with during that review, but not exactly like what I'm seeing here. searched nightlies: from nightly-2020-09-28 to nightly-2020-10-04 regressed nightly: nightly-2020-09-30 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
It's probably relevant that the actual token is passed as an arch-conditional parameter here:
Yes, I've missed this case, sorry. Will fix soon.
Fixed in
Works for me, thanks!
Change:
} } <ins> #[stable(feature = "from_ref_string", since = "1.35.0")] impl From<&String> for String { #[inline] fn from(s: &String) -> String { s.clone() } } </ins> // note: test pulls in libstd, which causes errors here #[cfg(not(test))] #[stable(feature = "string_from_box", since = "1.18.0")]

Discussion:
If a function takes it would be nice to pass it a (say, from pattern matching) without additional friction. implements this.
that could hide unnecessary clone
This is functionally identical to the existing impl. The clone would be necessary - if the receiving function needs to own the , and all you have is a , then someone has to do a clone. If it didn't need to own it then it could take (or ). And if you had a to pass in, then it would hit the no-op blanket impl.
Do you have an example why this is useful? coerces to so there is no need to implement this (also )
coerces to No it doesn't, but it to it. The specific case I had was: Currently the nicest way to handle this is , since there's a .
Okay, that's true. But you will have the same issue with , and . What about that?
To quote me:
Change:
tcx.sess.delay_span_bug( DUMMY_SP, &format!( <del> "unexpected const parent path def, parent: {:?}, def: {:?}", parent_node, res </del> <ins> "unexpected anon const res {:?} in path: {:?}", res, path, </ins> ), ); return tcx.types.err;

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
managed to reduce the test case a bit.
Also happens for this code using a function instead of an associated type:
claim
initial example fixed by , associated function fixed by instead
Change:
} } } <ins> Position::ArgumentImplicitlyIs(_) if self.is_diagnostic_namespace_variant => { String::from("{}") } Position::ArgumentIs(idx) if self.is_diagnostic_namespace_variant => { format!("{{{idx}}}") } </ins> _ => bug!("broken on_unimplemented {:?} - bad format arg", self.symbol), }, }) <del> .collect() </del> <ins> .collect(); // we cannot return errors from processing the format string as hard error here // as the diagnostic namespace gurantees that malformed input cannot cause an error // // if we encounter any error while processing the format string // we don't want to show the potentially half assembled formated string, // therefore we fall back to just showing the input string in this case // // The actual parser errors are emitted earlier // as lint warnings in OnUnimplementedFormatString::verify if self.is_diagnostic_namespace_variant && !parser.errors.is_empty() { String::from(s) } else { constructed_message } </ins> } }

Discussion:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?
Change:
hir::Stmt { span, node, hir_id: self.next_id() } } <ins> fn stmt_expr(&mut self, span: Span, expr: hir::Expr) -> hir::Stmt { self.stmt(span, hir::StmtKind::Expr(P(expr))) } </ins> fn stmt_let_pat( &mut self, attrs: ThinVec<Attribute>,

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:
} #[cold] #[inline(never)] <del> pub fn fail_str(msg: &str, file: &(&'static str, uint)) -> ! { format_args!(|fmt| fail_fmt(fmt, file), "{}", msg) } #[cold] #[inline(never)] </del> pub fn fail_fmt(fmt: &fmt::Arguments, file_line: &(&'static str, uint)) -> ! { #[allow(ctypes)] extern {

Discussion:
These appear all the time and result in large code bloat. At least the file and line should be combined into a static.
Also, and result in inefficient codegen and code bloat because they call into the string formatter when they don't need to.
This seems to be done for . The macro in still uses the string formatter for all invocations, but I don't even know how to use those.
Change:
use libc; use flate; <ins> use std::mem; </ins> pub fn run(sess: &session::Session, llmod: ModuleRef, tm: TargetMachineRef, reachable: &[String]) { if sess.opts.cg.prefer_dynamic {

Discussion:
There's another bug in LLDB that causes it to segfault when reading archive files. This one has already been fixed in May () but it still exists in a lot of LLDB binaries out there. As far as I can tell, the bug occurs when a number of object files are stored in an archive and the last one ends at an uneven byte offset. This often seems to be the case for compressed byte-code archives in rlibs (maybe regular object files are always padded to an even size?). I'm currently compiling a possible workaround (pad the bytecode objects to an even size). It would be good if we could allow for rust code to be debugged with older LLDB versions too.
Update: Padding all archives entries to an even size seems to prevent the crash in LLDB and I have not seen any detrimental side effects to this approach so far. Any idea if the additional padding byte at the end of the compressed LLVM IR object in an archive could potentially lead to a problem?
I'm not familiar enough with the format of object files or bytecode files to know whether an extra byte or two at the end would corrupt them, but if it's working ok currently then I'd just ship it!
I doubt that the containing archive will care about the padding byte, but either the decompression algorithm or the LLVM bitcode reader could trip over it. The safe way to do this would probably be to prepend the actual size of the compressed data, so we always know how much data to pass to . I guess, I'll implement this and make a pull request.
Thinking about it, changing the format here is not as so trivial since the compiler must handle libs with the old format differently from libs with the new format. I see two options: (1) Just add the padding byte and hope for the best (2) Introduce some kind of header (including a version byte) before the compressed bitcode, in order to future-proof this against other changes to the encoding. I think I'd favor option (2).
Is this only a problem for the bytecode in archives, or is it also a problem for object files?
So far it has only occurred for bytecode. All object files I came across had a size dividable by 2. I don't know if that's a coincidence...
Interesting!

I'm all for putting the bytecode in whatever format we want (it's already just a huge deflated stream)
I'll come up with something and then we can discuss the matter further when we have some code to look at in a PR, OK?
Sounds good to me!
Change:
<ins> error[E0412]: cannot find type `n` in this scope --> $DIR/issue-90871.rs:2:8 | LL |     2: n([u8; || 1]) |        ^ expecting a type here because of type ascription error[E0308]: mismatched types --> $DIR/issue-90871.rs:2:15 | LL |     2: n([u8; || 1]) |               ^^^^ expected `usize`, found closure | = note: expected type `usize` found closure `[closure@$DIR/issue-90871.rs:2:15: 2:17]` help: use parentheses to call this closure | LL |     2: n([u8; (|| 1)()]) |               +    +++ error: aborting due to 2 previous errors Some errors have detailed explanations: E0308, E0412. For more information about an error, try `rustc --explain E0308`. </ins>

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting the error "cannot find type in this scope", so low priority. Affected versions: I tried nightly 2021-11-12 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</details
Regressed since , cc
Assigning as and removing .
Another input with a slightly different error message: <details<summary<strongBacktrace</strong</summary<p</p</details
searched nightlies: from nightly-2021-01-07 to nightly-2021-12-24 regressed nightly: nightly-2021-07-26 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This regressed in . cc
No longer ICEs since
Change:
<ins> //! ICE test #124348 //! We should not be running const eval if the layout has errors. enum Eek { TheConst, UnusedByTheConst(Sum), //~^ ERROR cannot find type `Sum` in this scope } const EEK_ZERO: &[Eek] = &[]; fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: interpret const eval failure of Unevaluated(UnevaluatedConst { def: DefId(0:11 ~ ice[ec8e]::EEKZERO), args: [], promoted: Some(promoted[0]) }, &'{erased} [Eek; 0usize]) which is not in requiredconsts', 'error: internal compiler error: interpret const eval failure of Unevaluated(UnevaluatedConst { def: DefId(0:11 ~ ice[ec8e]::EEKZERO), args: [], promoted: Some(promoted[0]) }, &'{erased} [Eek; 0usize]) which is not in requiredconsts' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: 6 | const EEKZERO: &[Eek] = &[]; [evaltoallocationraw] const-evaluating + checking [evaltoconstvalueraw] simplifying constant for the type system [analysis] running analysis passes on this crate --
cc
Caused by running the interpreter on code that doesn't even pass name resolution. Not sure where to fix this, but probably not in the interpreter.^^ Cc
this is a promoted failing to compile because it gets the layout of this broken type, which gives us back an . I'm certain we can prevent const eval from running by checking such layouts earlier in the MIR pipeline, but the fix isn't clear to me yet.
The issue is that in the sanity check we only know it's an , we don't know whether it was a typeck error on a const-eval error. So we can't really distinguish these cases. If this is a , we could probably fix it by tweaking the error handling . But there probably are similar cases where a promoted fails to evaluate due to a SizeOverflow and then we have to report the error somewhere.

The only option I see right now is to add another variant to (or a flag in ) to track whether this was a failure inside the constant itself or a failure in something the constant referenced. But this distinction isn't always very clear anyway... it would basically have to be "is this an error that can occur even for supposedly infallible operations like ", i.e., match exactly the usecase of the const-eval / promoted sanity check. Which is not great.
We already got the flag that we can reuse for that
Change:
if (e) { e.preventDefault(); } const query = parseQuery(searchState.input.value.trim()); let filterCrates = getFilterCrates();

Discussion:
Reproduction: Go to Click the gear next to the search field, enable "Directly go to item in search if there is only one result" Refresh page to ensure it's enabled (was required the first time I tried to reproduce, but seemed to work straight away the second time) Search for You should be taken straight to Press "Back" in your browser I expected this to happen: Go back to Instead, this happened: Goes back to then instantly redirects forward again
Taking a look.
Fixed in
Change:
cache(decoder, pos, id); Ok(id) }, <ins> EXTERN_STATIC_DISCRIMINANT => { trace!("creating extern static alloc id at {}", pos); let did = DefId::decode(decoder)?; let alloc_id = tcx.interpret_interner.reserve(); tcx.interpret_interner.cache(did, alloc_id); Ok(alloc_id) }, </ins> shorthand => { trace!("loading shorthand {}", shorthand); short(decoder, shorthand)

Discussion:
fresh clone of using local Rust and Cargo latest nightly (also occurs in beta-1.25.0), MSVC x64 with Visual Studio 2017 In : set and to Rustup's proxies set (happens only in debug mode) set (specific value doesn't appear to affect the issue) run It gets to this point and ICEs: I grepped the error message () and it points to which appears to be associated with incremental compilation, which makes sense because this only triggers when building in debug mode and setting avoids the ICE. cc rust-lang/cargo
There's a very high chance that this is fixed by
I'll try to build the latest master and see what happens.
Nope, just changed the file the error is emitted from. I have the backtrace here if you like but it's more than 100 frames deep so I don't know how much context you need.
Thanks. I'll have a look. No need for a backtrace
Repro: The problem is that statics don't have allocations (because it makes no sense for them to have usable memory during const evaluation). This is easy to fix :)
Change:
<ins> // build-pass // Verify that the compiler doesn't ICE during const prop while evaluating the index operation. #![allow(unconditional_panic)] fn main() { let cols = [0u32; 0]; cols[0]; } </ins>

Discussion:
Here's the crashing code I came down to: An empty contains a single line: "pub mod " a file with the following code: This happened as I permuted type and size in my array definition. My intention was not to declare a zero sized array but to declare an array filled with zeros. Anyway, the compiler crashed. I noticed that if I remove the from the line in , it compiles fine. Backtrace:
cc
cc did the value visitor changes get merged?
is still waiting for review if that's the one you mean.
The ICE seems to be , though. So likely just needs a test (or checking that we already have an appropriate test)?
Maybe we should also find the PR that fixed this and beta nominate?
points to as being responsible for fixing this.
That PR is too big to backport. I suggest to just remove the assertion on beta as the ICE is properly fixed on master
Still need to backport
The fix is already on beta so backport is unneeded?
Yeah, playground confirms that this ICEs on stable but works fine on beta and nightly.
Change:
} pub fn get_lint_groups<'t>(&'t self) -> Vec<(&'static str, Vec<LintId>, bool)> { <del> self.lint_groups.iter().map(|(k, &(ref v, b))| (*k, v.clone(), b)).collect() </del> <ins> self.lint_groups.iter().map(|(k, v)| (*k, v.ref0().clone(), *v.ref1())).collect() </ins> } pub fn register_pass(&mut self, sess: Option<&Session>,

Discussion:
The recent attempts to improve hashmap seem to have exposed a bug in regionck where it fails to link the lifetimes of ref bindings in some situations. A mostly minimized test case is here: This test fails to compile but (I believe) should succeed. The problem is that the lifetime of the binding inside the callback from is not "linked" (in regionck terminology) to the lifetime , and hence region inference infers a lifetime for that is too small. It was not immediately obvious what the best way is to fix this -- the code around handling ref bindings seems a bit ... off in regionck, so I need to think about it some. Perturbing the code in various ways can workaround the issue, which is bad for making minimized test cases but good for landing the hasmap patch in the meantime!
I've run into (I think) another manifestation of this issue that forces the destructuring of a reference to a tuple from the arguments to the closure body: This works, but this does not
I think this is the original problem, updated to current syntax: error: Actually, maybe this should be using something other than Box... ugh old closures.
If you use a boxed closure, remember to box it: This runs on modern rustc.
Ah duh. Thanks!
Change:
//!     * `o` - precedes the argument with a "0o" //! * '0' - This is used to indicate for integer formats that the padding should //!         both be done with a `0` character as well as be sign-aware. A format <del> //!         like `{:08d}` would yield `00000001` for the integer `1`, while the </del> <ins> //!         like `{:08}` would yield `00000001` for the integer `1`, while the </ins> //!         same format would yield `-0000001` for the integer `-1`. Notice that //!         the negative version has one fewer zero than the positive version. //!

Discussion:
See e.g. It seems what instead of , is required. E.g. () produces
I tried to search already reported issue, no luck. If it's something really worthy, I might try to come up with PR to fix it.
So, does it qualify for a proper PR? I'm new in Rust ecosystem and I thought it could be a good way to both contribute back and start small, e.g. understand how the whole process works ... ;) Edit s/smart/small/
yes, absolutely! If you have the time, that'd be great.
You can check out for full details, but basically, just make a pull request :)
Great, will do it some time during this week.
fixed the issue seems to be updated, closing this one.
Change:
<ins> // Because of #109628, when we compute the implied bounds from `Foo<X>`, // we incorrectly get `X: placeholder('x)`. // Make sure we ignore these bogus bounds and not use them for anything useful. // // revisions: fail pass // [fail] check-fail // [pass] check-pass trait Trait { type Ty<'a> where Self: 'a; } impl<T> Trait for T { type Ty<'a> = () where Self: 'a; } struct Foo<T: Trait>(T) where for<'x> T::Ty<'x>: Sized; trait AnotherTrait { type Ty2<'a>: 'a; } #[cfg(fail)] mod fail { use super::*; // implied_bound: `'lt: placeholder('x)`. // don't use the bound to prove `'lt: 'static`. fn test_lifetime<'lt, T: Trait>(_: Foo<&'lt u8>) {} //[fail]~^ ERROR `&'lt u8` does not fulfill the required lifetime // implied bound: `T::Ty2<'lt>: placeholder('x)`. // don't use the bound to prove `T::Ty2<'lt>: 'static`. fn test_alias<'lt, T: AnotherTrait>(_: Foo<T::Ty2::<'lt>>) {} //[fail]~^ ERROR `<T as AnotherTrait>::Ty2<'lt>` does not fulfill the required lifetime } mod pass { use super::*; // implied_bound: 'static: placeholder('x). // don't ice. fn test_lifetime<T: Trait>(_: Foo<&'static u8>) {} // implied bound: T::Ty2<'static>: placeholder('x). // don't add the bound to the environment, // otherwise we would fail to infer a value for `'_`. fn test_alias<T: AnotherTrait>(_: Foo<T::Ty2::<'static>>) { None::<&'static T::Ty2<'_>>; } } fn main() {} </ins>

Discussion:
In that commit, go to folder and run (tested in nightly, stable 1.69 and stable 1.70) : <details<summary<strongBacktrace</strong</summary<p</p</details
This is causing us to leak placeholders into implied bounds. Minimized: