jiebi/CodeConvo huggingface dataset:
Change:
<ins> #![crate_name = "foo"] #![crate_type = "rlib"] extern crate dependency; pub use dependency::Type; </ins>

Discussion:
I'm writing code for a programming language that uses two libraries: one for a (very simple) parser, and another for a lower level byte code, which also uses the same parser library. The parser library (TSPL) defines the trait, with the byte code library (HVM) defining a that implements that trait through a macro from TSPL. Then, a third library does something like this, where is a method from that trait: This works as expected if the dependencies in are defined like this: If we change to use the version from the latest git commit like this: Then the code does not compile anymore, even though the version in the main branch in git has the exact same code as the published version . We get an error and a warning: Notice that the compiler error tells us the function has been found from the package, and we do as the error message tells us (), but the compiler does not recognize the trait is being used even so. While writing this issue, I figured out the problem: uses the version from crates-io and our library doesn't and, even though they have the exact same code, the two versions of clash and the compiler does not compile. If we do something like this it works as expected: I still want to open this issue because I believe the error message could be more descriptive: in other cases where dependencies have clashing versions of other dependencies, usually Rust specifies it as such. The current error message is not very descriptive - the solution it gives to the problem does not work at all and may push users into the wrong direction. <!-- 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<summaryBacktrace</summary<p</p</details

Consider three crates High, Mid and Low, where: Mid depends on Low; High depends on both Mid and Low. This is a quite common case. Now, it sometimes happens that the dependency of Mid is bumped to a more recent version of Low. If, however, the developer fails to bump the dependency of High to a more recent version of Low, surprising error messages arise. In particular, may arise, without any change to the code of either or . It would be great if the compiler could detect the error and somehow print something along the liens of
Triage: I feel like this has gotten better in certain cases, but not all. It would be nice to make a way to reproduce this more easily, but it's non-trivial.
Change:
recursion_depth: 0, predicate: trait_ref.without_const().to_predicate(self.tcx), }; <del> self.evaluate_obligation_no_overflow(&obligation) </del> <ins> self.evaluate_obligation(&obligation).unwrap_or(traits::EvaluationResult::EvaluatedToErr) </ins> } }

