jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0428]: the name `TestSome` is defined multiple times --> $DIR/duplicated-fields-issue-124464.rs:6:5 | LL |     TestSome(T), |     ----------- previous definition of the type `TestSome` here LL |     TestSome(T), |     ^^^^^^^^^^^ `TestSome` redefined here | = note: `TestSome` must be defined only once in the type namespace of this enum error[E0124]: field `bar` is already declared --> $DIR/duplicated-fields-issue-124464.rs:12:5 | LL |     bar: TestOption<u64>, |     -------------------- `bar` first declared here LL |     bar: u8, |     ^^^^^^^ field already declared error: aborting due to 2 previous errors Some errors have detailed explanations: E0124, E0428. For more information about an error, try `rustc --explain E0124`. </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
with debug assertions: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
without: --<details<summary<strongBacktrace</strong</summary<p</p</details

<!-- 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. --(reduced) <details<summary<strongOriginal Code</strong</summary<p</p</details<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details- has the same ICE location, but this one doesn't require any feature to make ICE. ICE-loc: Original ICE-triggering code is mutated from test-file
bisects to searched nightlies: from nightly-2024-01-01 to nightly-2024-04-30 regressed nightly: nightly-2024-02-21 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
The following already reproduces on 1.77 stable
Change:
} fn check_fn_target_features(&self, instance: ty::Instance<'tcx>) -> InterpResult<'tcx, ()> { <ins> // Calling functions with `#[target_feature]` is not unsafe on WASM, see #84988 </ins> let attrs = self.tcx.codegen_fn_attrs(instance.def_id()); <del> if attrs .target_features .iter() .any(|feature| !self.tcx.sess.target_features.contains(feature)) </del> <ins> if !self.tcx.sess.target.is_like_wasm && attrs .target_features .iter() .any(|feature| !self.tcx.sess.target_features.contains(feature)) </ins> { throw_ub_custom!( fluent::const_eval_unavailable_target_features_for_fn,

Discussion:
I tried this code on 1.73: Compiled it with , I expected it to compile fine as on previous 1.72.1, but it gave me these errors: It most recently worked on: 1.72.1 Output: : I read release notes for 1.73 and couldn't find anything that could be related to this, also tried to search for an existing issue about this - no luck. This issue also broke compilation of crate and transitively, Fyrox game engine.
Bisected to . cc
And then this was fixed by (or at least it started compiling since)
Hm, why does it think that the function requires that target feature? That function doesn't have any attribute... Cc
Ah, that's what changed in -- that from a bunch of functions. This was changed in Cc
That was changed in stdarch specifically in response to , to avoid breaking users who were using the already.
In principle we could probably silence this check on wasm, since we document wasm to be a target where calling functions with unsupported target features is safe.
What happens in wasm when you call a function that requires an unavailable target feature?
I am told that the wasm runtime will refuse to even load a module that contains invalid operations, so there are two options: the generated code makes no use of the target feature, and so everything just works the generated code makes use of the target feature, and we don't even ever get to the function call since loading the wasm module already failed
can you check on of the latest nightlies to verify if it works for you? (ref. )
We have a special exception for wasm that allows targetfeature functions to not be marked unsafe: We should probably have the same exception in the target-feature check in the interpreter. do you have the time for a follow-up PR implementing that?
I re-checked on latest nightly and seems to work fine:
I will do that
WG-prioritization assigning priority (). Issue is fixed on nightly+beta, leaving open to follow PR fixing label -I-prioritize +P-medium
In which version this fix will be included?
Should land in stable 1.74 (around mid November), iiuc. See or an
Change:
priv todo: ~[(Path,uint)] } <del> /** * Return an iterator that produces all the Paths that match the given pattern, * which may be absolute or relative to the current working directory. * * This method uses the default match options and is equivalent to calling * `glob_with(pattern, MatchOptions::new())`. Use `glob_with` directly if you * want to use non-default match options. * * # Example * * Consider a directory `/media/pictures` containing only the files `kittens.jpg`, * `puppies.jpg` and `hamsters.gif`: * * ```rust * for path in glob("/media/pictures/*.jpg") { *     println(path.to_str()); * } * ``` * * The above code will print: * * ``` * /media/pictures/kittens.jpg * /media/pictures/puppies.jpg * ``` */ </del> <ins> /// /// Return an iterator that produces all the Paths that match the given pattern, /// which may be absolute or relative to the current working directory. /// /// is method uses the default match options and is equivalent to calling /// `glob_with(pattern, MatchOptions::new())`. Use `glob_with` directly if you /// want to use non-default match options. /// /// # Example /// /// Consider a directory `/media/pictures` containing only the files `kittens.jpg`, /// `puppies.jpg` and `hamsters.gif`: /// /// ```rust /// for path in glob("/media/pictures/*.jpg") { ///     println(path.to_str()); /// } /// ``` /// /// The above code will print: /// /// ``` /// /media/pictures/kittens.jpg /// /media/pictures/puppies.jpg /// ``` /// </ins> pub fn glob(pattern: &str) -> GlobIterator { glob_with(pattern, MatchOptions::new()) }

Discussion:
Currently we don't support nested block comments. This allows lexing to be regular, but it widely seen as an inconvenience. Modify the lexer to keep track of comment nesting. Nominating backcompat.
I thought we were going to grow a macro to handle block quotes. Did that ever get implemented?
I don't know what you mean by block quotes.
Accepted for feature-complete
Don't line comments address pretty much all uses of nested block comments?
by block quote, I mean in the style of CPP's to allow for nesting comments. Something like this:
From what I've gathered from the code, there are two implementations of the comment parsing, one of which supports nested comments, so I guess should be fixed before this bug.
That's pretty funny that the pretty printer already supports nested comments. I don't think they necessarily have to be merged to fix this bug, though our lexing is a bit of a mess.
Are you going to tackle this?
If there's no massive refactoring to do, I can try! Expect a PR soon.
The reference manual says "Comments in Rust code follow the general C++ style of line and block-comment forms, with no nesting of block-comment delimiters" ... right after production rules for nested comments.
looks like it was forgotten to be updated, thanks for noticing! (I opened )
Change:
use rustc_middle::infer::unify_key::{ConstVariableOrigin, ConstVariableOriginKind}; use rustc_middle::ty::error::{ExpectedFound, TypeError}; use rustc_middle::ty::relate::{RelateResult, TypeRelation}; <ins> use rustc_middle::ty::TyVar; </ins> use rustc_middle::ty::{self, InferConst, ToPredicate, Ty, TyCtxt, TypeVisitableExt}; use rustc_middle::ty::{IntType, UintType}; use rustc_span::DUMMY_SP;

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. -- <!-- --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
minimal repro of the error reported above <details<summaryBacktrace</summary</details
Same ICE with in  () cc searched nightlies: from nightly-2023-12-03 to nightly-2023-12-06 regressed nightly: nightly-2023-12-06 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Change:
} } <ins> /// Return the set of type variables contained in a trait ref fn trait_ref_type_vars<'a, 'tcx>(selcx: &mut SelectionContext<'a, 'tcx>, t: ty::PolyTraitRef<'tcx>) -> Vec<Ty<'tcx>> { t.skip_binder() // ok b/c this check doesn't care about regions .input_types() .iter() .map(|t| selcx.infcx().resolve_type_vars_if_possible(t)) .filter(|t| t.has_infer_types()) .flat_map(|t| t.walk()) .filter(|t| match t.sty { ty::TyInfer(_) => true, _ => false }) .collect() } </ins> /// Processes a predicate obligation and returns either: /// - `Ok(Some(v))` if the predicate is true, presuming that `v` are also true /// - `Ok(None)` if we don't have enough info to be sure

