jiebi/CodeConvo huggingface dataset:
Change:
#[unstable(feature = "concat_idents_macro", issue = "29599")] #[macro_export] macro_rules! concat_idents { <del> ($($e:ident),*) => ({ /* compiler built-in */ }) </del> <ins> ($($e:ident),*) => ({ /* compiler built-in */ }); ($($e:ident,)*) => ({ /* compiler built-in */ }); </ins> } /// Concatenates literals into a static string slice.

Discussion:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged
Change:
// Forward arguments. miri.arg("--").arg("--target").arg(target.rustc_target_arg()); miri.args(builder.config.cmd.args()); <ins> miri.args(&builder.config.free_args); </ins> // miri tests need to know about the stage sysroot miri.env("MIRI_SYSROOT", &miri_sysroot);

Discussion:
Right now, x.py is pretty inconsistent with cargo's CLI. To pass arguments to compiletest, you use ; to pass arguments to you use ; to pass arguments to cargo you use CARGOFLAGS. I would like to unify these with the same syntax as cargo: would behave the same as today would behave the same as would behave the same as today, except that it would only pass it to cargo commands invoked by bootstrap, not when building bootstrap itself (avoiding the "argument --fix-broken not expected" error you'd get today). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Looking at the current setup for argument parsing, it appears that getopts::Options struct doesn't have a state engine based parser, so it wont be able to parse -- as a state changing flag. I'm thinking probably parse and translate the args in python then just pass it on to the bootstrap executable, (unless someone here has a better idea).
let's not put any logic in python if we can help it, it's going away soon: . I think it would be ok to switch to or another arg parser if it makes things easier.
Ah, I was thinking something like getting rid of the python script was going to happen someday. will probably do for the functionality we will need from it.
I'm out of town for the rest of the week so if anyone would like to take this issue while I'm away, go for it.
Change:
impl<'a> Writer for &'a mut Writer+'a { #[inline] <del> fn write(&mut self, buf: &[u8]) -> IoResult<()> { self.write(buf) } </del> <ins> fn write(&mut self, buf: &[u8]) -> IoResult<()> { (**self).write(buf) } </ins> #[inline] <del> fn flush(&mut self) -> IoResult<()> { self.flush() } </del> <ins> fn flush(&mut self) -> IoResult<()> { (**self).flush() } </ins> } /// A `RefWriter` is a struct implementing `Writer` which contains a reference

