jiebi/CodeConvo huggingface dataset:
Change:
span.lo < other.hi && other.lo < span.hi } <ins> /// Returns `true` if `self` touches or adjoins `other`. pub fn overlaps_or_adjacent(self, other: Span) -> bool { let span = self.data(); let other = other.data(); span.lo <= other.hi && other.lo <= span.hi } </ins> /// Returns `true` if the spans are equal with regards to the source text. /// /// Use this instead of `==` when either span could be generated code,

Discussion:
No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Short code to reproduce the issue.
Change:
FnKind::Fn(FnCtxt::Free | FnCtxt::Foreign, ..) => FnItemRibKind, FnKind::Fn(FnCtxt::Assoc(_), ..) | FnKind::Closure(..) => NormalRibKind, }; <del> let previous_value = replace(&mut self.diagnostic_metadata.current_function, Some(sp)); </del> <ins> let previous_value = replace(&mut self.diagnostic_metadata.current_function, Some((fn_kind, sp))); </ins> debug!("(resolving function) entering function"); let declaration = fn_kind.decl();

Discussion:
Hi, ... returns: () Message says , even though it does have a parameter, which is kinda confusing. This happens only on beta and nightly, since current stable doesn't provide that hint at all. Thanks, Patryk.
This happened to me on an old nightly (I believe 1.38.0 when it was still nightly, I may be wrong)
Running into this issue on latest stable as well. What is the actual problem?
I just ran into what appears to be the same issue on , in the context of a trait method.
Change:
if [ -z "${CFG_UNINSTALL}" ] then msg "verifying platform can run binaries" <ins> export $CFG_LD_PATH_VAR="${CFG_SRC_DIR}/lib":$CFG_OLD_LD_PATH_VAR </ins> "${CFG_SRC_DIR}/bin/rustc" --version > /dev/null if [ $? -ne 0 ] then err "can't execute rustc binary on this platform" fi <ins> export $CFG_LD_PATH_VAR=$CFG_OLD_LD_PATH_VAR </ins> fi fi