Discussion:
This takes ~2 seconds to type check (according to ): Doubling (respectively, halving) the number of invocations multiplies (resp. divides) the time by 4. It applies to arithmetic in s/s too which is, I imagine, where this will occur most often in practice (it's how I found it). Observations: for , , and , annotating either side (e.g. ) or both sides makes it take only 0.03s and behave linearly (AFAICT) for and : annotating the LHS () reduces the time to ~1.5s, annotating the RHS () reduces it to ~1.1s but both are still quadratic, annotating both takes it to 0.04s and linear it seems to only be dependent on the number of operations in a single function/item, separating the 4 big chunks above across 4 functions reduces the time to ~0.5s. there's no significant difference between using the macro or writing the operations inline (I only use to allow easier experimentation) cc
This must be what's making my old macro-abusing inflate implementation take almost 300 seconds in typeck. It almost sounds like type-checking a function is quadratic over the number of inference variables. Having ran callgrind on the sample and also half of it, I'm seeing the following trace: An unrefined conclusion is that either shouldn't call or should be constant-time.
Is this the same issue as ?
I'm not too familiar with fulfill and infer, but couldn't track the latest snapshot it processed and look at the new information there?
We have exactly for this reason. It doesn't work for some reason tho.
This is the same issue as This is a different issue from (I think I will fix that one separately).
Change:
#[naked] pub fn naked_with_args_and_return(a: isize) -> isize { // CHECK-NEXT: {{.+}}: <del> // CHECK-NEXT: %_1 = alloca i{{[0-9]+}} </del> <ins> // CHECK-NEXT: %a = alloca i{{[0-9]+}} </ins> &a; // keep variable in an alloca // CHECK: ret i{{[0-9]+}} %{{[0-9]+}} a

Discussion:
When compiling () The generated assembly includes a prologue with unexpected 's (as well as a trailing , already reported in ) Expected behaviour would be to have no prologue (and prevent compilation of a function that is not as this would require implementing an undefined ABI, contrarily to what seems to happen ). This is treacherous, as it dereferences some memory locations that may not be accessible, as happened to me and led to hours of debugging to finally figure out the compiled function was not the one defined. cc
IIRC this is invalid and rustc should reject such a function, naked functions can't take arguments and the compiler should probably enforce that.
Hmm, my understanding of the RFC (“The following variant is not an error because the C calling convention is well-defined and it is thus possible for the programmer to write a conforming function”, even if the example is not with an argument) would mean that if the function is declared , then the function can actually respect the said ABI, thus should be well-formed?
Is there an update on this? I was hit by this issue as well. I hit the problem when compiling a tock app (baremetal-ish and jumped to by the tock OS) A naked function with arguments would produce this prolog (RV32): Which would result in an invalid access as s0 would be 0. Removing the arguments would remove the prologue and fix the problem. Removing the naked cfg would also work as teh stack pointer was already setup by the OS and result in this. If arguments with naked functions aren't supported rustc should generate an error as this is a difficult problem to debug.
This is an LLVM bug. Has it been reported upstream?
Change:
} LocalKind::Temp if !temps[local].is_promotable() => { <del> cx.per_local[IsNotPromotable].insert(local); </del> <ins> cx.per_local[IsNotConst].insert(local); </ins> } _ => {}