Discussion:
Code: Compile, run, result is Sorry, cannot find smaller example to reproduce the problem. Similar code, internal compiler error:
Smaller:
Looks like a libstd bug: could you file a separate issue for the internal compiler error?
Change:
if let Some(indexed_extent) = indexed_extent { let parent_def_id = cx.tcx.hir().get_parent_item(expr.hir_id); let region_scope_tree = cx.tcx.region_scope_tree(parent_def_id); <del> let pat_extent = region_scope_tree.var_scope(pat.hir_id.local_id); </del> <ins> let pat_extent = region_scope_tree.var_scope(pat.hir_id.local_id).unwrap(); </ins> if region_scope_tree.is_subscope_of(indexed_extent, pat_extent) { return; }

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 --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I was just looking at the parsing code for const generic exprs.. claim
actually, so this isn't related to incorrectly parsing , since we're parsing in expr position to allow if-let chains.. -- this is due to const eval lowering to MIR and the fact that const generic parameters have no enclosing scope. Adding around the generic args works, but I don't know where exactly to hack in a scope for these params. release-assignment label A-const-eval A-mir
Maybe fixing this also fixes :slightlysmilingface:
This gives an error without ICE in 1.55
It was unclear to me - I think meant that changing to gives a compile error instead of an ICE. So the proper fix here is probably to add somewhere instead of panicking.
Then this should be easy. claim
Change:
HTMLParser.close(self) return self.__builder.close() <del> Command = namedtuple('Command', 'negated cmd args lineno') </del> <ins> Command = namedtuple('Command', 'negated cmd args lineno context') class FailedCheck(Exception): pass class InvalidCheck(Exception): pass </ins> def concat_multi_lines(f): """returns a generator out of the file object, which

Discussion:
When a doc test fails, the console output looks like this: A traceback should only be shown if there was an error in the python script itself - in this case it should only show the matches error, something like this:
cc me. I'm surely willing to fix that as soon as I get enough spare time.
did you ever get a chance to look at this? (Do you know if the situation has changed?)
No, also I'm not aware of any update. Looks like that I've forgotten this at that time (as flt2dec was being matured); I have virtually no energy to contribute nowadays, so I probably cannot work on this right now.
Change:
<ins> //! Tests that generator discriminant sizes and ranges are chosen optimally and that they are //! reflected in the output of `mem::discriminant`. // run-pass #![feature(generators, generator_trait, core_intrinsics)] use std::intrinsics::discriminant_value; use std::marker::Unpin; use std::mem::size_of_val; use std::{cmp, ops::*}; macro_rules! yield25 { ($e:expr) => { yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; yield $e; }; } /// Yields 250 times. macro_rules! yield250 { () => { yield250!(()) }; ($e:expr) => { yield25!($e); yield25!($e); yield25!($e); yield25!($e); yield25!($e); yield25!($e); yield25!($e); yield25!($e); yield25!($e); yield25!($e); }; } fn cycle(gen: impl Generator<()> + Unpin, expected_max_discr: u64) { let mut gen = Box::pin(gen); let mut max_discr = 0; loop { max_discr = cmp::max(max_discr, discriminant_value(gen.as_mut().get_mut())); match gen.as_mut().resume(()) { GeneratorState::Yielded(_) => {} GeneratorState::Complete(_) => { assert_eq!(max_discr, expected_max_discr); return; } } } } fn main() { // Has only one invalid discr. value. let gen_u8_tiny_niche = || { || { // 3 reserved variants yield250!(); // 253 variants yield; // 254 yield; // 255 } }; // Uses all values in the u8 discriminant. let gen_u8_full = || { || { // 3 reserved variants yield250!(); // 253 variants yield; // 254 yield; // 255 yield; // 256 } }; // Barely needs a u16 discriminant. let gen_u16 = || { || { // 3 reserved variants yield250!(); // 253 variants yield; // 254 yield; // 255 yield; // 256 yield; // 257 } }; assert_eq!(size_of_val(&gen_u8_tiny_niche()), 1); assert_eq!(size_of_val(&Some(gen_u8_tiny_niche())), 1); // uses niche assert_eq!(size_of_val(&Some(Some(gen_u8_tiny_niche()))), 2); // cannot use niche anymore assert_eq!(size_of_val(&gen_u8_full()), 1); assert_eq!(size_of_val(&Some(gen_u8_full())), 2); // cannot use niche assert_eq!(size_of_val(&gen_u16()), 2); assert_eq!(size_of_val(&Some(gen_u16())), 2); // uses niche cycle(gen_u8_tiny_niche(), 254); cycle(gen_u8_full(), 255); cycle(gen_u16(), 256); } </ins>

Discussion:
Currently they use a hardcoded discriminant, which is quite a lot of room considering that generators don't typically have billions of states. They should be able to use the smallest unsigned integer type that fits all states instead (so in the vast majority of cases).
The discriminant is also never marked with a valid range, meaning that it never provides any niches that could be used to store other values. Not sure if doing that has any drawbacks, but it seems like a somewhat easy size optimization on first glance.
Fixing this was way easier than I expected, but I'd appreciate help with benchmarking the runtime impact of the fix in . So if anyone knows any async/await benchmarks that are not I/O heavy (so that they mostly test CPU overhead of async/await), I'd be happy to run them.
Change:
endif # The stage we install from <del> ISTAGE = 3 </del> <ins> ISTAGE = 2 </ins> PREFIX_ROOT = $(CFG_PREFIX) PREFIX_BIN = $(PREFIX_ROOT)/bin

Discussion:
We're not comparing stage2 and stage3 at the moment, and the amount of bugs caught by that extra stage that wouldn't be caught in stage2 is probably very small. We could shave off some cycle time by only going to stage2, and doing a stage3 check only on checkpoints.
Fixed in .
Change:
//! OS-specific networking functionality. <ins> // See cfg macros in `library/std/src/os/mod.rs` for why these platforms must // be special-cased during rustdoc generation. #[cfg(not(all( doc, any( all(target_arch = "wasm32", not(target_os = "wasi")), all(target_vendor = "fortanix", target_env = "sgx") ) )))] </ins> #[cfg(any(target_os = "linux", target_os = "android", doc))] pub(super) mod linux_ext;

Discussion:
Any ideas?
Regressed with
cc
Is there more information available from the error? The module should not be part of the FreeBSD build. Also, an error in resolving doesn't make much sense to me because that module should exist regardless of whether the feature is enabled. Is it possible that there's either (1) another error further up in the build log, or (2) an existing incorrect dependency that's been exposed by the recent change?
The full log is available here:
It only happens if I build the documentation. Is it possible to fix this problem before rust 1.67 lands?
Reproduced with the following command: could you please see if the patch in fixes the build for you?
Your patch fixes the issue. Many thanks!
Change:
//! Overloadable operators. //! <del> //! Implementing these traits allows you to get an effect similar to //! overloading operators. </del> <ins> //! Implementing these traits allows you to overload certain operators. </ins> //! //! Some of these traits are imported by the prelude, so they are available in <del> //! every Rust program. </del> <ins> //! every Rust program. Only operators backed by traits can be overloaded. For //! example, the addition operator (`+`) can be overloaded through the `Add` //! trait, but since the assignment operator (`=`) has no backing trait, there //! is no way of overloading its semantics. Additionally, this module does not //! provide any mechanism to create new operators. If traitless overloading or //! custom operators are required, you should look toward macros or compiler //! plugins to extend Rust's syntax. </ins> //! //! Many of the operators take their operands by value. In non-generic //! contexts involving built-in types, this is usually not a problem.

Discussion:
Part of did a wonderful job here a month or two ago, but we should still double check it, and make sure links are in place for all types, etc.
I am happy with this now.
Change:
use crate::traits::{NormalizeExt, ObligationCtxt}; use hir::def::CtorOf; <del> use hir::HirId; </del> <ins> use hir::{Expr, HirId}; </ins> use rustc_data_structures::fx::FxHashSet; use rustc_data_structures::stack::ensure_sufficient_stack; use rustc_errors::{

Discussion:
we should suggest cloning. Also, we should suggest <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
If we suggest add bound, we don't need dervie , This code will compile:
Change:
<ins> // edition: 2021 #![feature(return_position_impl_trait_in_trait, async_fn_in_trait)] #![allow(incomplete_features)] trait Uwu { fn owo(x: ()) -> impl Sized; } impl Uwu for () { fn owo(_: u8) {} //~^ ERROR method `owo` has an incompatible type for trait } trait AsyncUwu { async fn owo(x: ()) {} } impl AsyncUwu for () { async fn owo(_: u8) {} //~^ ERROR method `owo` has an incompatible type for trait } trait TooMuch { fn calm_down_please() -> impl Sized; } impl TooMuch for () { fn calm_down_please(_: (), _: (), _: ()) {} //~^ ERROR method `calm_down_please` has 3 parameters but the declaration in trait `TooMuch::calm_down_please` has 0 } trait TooLittle { fn come_on_a_little_more_effort(_: (), _: (), _: ()) -> impl Sized; } impl TooLittle for () { fn come_on_a_little_more_effort() {} //~^ ERROR method `come_on_a_little_more_effort` has 0 parameters but the declaration in trait `TooLittle::come_on_a_little_more_effort` has 3 } trait Lifetimes { fn early<'early, T>(x: &'early T) -> impl Sized; } impl Lifetimes for () { fn early<'late, T>(_: &'late ()) {} //~^ ERROR method `early` has an incompatible type for trait } fn main() {} </ins>

Discussion:
Essentially, if my trait has and my impl has the compiler panics. Note that the code is invalid and compilation should fail. <!-- 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. --: Note that I'm using which is experimental. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This happens for all type mismatches in the arguments (but not the arity!) A : <details<summaryWith the following backtrace: </summary</details
When not using a normal , the proper error is emitted here inside : But something gets messed up with the return position impl trait in trait desugaring that doesn't make this work (the arity check above does work). claim
Change:
error[E0632]: cannot provide explicit generic arguments when `impl Trait` is used in argument position <del> --> $DIR/universal-issue-48703.rs:8:5 </del> <ins> --> $DIR/universal-issue-48703.rs:8:11 </ins> | LL |     foo::<String>('a'); <del> |     ^^^^^^^^^^^^^ </del> <ins> |           ^^^^^^ explicit generic argument not allowed </ins> error: aborting due to previous error

Discussion:
The spans for this error should point to the generic arguments, not the entire path. See <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
use rustc_hir::def::{CtorOf, DefKind}; use rustc_hir::lang_items::LangItem; use rustc_hir::{Expr, ExprKind, ItemKind, Node, Path, QPath, Stmt, StmtKind, TyKind}; <del> use rustc_infer::infer; </del> <ins> use rustc_infer::infer::{self, TyCtxtInferExt}; </ins> use rustc_middle::lint::in_external_macro; use rustc_middle::ty::{self, Binder, Ty}; use rustc_span::symbol::{kw, sym};

Discussion:
Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like it does for the : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-async-await +D-papercut
I'm gonna try and take a shot at this. claim
Thanks for putting up a PR so quickly, label +AsyncAwait-Triaged +AsyncAwait-Polish
Change:
<ins> error: array lengths can't depend on generic parameters --> $DIR/issue-62504.rs:18:25 | LL |         ArrayHolder([0; Self::SIZE]) |                         ^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd like to work on this. claim
Now ICE no longer occurs, I think it's fixed by . Marked as E-needstest.

When executed in the : <details<summaryCompiler output</summary</detailsEDIT: Here's the updated and the new stack trace as of Jan 7, 2020: <details<summaryCompiler output</summary</details
cc
I think this is another instance of However, we can leave this issue open to remember to add a test case when it's fixed.
The original issue no longer ICEs and instead errors with: which is essentially correct. However, providing the type annotations produces a new ICE:
In Source: <details<summaryStack trace</summary<p</p</details
Now ICE no longer occurs. I think it's fixed by .

This occurs on 1.34.1 and 1.34.0, is a regression from 1.33.0, and does.. not occur on nightly? Reproduction: compiled with Yields: I found this in building crates like and but pared it down to this
I think this is fixed in which might explain why it doesn't occur on nightly
triage: Probably fixed by . Normally an ICE would lead me to tag this as P-high, but the fact that this is only exposed by leads me to prioritize this as P-medium.
assigning to self to confirm that is the reason this is fixed, and (if need be) add a regression test.
Here's a slightly smaller case of what appears to potentially be the same thing which shows up if you select the "show MIR" option in In particular the following error is observed:
I think this issue is fixed in all channels. I tried stable and nightly both locally and on , and couldn't get any ICEs. Should we add a test? Otherwise we can just close I think.
Adding a test with seems like a good idea.

Compiler crash when using cfgif and defining a macro with macrorules twice. I tried this code: In a repo: I expected to see this happen: error: a macro named has already been exported Instead, this happened: error: internal compiler error: unexpected panic : Backtrace:
Regression from stable to stable (works in 1.30). Reduced test case:
mode is implemented on best effort basis, generally unsupported and will be removed in some time.
Ah, I see, the original issue doesn't have it. I'll investigate.
Reproducer in no longer ICEs.
Change:
<ins> error: array lengths can't depend on generic parameters --> $DIR/issue-62504.rs:18:25 | LL |         ArrayHolder([0; Self::SIZE]) |                         ^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
results in: Removing the constgenerics feature flag gets the expected error message: (IIUC that itself is a bug related to ) Using directly outside of a const-context works, which I guess is something const_generics enables that isn't otherwise allowed. Finally, the error message is the same whether or not the code is in a provided method or a impl block; I actually ran into the bug in the later.
I believe this should be fixed by
Now, it shows different ICE(s) ():
Now ICE no longer occurs. I think it's fixed by .
Change:
<ins> // revisions: x86_64 arm //[x86_64] compile-flags: --target x86_64-unknown-linux-gnu //[arm] compile-flags: --target armv7-unknown-linux-gnueabihf #![feature(no_core, lang_items, rustc_attrs)] #![no_core] #[rustc_builtin_macro] macro_rules! asm { () => {}; } #[lang = "sized"] trait Sized {} fn main() { unsafe { asm!(".intel_syntax noprefix", "nop"); //[x86_64]~^ ERROR intel syntax is the default syntax on this target asm!(".intel_syntax aaa noprefix", "nop"); //[x86_64]~^ ERROR intel syntax is the default syntax on this target asm!(".att_syntax noprefix", "nop"); //[x86_64]~^ ERROR using the .att_syntax directive may cause issues //[arm]~^^ att syntax is the default syntax on this target asm!(".att_syntax bbb noprefix", "nop"); //[x86_64]~^ ERROR using the .att_syntax directive may cause issues //[arm]~^^ att syntax is the default syntax on this target asm!(".intel_syntax noprefix; nop"); //[x86_64]~^ ERROR intel syntax is the default syntax on this target asm!( r" .intel_syntax noprefix nop" ); //[x86_64]~^^^ ERROR intel syntax is the default syntax on this target } } </ins>

Discussion:
People used to gcc/clang inline assembly may try using the or directives directly in the assembly string, which can cause issues. Ideally, we should detect attempts to use those directives. Attempting to use should generate an error stating that that's the default. Attempting to use should generate an error and point to the option, ideally with a rustfix-applicable suggestion. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Is anyone currently working on this? I would like to do it if not.
Not to my knowledge, no.
claim
Change:
// Create StorageLive instructions for locals with live storage for i in 0..(body.local_decls.len()) { <del> if i == 2 { // The resume argument is live on function entry. Don't insert a // `StorageLive`, or the following `Assign` will read from uninitialized // memory. continue; } </del> let l = Local::new(i); let needs_storage_live = point.storage_liveness.contains(l) && !transform.remap.contains_key(&l)

Discussion:
Reproduces with on commit Remove and add to get a lot of ICEs like this:
So, looks like we should either allow StorageLive on an already live local, or we need to ensure that all locals are explicitly marked StorageDead before returning. No idea how realistic it is to achieve the latter. Cc
Change:
} while !self.provided_indices.is_empty() || !self.expected_indices.is_empty() { <del> match self.find_issue() { </del> <ins> let res = self.find_issue(); match res { </ins> Some(Issue::Invalid(idx)) => { let compatibility = self.compatibility_matrix[idx][idx].clone(); let input_idx = self.provided_indices[idx];

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: the compiler giving an error and showing a hint that order of the argument are not correct. Instead, this happened: it stucks, waits forever. It happens on both stable and nightly. Might be related to this:
Yeah, this is probably a dupe of that other one. cc
Yes, it's another bug in the same function, but the root cause is different. I will working on the same PR for this issue.
Change:
starts to create problems we'll have to revisit this portion of the code and think hard about it. =) */ <del> if opt_graph.is_none() { opt_graph = Some(self.construct_graph()); } let graph = opt_graph.as_ref().unwrap(); </del> let node_vid = RegionVid { index: idx as u32 }; match var_data[idx].classification { Expanding => {

Discussion:
Notably, this does not occur with a trait like: This smells like a bug to me, unless a language change introduced special treatment of with regard to lifetimes.
An interesting quirk is that if you replace with just , it compiles fine with the impl.
cc
are you saying this used to work? Just curious what the original was.
(Also it seems difficult if not impossible to satisfy the combination of and ..... well I guess of static would, but I don't know if we can deduce that.
Yes, this used to work. This bug is affecting
It looks like this may have been introduced in . Prior to this, checking for bounds in was done via , which creates a throw-away inference context before calling into trait selection. It now goes through the ; the impl of for uses its own inference context. This causes region constraints introduced during trait selection for to stick around, resulting in a seemingly inappropriate transitive constraint between the free region within the closure body and at the call site of .
hmm good catch, sorry I let this slip through last week :( I'll try to pay it some attention now. The current code does not seem entirely wrong to me, though. I have to think this through a bit.