Discussion:
While trying to migrate  0.11.1 to the 2021 edition, the compiler fails with this error: It is hard to create a small reproduction, but here is the command to run in that package to reproduce the error: I'm not sure if it is feasible to avoid this. I'm guessing that the lint is doing some kind of trait evaluation that happens to add some additional recursion that is not normally there. Adding fixes the problem. Opening this issue to track whether or not there is anything to do here. Note that the lint doesn't actually fire, so this is just during the analysis (presumably somewhere in ). Full error: <!-- 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. --: cc
don't think I have much context on this one either
I think the problem here is that we are using : But that uses : which is the variant that aborts on overflow we could write into and or something like that. I have to look at the places that call -- in this case, if we see overflow, we could just treat it as false. Scanning where is used: diagnostics, would be better to squelch overflow here too as above as above seems to be for lints, as above (side note that the is-drop-implemented-for-ty is not needed, right?) prelude2021: another 2021 lint, would prefer not to abort clippy: also a lint, probably also true there So, my proposed fix is that we change to return false on overflow. i.e., if it overflows, we don't know that the type implements the trait (we don't, in fact, know anything at all). The function is already approximating in the case of generics -- i.e., a false result doesn't mean that the type does NOT implement the trait, just that we don't know that it does.
Change:
} fn visit_pat(&mut self, p: &'a ast::Pat) { <del> let mut visit_subpats = true; run_early_pass!(self, check_pat, p, &mut visit_subpats); </del> <ins> run_early_pass!(self, check_pat, p); </ins> self.check_id(p.id); <del> if visit_subpats { ast_visit::walk_pat(self, p); } </del> <ins> ast_visit::walk_pat(self, p); run_early_pass!(self, check_pat_post, p); </ins> } fn visit_expr(&mut self, e: &'a ast::Expr) {

Discussion:
The parameter is a hack (to fix ) that should be refactored. The idea is that the state should be contained in instead. This should be straightforward to fix. the parameter from (You'll also need to update the signature of in . a method with an identical signature below it. the condition from an early lint pass for at the end. a field to in (Look at for an example of a lint with fields.) You'll also need to initialise it with here: should be replaced with an assignment of the new field in to : should be early-exited if the field is . a implementation to and reset the field to if the pattern ID matches the field ID. sure the UI tests still pass with no changes.
hi I'm happy to take care of this one if it's not taken already.
go ahead! Let me know if you have any questions or problems with the implementation! :)
Change:
/// # Examples /// /// ``` <del> /// #![feature(cmp_min_max_by)] /// </del> /// use std::cmp; /// /// assert_eq!(cmp::min_by(-2, 1, |x: &i32, y: &i32| x.abs().cmp(&y.abs())), 1);

Discussion:
Tracking issue for the feature, which adds the / / / functions to . PR:
Is there anything blocking this from stabilizing?
Doesn't look like it! If somebody would like to open a stabilization PR then we can start a FCP
Stabilization PR up at
Change:
value } <del> pub fn store(&self, val: ValueRef, ptr: ValueRef) { </del> <ins> pub fn store(&self, val: ValueRef, ptr: ValueRef) -> ValueRef { </ins> debug!("Store {} -> {}", self.ccx.tn().val_to_string(val), self.ccx.tn().val_to_string(ptr)); assert!(!self.llbuilder.is_null()); self.count_insn("store"); unsafe { <del> llvm::LLVMBuildStore(self.llbuilder, val, ptr); </del> <ins> llvm::LLVMBuildStore(self.llbuilder, val, ptr) </ins> } } <del> pub fn volatile_store(&self, val: ValueRef, ptr: ValueRef) { </del> <ins> pub fn volatile_store(&self, val: ValueRef, ptr: ValueRef) -> ValueRef { </ins> debug!("Store {} -> {}", self.ccx.tn().val_to_string(val), self.ccx.tn().val_to_string(ptr));

Discussion:
The attached source produces code that misbehaves on some platforms that are picky about memory access alignment. The code should exit with code 2, but on both Emscripten-generated JavaScript and ARMv5, it finishes with exit code 1 to indicate that the field is incorrectly tested as equal to . Changing the field to a type results in proper execution on these platforms. All optimization levels seem to cause it. Libraries that make use of structs with fields followed by enums seem particularly prone to this problem. It all works fine on platforms that allow unaligned memory access like x86, ARMv6, etc. Expected output: (x86, ARMv6) Actual output: (ARMv5, Emscripten) Note that the same ARM binary runs on both ARMv5 and ARMv6 platforms, producing the different results. See also: ( and removed)
To quote myself:
Change:
} impl<'a, 'tcx> PrivacyVisitor<'a, 'tcx> { <del> // used when debugging fn nodestr(&self, id: ast::NodeId) -> String { self.tcx.map.node_to_string(id).to_string() } </del> // Determines whether the given definition is public from the point of view // of the current item. fn def_privacy(&self, did: DefId) -> PrivacyResult {

Discussion:
This was working previously before . If this is an intended change, we should probably give the error where the re-export is defined and not on use of the trait.
I've noticed this too while compiling nphysics, I've narrowed it to The error is I'm using .
I'm facing the same problem for quite some time now (currently rustc 1.0.0-nightly ( 2015-01-20 23:03:09 +0000)). Is this a bug or is it intended behavior?
is this expected?
Just ran into this bug in my code, would love to see a fix for this!
Im also still running into this from time to time (rustc 1.3.0). I'd love to see it fixed or clarified whether this is intended or a bug.
I also have this with rustc nightly (from PPA: "~~wily")
I think this is a bug, actually. do you agree?
yes I realize I'm responding to a comment from Jan 28 :) a bit late, I know
this was "fixed" by but reverted by due to a regression. Personally, I think that the correct fix for the regression should be to make a privacy error, but as far as I can tell, it's not easy to implement this currently, and it's likely to cause further regressions. Trait privacy is hard :(
better late than never :heart:
yeah this looks like a bug to me, and I think is right in that is probably the right fix if we deal with , which I think is the cause of some other visibility/privacy bug around here...
This can be simplified even further to: Also an additional note, this only affects usage in the same crate. Other crates are able to use the re-exports fine.
Still a bug in 1.6 :cry:
+1
still a bug in cargo 0.8.0-nightly ( 2016-01-17)
For those who may fall on this issue, it can be bypassed by using the UFCS syntax: . For example becomes
Change:
command line options from it. These options are one per line; a blank line indicates an empty option. The file can use Unix or Windows style line endings, and must be encoded as UTF-8. <ins> ## `--passes`: add more rustdoc passes This flag is **deprecated**. For more details on passes, see [the chapter on them](passes.md). ## `--no-defaults`: don't run default passes This flag is **deprecated**. For more details on passes, see [the chapter on them](passes.md). ## `-r`/`--input-format`: input format This flag is **deprecated** and **has no effect**. Rustdoc only supports Rust source code and Markdown input formats. If the file ends in `.md` or `.markdown`, `rustdoc` treats it as a Markdown file. Otherwise, it assumes that the input file is Rust. </ins>

Discussion:
From So not sure which way seems better? What do you think ?
Yeah I think we should document the new stuff and remove the docs for the deprecated stuff (perhaps mention that these deprecated features exist, but not document them in depth)
I've felt confused about this before: Why do we even let people customize which passes are run? That seems like unnecessary entanglement with rustdoc internals.
Also, there doesn't seem to be a flag. Are you thinking of ? If so, rustdoc says that's deprecated. Edit: It looks like is deprecated as well.
What is "the new stuff"? Do you mean things like ? Other than my confusion about that, I agree with Manish here. I think we should mention the deprecated features, but not document them extensively since they shouldn't be used anyway. If we extensively document deprecated features, we are wasting our time and our readers' time.
Yes. I do think the pass infra should stay mostly internal, with specific options being exposed via specific attributes. How we construct it internally should not be something the user should ever have to care about.
Change:
use crate::infer::error_reporting::nice_region_error::NiceRegionError; use crate::infer::lexical_region_resolve::RegionResolutionError; <del> use crate::infer::{Subtype, TyCtxtInferExt, ValuePairs}; </del> <ins> use crate::infer::{Subtype, ValuePairs}; </ins> use crate::traits::ObligationCauseCode::CompareImplMethodObligation; use rustc_errors::ErrorReported; use rustc_hir as hir;

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. --(I know this is probably incorrect code, but this is what triggered the internal compiler error). <!-- 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
Assigning as and removing .
44 doesn't have the ICE.
shows that this can result in no user-facing error message. I suggest increasing priority to .
Change:
<ins> // run-rustfix #![allow(dead_code)] pub fn foo(x: &str) -> Result<(), Box<dyn std::error::Error>> { Err(format!("error: {x}")) //~^ ERROR mismatched types } macro_rules! outer { ($x: expr) => { inner!($x) } } macro_rules! inner { ($x: expr) => { format!("error: {}", $x) //~^ ERROR mismatched types } } fn bar(x: &str) -> Result<(), Box<dyn std::error::Error>> { Err(outer!(x)) } macro_rules! entire_fn_outer { () => { entire_fn!(); } } macro_rules! entire_fn { () => { pub fn baz(x: &str) -> Result<(), Box<dyn std::error::Error>> { Err(format!("error: {x}")) //~^ ERROR mismatched types } } } entire_fn_outer!(); macro_rules! nontrivial { ($x: expr) => { Err(format!("error: {}", $x)) //~^ ERROR mismatched types } } pub fn qux(x: &str) -> Result<(), Box<dyn std::error::Error>> { nontrivial!(x) } fn main() {} </ins>

Discussion:
The suggestion converts the code to: which is invalid. It should suggest: The suggestion works correctly for non-macro string values. This suggestion was introduced in . No response
It cannot be reproduced on .
I'm able to reproduce it locally. It seems to be suggesting a change in : (note the path) I assume that this is due to macro expansion. It might not be working on the playground because the playground doesn't have the component installed but that's a total guess.
The presence of only affects the human-readable rendering. The important part to me is the JSON output which has even without rust-src. Ideally it would be something closer to what it looks like with :
It seems to affect all macro expansions ():
Is the solution to just disable this suggestion for macro-expanded code? As an aside, perhaps the playground should get , especially because of its prevalence in sharing code which might need the additional context.
I think it's possible to achieve the desired output found in the description, although I'm not sure how exactly. Typically, you would use on the span to peel away the layers of macro invocations, though for that you would need to provide a parent to mark the end of the chain. doesn't need such a stopper but here its use would be incorrect if the macro call itself (e.g. ) was inside of a macro expansion. Since we don't have a parent (afaiaa), earlier I briefly tried to create a parent for via I think but that didn't work. Maybe could work, not sure. This approach is a catch-22 I believe.
Yeah, would that be the desired solution though? Can this be generalized to all the other type mismatch suggestions?
That's a good question. It was mostly an experiment to see if this specific issue can be solved with .
Change:
`hir` (the HIR), `hir,identified`, or `hir,typed` (HIR with types for each node).", "TYPE"), <del> opt::opt_u("", "show-span", "Show spans for compiler debugging", "expr|pat|ty"), </del> ]); opts }

Discussion:
Not a breaking change since it is an unstable option.
Is it already an unstable option?
this issue is saying that should be changed to . It is already an unstable option.
So can accept as arguments. How would those be specified if were changed to a ?
Hopefully exactly the same way, not sure how possible that is. If it is not possible right now, then this probably isn't an easy issue to fix. I can look into it next week.
We've got kinda our own syntax for the flags so where today you pass it could instead be
Change:
<ins> // Test to print lifetimes on HIR pretty-printing. // pretty-compare-only // pretty-mode:hir // pp-exact:issue-85089.pp trait A<'x> {} trait B<'x> {} struct Foo<'b> { pub bar: &'b dyn for<'a> A<'a>, } impl<'a> B<'a> for dyn for<'b> A<'b> {} impl<'a> A<'a> for Foo<'a> {} </ins>

Discussion:
(From the Playground.) Note that the uses of , , and don't include their lifetimes. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> include ../tools.mk all: $(RUSTC) --emit=dep-info -Zunpretty=expanded with-dep.rs $(CGREP) "with-dep.rs" < $(TMPDIR)/with-dep.d -rm $(TMPDIR)/with-dep.d $(RUSTC) --emit=dep-info -Zunpretty=normal with-dep.rs ! test -f $(TMPDIR)/with-dep.d </ins>

Discussion:
Related: (i.e. having as an actual would be nice). We use in the kernel to provide the expanded output in outputs/targets. The dependency information is not critical, but the change made our Make target fail (so we need a change on the kernel side), and it would be nice nevertheless to have the dependency information (assuming it is accurate), e.g. we also use it for similar outputs like and .
Bisection seems to lead to commit but I am not sure / cant say if really related. The mentioned issue was opened before that commit was merged :thinking: wdy?
This looks like another symptom of We'll likely keep regressing this by accident without a test. I don't know why was fixed between when it was reported and 1.68
Thanks for fixing this
Change:
<ins> error[E0619]: the type of this value must be known in this context --> $DIR/issue-42234-unknown-receiver-type.rs:17:5 | 17 |     x.unwrap().method_that_could_exist_on_some_type(); |     ^^^^^^^^^^ error[E0619]: the type of this value must be known in this context --> $DIR/issue-42234-unknown-receiver-type.rs:22:5 | 22 | /     data.iter() //~ ERROR 22:5: 23:20: the type of this value must be known in this context 23 | |         .sum::<_>() | |___________________^ error: aborting due to 2 previous errors </ins>

Discussion:
E.g., the expression with unknown type is the variable use , but the error highlight covers the entire sub-expression of . I assume this is due to us doing something sub-optimal with the spans here in the HIR lowering.
is worried that similar issues are arising with other desugarings, i.e. that this might be an across-the-board regression. Worth investigating.
: gives
triage: P-medium Doesn't seem like a "stop everything" sort of problem, but would be good to figure it out. However, it does not appear to be a regression: e.g., the above test case behaves the same in 1.16.0 as well.
Change:
<ins> use std::{usize, isize}; fn main() { match 0usize { //~^ ERROR non-exhaustive patterns //~| NOTE pattern `_` not covered //~| NOTE the matched value is of type `usize` //~| NOTE `usize` does not have a fixed maximum value 0 ..= usize::MAX => {} } match 0isize { //~^ ERROR non-exhaustive patterns //~| NOTE pattern `_` not covered //~| NOTE the matched value is of type `isize` //~| NOTE `isize` does not have a fixed maximum value isize::MIN ..= isize::MAX => {} } match 7usize {} //~^ ERROR non-exhaustive patterns //~| NOTE the matched value is of type `usize` } </ins>

Discussion:
Gives:
Fairly sure this is intentional for
From the pull I've seen a part that I didn't see/remember: An unstable feature precisepointersizematching will be to permit matching exactly on pointer-size integer types. So you're right, this isn't a new bug, it's a known unfinished part. I hope to see that precisepointersizematching implemented.
It already exists.
I see, then what do I have to hope to see? :-)
I'm not sure the feature is ever going to be stabilised, because there are concerns that this isn't a desirable feature. But hopefully the diagnostics will at least be improved in
Do you have a link to such concerns? (Or are you willing to summarize them?) (I value your work on the compiler a lot varkor :-) )
I think the relevant concerns arose in the (from this comment up). The overview is that we ought not to make assumptions about pointer sizes on the target platform, because they're not guaranteed to be fixed, so this could cause compatibility issues.
Change:
StaticKind::Promoted(promoted, promoted_substs) => { let substs = self.subst_from_frame_and_normalize_erasing_regions(promoted_substs); let instance = ty::Instance::new(place_static.def_id, substs); <ins> // Even after getting `substs` from the frame, this instance may still be // polymorphic because `ConstProp` will try to promote polymorphic MIR. if instance.needs_subst() { throw_inval!(TooGeneric); } </ins> self.const_eval_raw(GlobalId { instance, promoted: Some(promoted),

Discussion:
See https://travis- for failed build
Could you please provide a backtrace for the ICE?
cc
cc more const prop fallout?
Seems likely. I'll have some time tonight to look at it.
Minimal repro:
Cc me
Change:
<ins> // check-pass #![allow(incomplete_features)] #![feature(const_trait_impl, generic_const_exprs)] trait ConstName { const NAME_BYTES: &'static [u8]; } impl const ConstName for u8 { const NAME_BYTES: &'static [u8] = b"u8"; } const fn name_len<T: ?Sized + ConstName>() -> usize { T::NAME_BYTES.len() } impl<T: ?Sized + ConstName> const ConstName for &T where [(); name_len::<T>()]:, { const NAME_BYTES: &'static [u8] = b"&T"; } impl<T: ?Sized + ConstName> const ConstName for &mut T where [(); name_len::<T>()]:, { const NAME_BYTES: &'static [u8] = b"&mut T"; } pub const ICE_1: &'static [u8] = <&&mut u8 as ConstName>::NAME_BYTES; pub const ICE_2: &'static [u8] = <&mut &u8 as ConstName>::NAME_BYTES; fn main() {} </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. --Playing around with some more complex possibilities of const traits + checked evaluation, and ran into an ICE. I minimized it as much as I could, but I imagine this may not be the most minimal example. Uncomment the lines marked as 'Does ICE' to see the error. Playground Link: <!-- 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. --Playground Version <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Update: Further minimized example, the actual value of the constants is irrelevant, it seems the dependent where bounds are the primary issue.
It appears somewhere along the way, the playground link started working. Does this need a test, something in glacier, or any other work?