Discussion:
Expected the following code to compile But getting Repro:
Also happens on beta, not on stable
Stable says:
For reference, the function signature as defined is exactly the same.
The actual ICE occurs first in nightly-2019-03-03 (...). But interesting enough, stable (as jonas pointed out) procuces an error, saying, that the third argument must be a constant. Since nightly-2019-02-16 (...) this does not emit an error anymore, but also does not ICE.
I guess for the "does not emit an error anymore" can say something about it. should be responsible for it.
triage: P-high
Note that because of the on the definition, you can't wrap it (without matching on and having 256 separate calls). I don't think this is intentional, but I'm not sure why it would happen, maybe arguments are treated incorrectly in the qualifier. cc
So I agree that this code can't compile, that's the expected behavior; if you want to wrap it, you have to use a macro - Rust functions aren't able to abstract over this type of hardware operations yet. The ICE is a regression over the error message that was being produced before. We should definitely add an ui test for that.
triage, assigning to self to fix the stable-to-beta regression.
The behavior here varies with edition as well as channel. edition 2018 ------------------ ------------------------ stable expected error beta unexpected compile-pass nightly-2019-04-05 ICE I think the most immediate thing to address is the unexpected compile-pass that has leaked into beta.
The easiest thing might be to revert
I have an actual fix in (also easier to backport than a revert)
Okay then I'm reassigning to
Change:
/// Pushes a new row to the matrix. If the row starts with an or-pattern, this expands it. crate fn push(&mut self, row: PatStack<'p, 'tcx>) { if let Some(rows) = row.expand_or_pat() { <del> self.0.extend(rows); </del> <ins> for row in rows { // We recursively expand the or-patterns of the new rows. // This is necessary as we might have `0 | (1 | 2)` or e.g., `x @ 0 | x @ (1 | 2)`. self.push(row) } </ins> } else { self.0.push(row); }

Discussion:
This code is reduced from issue--unused-parens- :
Another variation on this to include in a regression test:
cc
Ah yeah, I see the issue. There's an implicit invariant that there should be no or-patterns directly in the first column of the matrix, but this invariant is broken exactly when an or-pattern has a child that is itself an or-pattern. I should have documented that. Specifically this fails to preserve the invariant: I don't expect to have the bandwidth to work on rustc in the foreseeable future sadly. I anyone wants to try, I believe the fix could be as simple as replacing in the above function with a loop that calls (and not ). That will ensure that we recursively expand or-patterns as needed instead of just expanding the first one.
Yep, that did it. Thanks for the pointer. This issue is fixed by
Change:
// FIXME -- it seems like this method actually pushes // duplicate impls onto the list <del> ty::populate_implementations_for_type_if_necessary(self.tcx, trait_def_id); </del> <ins> ty::populate_implementations_for_trait_if_necessary(self.tcx, trait_def_id); </ins> let mut impls = Vec::new(); self.push_impls_of_trait(trait_def_id, &mut impls);