Discussion:
At this point, and both exist. Just in case it matters: my prefix is .
Fallout from , perhaps? This isn’t the first time we’ve had completely broken (two months ago it happened, ). Why don’t we add it to the tests done on the buildbot?
Indeed, this was predicted as a known consequence of . It may be the case that asking people to set is too much. We might need/want wrapper scripts to drive that set up such environment variables, much like other projects have.
Fixed by .
(see comment , since it is relevant to this issue.)
Change:
<ins> pub trait Tr { type VisibleAssoc; #[doc(hidden)] type HiddenAssoc; const VISIBLE_ASSOC: (); #[doc(hidden)] const HIDDEN_ASSOC: (); } pub struct Ty; impl Tr for Ty { type VisibleAssoc = (); type HiddenAssoc = (); const VISIBLE_ASSOC: () = (); const HIDDEN_ASSOC: () = (); } </ins>

Discussion:
Minimal reproducible example (on stable and nightly): Document crate and take a look at the generated pages of and : You should be able to actually see the associated type in the block despite being marked as hidden. You probably need to click (expand) first. The block I refer to is in section Implementors on the trait page and in section Trait Implementations on the implementor's page. It should be noted that even though wrongly shows up in those blocks, it is indeed not shown in the code block at the start of the trait page – at the “definition site” if you will (compared to the “use sites” – the blocks). It is crucial that the trait and the type are defined inside of an external crate. If they were defined in the “current” crate, this bug would not occur: The hidden associated items would not be shown. You can check this for yourself by documenting on its own and viewing its documentation separately, or by re-exporting the crate from (e.g. with ) and then documenting : On the page for , the associated item is hidden On the page for the re-export , however, the associated item is displayed after a CI job failed because the linkchecker complained about broken links in the standard library when documenting it with a modified rustdoc. The broken links are not relevant for this bug, they are mere symptoms of it: If everything was properly hidden, no broken links would ever be generated. This bug currently affects the standard library documentation (for stable and nightly) as mentioned in the linked comment. In this case, the trait is  the type is  the associated type that shouldn't be shown is crate “alpha” is crate “beta” is label T-rustdoc A-cross-crate-reexports <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
/// Creates an iterator that yields a pair of the value returned by this /// iterator plus the current index of iteration. /// <ins> /// `enumerate` keeps its count as a `usize`. If you want to count by a /// different sized integer, the `zip` function provides similar functionality. /// </ins> /// # Examples /// /// ```

Discussion:
Currently uses for counting. This is necessary when iterating over slices (probably the most common scenario). However, in general an iterator is not necessarily related to memory, so it may make more sense to use other integer types. It seems sensible to make generic over the integer type used for counting. This is backwards compatible, so it shouldn't break existing code. Would it be possible to make this change although is marked as stable?
nominating, like we've been doing for possible backompat-libs issue
Isn't it likely to break code where the integer type can't be inferred?
A little off-topic, but doesn't now do the exact same thing as ? We can just zip with to do with . =
Python has both of them as well, I think it is common enough to warrant its own iterator. On Tue, Feb 24, 2015, 09:30 Utkarsh Kukreti wrote:
E-needs-decision. cc 1.0 beta P-backcompat-libs.
Personally I'm inclined to keep things simple and just use here. In particular, to do otherwise would require basically adding an associated type to the trait, because we must have some way for generic wrappers like to reflect the index type of the things they are iterating over.
(The fact that zipping with provides an easy way to use other kinds of integers if you prefer is nice, though.)
Then I would honestly rather remove than having a crippled version.
itertools already has a generic (which is basically the same as zipping with ), you could possibly import that into libcore. Specifying the starting point adds another degree of customization and an obvious place to specify the integer type. For a generic I would worry it's too confusing and nonobvious how to specify the integer type to use. Standard .enumerate() is not crippled just because it's simple. It's one of a million possible iterator adaptors, and not all of them are going to be included in Rust by default.
I personally see as a common iterator adaptor which is expected in a library of iterators, so I would not want to remove it in favor of the less intuitive . I think it's fine to have the open ended range to count with an arbitrary integer, but I don't think we need to change as-is.
Well, then let's at least mention in 's documentation as the more flexible variant.

On Thu, Mar 19, 2015, 04:03 Alex Crichton wrote:
Ok after some more discussion the conclusion is that we probably don't want to make generic over integer types due to worries about inference and overcomplexity. This does seems like a worthwhile A-docs bug though, so I'm going to apply that label to ensure that we mention the alternative in the docs.
triage: P-high ()
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> impl Drop for int { </del> <ins> impl<'a> Drop for &'a mut int { </ins> //~^ ERROR the Drop trait may only be implemented on structures //~^^ ERROR cannot provide an extension implementation fn drop(&mut self) {

Discussion:
Basically, it's now possible to write: and have everything work. This unfortunately means that doing something like with a will zero b, but not move it. /cc
I noticed this possibility too and was debating if this is a problem. It's not clear to me. Probably best to disallow it for now.
at the very least, it's causing incorrect behaviour at runtime, since it's zeroing out types like a move, but not forbidding the use of them like a copy.
Looks unsafe to me: Program received signal SIGSEGV, Segmentation fault. 0x0000555555598e5c in ()
I agree that combining it with zeroing is unsafe. If zeroing did not occur, or we did not zero for types that were copy, there wouldn't necessarily be a problem.
Anyhow, it's easiest to forbid it for now. We can always make it legal later if someone comes up with a persuasive use case. Idempotent destructors seem like a bit of an odd thing.
Change:
<ins> error[E0080]: could not evaluate static initializer --> $DIR/static_mut_containing_mut_ref3.rs:5:31 | LL | static mut BAR: () = unsafe { FOO.0 = 99; }; |                               ^^^^^^^^^^ tried to modify a static's initial value from another static's initializer error: aborting due to previous error For more information about this error, try `rustc --explain E0080`. </ins>

Discussion:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // error-pattern:stop // #18576 // Make sure that an calling extern function pointer in an unreachable // context doesn't cause an LLVM assertion #[allow(unreachable_code)] fn main() { panic!("stop"); let pointer = other; pointer(); } extern fn other() {} </ins>

Discussion:
The following causes an LLVM assertion failure: Removing the panic! prevents the assertion failure.
I minimized it some more: The Option<and the #![no_std] don't matter, it's specifically attempting to call an extern fn pointer after a panic! that causes the crash.
Change:
} } <ins> let terminator = bb.terminator(); </ins> // remove StorageDead (if it exists) being used in the assign of the comparison for (stmt_idx, stmt) in bb.statements.iter().enumerate() { if !matches!(stmt.kind, StatementKind::StorageDead(local) if local == opt.to_switch_on.local) { continue; } <del> storage_deads_to_remove.push((stmt_idx, opt.bb_idx)) </del> <ins> storage_deads_to_remove.push((stmt_idx, opt.bb_idx)); // if we have StorageDeads to remove then make sure to insert them at the top of each target for bb_idx in new_targets.iter() { storage_deads_to_insert.push(( *bb_idx, Statement { source_info: terminator.source_info, kind: StatementKind::StorageDead(opt.to_switch_on.local), }, )); } </ins> } <ins> let terminator = bb.terminator_mut(); terminator.kind = TerminatorKind::SwitchInt { discr: Operand::Move(opt.to_switch_on), switch_ty: opt.branch_value_ty, values: vec![new_value].into(), targets: new_targets, }; </ins> } for (idx, bb_idx) in storage_deads_to_remove {

Discussion:
The following program runs fine in Miri on mir-opt-levels 0-2, but in level 3 it errors: The error is: Looks like something changes the liveness ranges of locals and it does so incorrectly. Cc
Could you describe affected rustc version and reproduction steps?
The rustc version is commit , but most likely a nightly will also do it. To reproduce, run this in a Miri checkout:
The SimplifyComparisonIntegral introduces StorageDead for a local which didn't have any markers before. Currently this also makes the local dead on the entry to the function. Related to the issue about semantics of StorageLive without matching StorageDead (this would be the reverse).
The LLVM docs for their version of (which the Rust thing translates to) So just introducing a without also having appropriate is pretty clearly wrong, I would say.
That is the doc for , not . The doc for is:
oops sorry, yeah. We'd have to check the MIR here to see if it makes any sense at all; however, currently I think not just Miri but also our dataflow framework assumes that variables with any liveness annotations are initially dead.
Diff for this case before/after SimplifyComparisonIntegral: Note the placed in both successors of the , when there was no to begin with. cc -- along the lines of , you could leave the as a copy in this case for later optimisation passes to clean up. This is definitely a case I can cover for .
Does this analysis ensure that is not used any more afterwards? As in, would it be sufficient to add a in the start block? (I am not saying that that's a good fix, just trying to feel out the design space here.) I guess I am also surprised that an "integral comparison simplification" pass touches storage liveness.
That part is my fault. I incorrectly assumed that there's a storagedead before the switch. Maybe there is one in some situations, idk, if there is, we should probably just not do the optimization instead of rewriting the storage markers.
Should this be marked as I-unsound?
Assigning as discussed as part of the . modify labels: +P-medium -I-prioritize
Error: Label P-medium can only be set by Rust team members Please let know if you're having trouble with this bot.
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub fn foo(params: Option<&[&str]>) -> uint { params.unwrap().head().unwrap().len() } fn main() { let name = "Foo"; let msg = foo(Some(&[name.as_slice()])); //~^ ERROR mismatched types: expected `core::option::Option<&[&str]>` assert_eq!(msg, 3); } </ins>

Discussion:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

(Doesn't happen with .)
Paging
Here's a truly minimal test case:
cc me
Variation: This gives a different error message:
Fixed in Can be closed.
Change:
debug!("{}.super_relate_consts(a = {:?}, b = {:?})", relation.tag(), a, b); let tcx = relation.tcx(); <del> let a_ty; let b_ty; if relation.tcx().features().adt_const_params { a_ty = tcx.normalize_erasing_regions(relation.param_env(), a.ty()); b_ty = tcx.normalize_erasing_regions(relation.param_env(), b.ty()); } else { a_ty = tcx.erase_regions(a.ty()); b_ty = tcx.erase_regions(b.ty()); } if a_ty != b_ty { relation.tcx().sess.delay_span_bug( DUMMY_SP, &format!( "cannot relate constants ({:?}, {:?}) of different types: {} != {}", a, b, a_ty, b_ty ), ); } </del> // HACK(const_generics): We still need to eagerly evaluate consts when // relating them because during `normalize_param_env_or_error`, // we may relate an evaluated constant in a obligation against

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</detailsThis occurred in code different from the above but this is a minimal example that causes this failure. I believe I am disobeying some rules in the manner in which is not bound in the underlying type of the trait. This bug appeared in my own code that worked with a previous nightly build. That code does bind into the underlying type and still fails. If I bind it in this example with the following changes: the error goes away. I will need to create a minimal example that produces an ICE closer to the failure in my own code but I was struggling to do this. This is at least one ICE of interest and perhaps the unbound should itself be prevented. I'm not entirely sure. Worthy of note, the following also compiles fine: which omits all of the stuff.
I've isolated it to the following commit range: ..
I determined it was due to the above linked-from PR.
Prior to this PR, the above code would emit the following warning instead of generating the ICE:
This is caused by the fact that acts sort of like a const item with a const param ty the references other generic parameters: . When we relate the in we constrain infer vars to be the same as eachother but do not end up actually resolving the infer vars before relating so the assertion that const param ty's are sees two different infer vars instead of the resolved ones.
Change:
/// This may not be the same as `link` if there was a disambiguator /// in an intra-doc link (e.g. [`fn@f`]) pub(crate) link_text: String, <del> pub(crate) did: DefId, </del> <ins> /// The `DefId` of the Item whose **HTML Page** contains the item being /// linked to. This will be different to `item_id` on item's that don't /// have their own page, such as struct fields and enum variants. pub(crate) page_id: DefId, </ins> /// The url fragment to append to the link pub(crate) fragment: Option<UrlFragment>, }

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. --field contains wrong IDs for some kind of items. Items for which no independent HTML is generated (link target URL is ) appear to have incorrect IDs. I tried this code: I expected to see this happen: contains the IDs of link targets Instead, this happened: contains the ID of the items containing the link targets <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: +A-rustdoc-json +T-rustdoc +A-intra-doc-links
claim
Change:
<ins> error[E0658]: a non-static lifetime is not allowed in a `const` --> $DIR/issue-64173-unused-lifetimes.rs:16:23 | LL |     beta: [(); foo::<&'a ()>()], |                       ^^ | = note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information = help: add `#![feature(generic_const_exprs)]` to the crate attributes to enable error: generic `Self` types are currently not permitted in anonymous constants --> $DIR/issue-64173-unused-lifetimes.rs:4:28 | LL |     array: [(); size_of::<&Self>()], |                            ^^^^ error[E0392]: parameter `'s` is never used --> $DIR/issue-64173-unused-lifetimes.rs:3:12 | LL | struct Foo<'s> { |            ^^ unused parameter | = help: consider removing `'s`, referring to it in a field, or using a marker such as `PhantomData` error[E0392]: parameter `'a` is never used --> $DIR/issue-64173-unused-lifetimes.rs:15:12 | LL | struct Bar<'a> { |            ^^ unused parameter | = help: consider removing `'a`, referring to it in a field, or using a marker such as `PhantomData` error: aborting due to 4 previous errors Some errors have detailed explanations: E0392, E0658. For more information about an error, try `rustc --explain E0392`. </ins>

Discussion:
When trying to compile the following code, a panic occurs on :
Also happens on nightly
ICE reproduces all the way back to 1.36.0; before that, it still ICEs but in a different place.
Maximal reduction: ICE arises in: Blame: cc
I suspect this is a duplicate of . But the test case is slightly different so I'll leave it open for now
triage: P-medium (via analogy with priority on ), removing nomination label.
Triage: This is no longer ICE with the latest nightly:
Change:
parser_double_colon_in_bound = expected `:` followed by trait or lifetime .suggestion = use single colon <ins> parser_fn_ptr_with_generics = function pointer types may not have generic parameters .suggestion = consider moving the lifetime {$arity -> [one] parameter *[other] parameters } to {$for_param_list_exists -> [true] the *[false] a } `for` parameter list </ins>

Discussion:
Newcomers might attempt to write a “generic” function pointer like . In such case, the compiler should provide a better error message. Inspired by a recent Reddit thread I sadly cannot find anymore. Given the following code: The compiler should mention that function pointers may not be generic or […] may not have generic parameters, suggest to move the lifetime(s) to a parameter list (this should be machine-applicable in my judgement) and be able to recover: For later reference, the current output is: Given the following code: The compiler should mention that function pointers may not be generic or […] may not have generic parameters and be able to recover emitting two diagnostics, one for each line. The compiler could also suggest moving the generic parameter list further up to the owning function, struct, etc. if available. Note that this might not be what the user intended (since there is a semantic difference between hypothetical higher-ranked generics and normal ones) and therefore shouldn't be machine-applicable. For later reference, the current output is: label A-parser A-suggestion-diagnostics D-newcomer-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<del> error[E0752]: start is not allowed to be `async` </del> <ins> error[E0752]: `start` is not allowed to be `async` </ins> --> $DIR/issue-68523-start.rs:6:1 | LL | pub async fn start(_: isize, _: *const *const u8) -> isize { <del> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ start is not allowed to be `async` </del> <ins> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `start` is not allowed to be `async` </ins> error: aborting due to previous error

Discussion:
Crash occurs in both 1.46.0 beta and in current nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I made the false assumption that this was rustc crashing, but it's actually the binary that crashes upon running it.
Cc We probably just want to ban track caller on main (and maybe any lang item function?)
claim
Same with : results in edit: I think is a more general problem so I won't change that here
Assigning as and removing .