Discussion:
Arch Linux, x86_64, Code: I didn't expect this to compile successfully, but when I tried I hit an error which asked me nicely to report it as a compiler bug :smile:
Reduced test case:
Taking a look
It seems that overlap checking is not finding the blanket impl of for at all...
I have a fix, will submit a PR after lunch.
Change:
[[package]] name = "clippy_lints" <del> version = "0.0.166" </del> <ins> version = "0.0.171" </ins> dependencies = [ "if_chain 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)", "itertools 0.6.5 (registry+https://github.com/rust-lang/crates.io-index)",

Discussion:
branch: master Compiling cargometadata v0.2.3 Compiling clippylints v0.0.166 (file:///home/ryan/git/rust/src/tools/clippy/clippylints) error: :vis fragment specifier is experimental and subject to change (see issue ) --<declarelint macros:1:3 | 1 | ( NAME : ident , desc : expr ) =( | ^^^^^^^^^^^ | = help: add #![feature(macrovismatcher)] to the crate attributes to enable error: :vis fragment specifier is experimental and subject to change (see issue ) --<declarelint macros:1:3 | 1 | ( NAME : ident , desc : expr ) =( | ^^^^^^^^^^^ | = help: add #![feature(macrovismatcher)] to the crate attributes to enable error: aborting due to previous error error: aborting due to previous error error: Could not compile . warning: build failed, waiting for other jobs to finish... error: Could not compile . warning: build failed, waiting for other jobs to finish... error: build failed This failure is expected (see ) Build completed successfully in 1:46:49
Everything is actually fine, as you can see by the last two lines of the log. I hope to remove the error log if the failure is expected in the future, but not sure yet how best to do that.
Is it related to rust-lang-nursery/rust-clippy?
Change:
trace!("encoding {} further alloc ids", new_n - n); for idx in n..new_n { let id = self.interpret_allocs[idx]; <del> let pos = self.position() as u32; </del> <ins> let pos = self.position() as u64; </ins> interpret_alloc_index.push(pos); interpret::specialized_encode_alloc_id(self, tcx, id); }

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. --: I see similar behavior in stable : The example always succeeds to compile the first time, but uses a large amount of time and memory. : Upon incremental re-compilation, I almost always see one of the following errors. I saw other open issues with a similar error message as the 1.46.0 output below, but in this one the error is affected by the value the array was filled with. : Running sometimes yields a different yet similar error: On 1.46.0: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pOn 1.46.0: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
do you know if this is still a problem for you? claim
On 1.66.0, I still get an error upon incremental recompilation with the same code: <details<summary<strongBacktrace</strong</summary</details
Oh wow I didn't know anyone actually hit this so long ago! I turned this into a much nicer panic a few months ago:
Change:
| clean::TraitItem(..) | clean::FunctionItem(..) | clean::VariantItem(..) <del> | clean::MethodItem(..) </del> | clean::ForeignFunctionItem(..) | clean::ForeignStaticItem(..) | clean::ConstantItem(..) | clean::UnionItem(..) <del> | clean::AssocConstItem(..) | clean::AssocTypeItem(..) </del> | clean::TraitAliasItem(..) | clean::MacroItem(..) | clean::ForeignTypeItem => {

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 the documentation for the type alias to show the method and the implementation of . Instead, the type alias does not show the method . It does however show the implementation of . ! By publicly exposing through , the documentation of on the alias is documented as I expected, but then is publicly reachable, which in my case is unwanted due to being an internal implementation detail. This also works when making the statement , which gets the docs to look like I expected them to. ! <!-- 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. --: Thanks for helping me figure out why what I was expecting wasn't happening though it looked like it should.
I think it's ok to document an impl on a reexported if the reexported item is not doc hidden. I'll send a fix in the next weeks.
Change:
} fn f5() { <del> async //~ ERROR async closures are unstable </del> <ins> async </ins> let x = 0; //~ ERROR expected one of `move`, `|`, or `||`, found keyword `let` }

Discussion:
This code (): prints out This is pretty unhelpful for beginners - normally this happens when they try to use in a closure, which tells them they need async: But when they do they get an error about async being unstable, which they have no idea how to solve. The fix is to remove the pipe symbols: However, this requires knowledge that async blocks desugar internally into closures, which is not at all clear from the syntax. It would be better for the compiler to suggest it:
Hey, I saw this and it looked like it might be easy so I took a shot with I haven't fixed the tests yet because I wasn't sure if this approach is reasonable or not. You end up with Re-ordering the note and help, or adding a nested span on to put the help would be considerably more involved.
Given the current is equivalent to , it may be preferable to suggest instead of .
the point of this is that the user didn't mean though. If you add then you can no longer await it: For context, the original code was something like , where the user tried to use outside of an async function.
Thanks for clarifying. What suggestion is preferable seems to depend on the expected return type. Perhaps it is preferable to have both notes?