jiebi/CodeConvo huggingface dataset:
Change:
} #[test] <ins> fn test_str_slice_rangetoinclusive_ok() { let s = "abcαβγ"; assert_eq!(&s[..=2], "abc"); assert_eq!(&s[..=4], "abcα"); } #[test] #[should_panic] fn test_str_slice_rangetoinclusive_notok() { let s = "abcαβγ"; &s[..=3]; } #[test] fn test_str_slicemut_rangetoinclusive_ok() { let mut s = "abcαβγ".to_owned(); let s: &mut str = &mut s; assert_eq!(&mut s[..=2], "abc"); assert_eq!(&mut s[..=4], "abcα"); } #[test] #[should_panic] fn test_str_slicemut_rangetoinclusive_notok() { let mut s = "abcαβγ".to_owned(); let s: &mut str = &mut s; &mut s[..=3]; } #[test] </ins> fn test_is_char_boundary() { let s = "ศไทย中华Việt Nam β-release 🐱123"; assert!(s.is_char_boundary(0));

Discussion:
Caught while fleshing out a much beefier test suite for SliceIndex, which I plan to submit as a PR. (this Issue is here just in case that PR never happens). The unicode character boundary check here should be looking at . Better yet, the method could just delegate to instead. (note: it can't delegate to here without NLL, which seems to be a leading factor as to how this function ended up this way)
Not technically a regression but tagging it as such to ensure that we don't forget about it.
my commit message accidentally closed this, which might defeat the purpose of the tag you (note: I myself can't reopen it because Github attributed the message to Bors)
Oh that's ok, the tags on the PR take over now for backporting and that's how we'll track this.
(ahhhh, now I see. The tag is used in automation for a Github Project to track regressions. That's actually pretty cool!) ('t mind me, just talking to myself)
Change:
<del> Subproject commit 668c64760b5c7ea654facb4ba5fe9faddfda27cc </del> <ins> Subproject commit 72187f5cd0beaaa9c6f584156bcd88f921871e83 </ins>

Discussion:
or The examples don't compile and the list of items is outdated. Should the list at the bottom of the page still be updated? The amount of language items has grown and there's already a list . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim label: +A-lang-item
I think linking to the source code is better than trying to keep the list up to date, yes. We might still want to document the language items that are required for a binary, since those are "user facing" in a way the others aren't.
Ideally we could find a way to run rustdoc on the examples (as doctests) so they don't get outdated.
The guidance could be to the nomicon because there's already .
Change:
<del> Subproject commit 60e8413a4e5b7c67001176783893b12411ce355e </del> <ins> Subproject commit 7b8e8293d08d298579470f9d6c74731043c6601a </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
| ty::Never | ty::Dynamic(_, _, ty::DynStar) | ty::Error(_) => { <del> self.dcx().span_bug(span, format!("`{t:?}` should be sized but is not?")); </del> <ins> let guar = self .dcx() .span_delayed_bug(span, format!("`{t:?}` should be sized but is not?")); return Err(guar); </ins> } }) }

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: should be sized but is not?', 'error: internal compiler error: should be sized but is not?' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
this seems to bisect to fyi
claim
Change:
extra_features: Vec::new(), }); if let Some(miri) = miri { <ins> let mut cargo = builder.cargo(compiler, Mode::ToolRustc, host, "install"); cargo.arg("xargo"); // Configure `cargo install` path. cargo adds a `bin/`. cargo.env("CARGO_INSTALL_ROOT", &builder.out); let mut cargo = Command::from(cargo); if !try_run(builder, &mut cargo) { return; } </ins> // # Run `cargo miri setup`. <del> // As a side-effect, this will install xargo. </del> let mut cargo = tool::prepare_tool_cargo( builder, compiler,

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium. Removing I-nominated.
Change:
|         - non-const generic parameter error: attribute should be applied to a function <ins> --> $DIR/invalid-rustc_legacy_const_generics-arguments.rs:33:5 | LL |     #[rustc_legacy_const_generics(0)] |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LL |     fn foo9<const X: usize>() {} |     ---------------------------- not a function error: attribute should be applied to a function </ins> --> $DIR/invalid-rustc_legacy_const_generics-arguments.rs:25:5 | LL |     #[rustc_legacy_const_generics(1)]

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 --
minimized: I think it's just that this attr ICEs when attached to methods and not functions.
claim
Change:
"test/bench/shootout-k-nucleotide.rs", # BSD "test/bench/shootout-mandelbrot.rs", # BSD "test/bench/shootout-meteor.rs", # BSD <ins> "test/bench/shootout-nbody.rs", # BSD </ins> "test/bench/shootout-pidigits.rs", # BSD "test/bench/shootout-regex-dna.rs", # BSD "test/bench/shootout-threadring.rs", # BSD

Discussion:
See I propose to change the license of Non trivial contributors: OK OK Contributors appearing in git blame that are trivial (except artifacts as empty lines): OK OK Contributors with removed and trivial contributions are not considered. For the persons that are not in "OK" state, please respond to this issue saying: Then, I'll propose the corresponding PR. Thanks.
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license () On 07/09/2014 09:59, Daniel Micay wrote: Developer | Willing Consulting +1 760 456 9366 |
Change:
hir_map::NodeForeignItem(&hir::ForeignItem { ref attrs, span, node: hir::ForeignItemKind::Static(..), .. }) => { <del> let g = if let Some(linkage) = cx.tcx.codegen_fn_attrs(def_id).linkage { // If this is a static with a linkage specified, then we need to handle // it a little specially. The typesystem prevents things like &T and // extern "C" fn() from being non-null, so we can't just declare a // static and call it a day. Some linkages (like weak) will make it such // that the static actually has a null value. let llty2 = match ty.sty { ty::TyRawPtr(ref mt) => cx.layout_of(mt.ty).llvm_type(cx), _ => { cx.sess().span_fatal(span, "must have type `*const T` or `*mut T`"); } }; unsafe { // Declare a symbol `foo` with the desired linkage. let g1 = declare::declare_global(cx, &sym, llty2); llvm::LLVMRustSetLinkage(g1, base::linkage_to_llvm(linkage)); // Declare an internal global `extern_with_linkage_foo` which // is initialized with the address of `foo`.  If `foo` is // discarded during linking (for example, if `foo` has weak // linkage and there are no definitions), then // `extern_with_linkage_foo` will instead be initialized to // zero. let mut real_name = "_rust_extern_with_linkage_".to_string(); real_name.push_str(&sym); let g2 = declare::define_global(cx, &real_name, llty).unwrap_or_else(||{ cx.sess().span_fatal(span, &format!("symbol `{}` is already defined", &sym)) }); llvm::LLVMRustSetLinkage(g2, llvm::Linkage::InternalLinkage); llvm::LLVMSetInitializer(g2, g1); g2 } } else { // Generate an external declaration. declare::declare_global(cx, &sym, llty) }; (g, attrs) </del> <ins> let fn_attrs = cx.tcx.codegen_fn_attrs(def_id); (check_and_apply_linkage(cx, &fn_attrs, ty, sym, Some(span)), attrs) </ins> } item => bug!("get_static: expected static, found {:?}", item) }; <ins> debug!("get_static: sym={} attrs={:?}", sym, attrs); </ins> for attr in attrs { if attr.check_name("thread_local") { llvm::set_thread_local_mode(g, cx.tls_model);

Discussion:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by
Change:
.map_err(|_: ErrorGuaranteed| debug!("failed to compute implied bounds {:?}", ty)) .ok()?; debug!(?bounds, ?constraints); <ins> // Because of #109628, we may have unexpected placeholders. Ignore them! // FIXME(#109628): panic in this case once the issue is fixed. let bounds = bounds.into_iter().filter(|bound| !bound.has_placeholders()); </ins> self.add_outlives_bounds(bounds); constraints }

Discussion:
In that commit, go to folder and run (tested in nightly, stable 1.69 and stable 1.70) : <details<summary<strongBacktrace</strong</summary<p</p</details
This is causing us to leak placeholders into implied bounds. Minimized:
Change:
glob_importers: RefCell<Vec<(Module<'a>, &'a ImportDirective<'a>)>>, globs: RefCell<Vec<&'a ImportDirective<'a>>>, <ins> // Used to memoize the traits in this module for faster searches through all traits in scope. traits: RefCell<Option<Box<[&'a NameBinding<'a>]>>>, </ins> // Whether this module is populated. If not populated, any attempt to // access the children must be preceded with a // `populate_module_if_necessary` call.

Discussion:
Before (on librustc): After (on same librustc): cc
The extra RAM usage seems to be because of the AST not getting freed after the early lint checks. Not sure if this is intentional.
The AST should definitely still get freed, nobody touched , so it's not intentional (unless something about the command line options has changed?)
The performance regression in looks like it was caused by . I'll work on a fix now. I'm not sure what caused the RAM increase.
Resolution used to take about 1 seconds a few months ago in winapi and now it takes 9 seconds.
I fixed the performance regression in .
Change:
$(Q)mkdir -p $(PREFIX_BIN) $(Q)mkdir -p $(PREFIX_LIB) $(Q)mkdir -p $(PREFIX_ROOT)/share/man/man1 <del> $(Q)$(call INSTALL,$(HB),$(PHB),rustc$(X)) $(Q)$(call INSTALL,$(HB),$(PHB),cargo$(X)) $(Q)$(call INSTALL,$(HB),$(PHB),rustdoc$(X)) </del> <ins> $(Q)$(call INSTALL,$(HB3),$(PHB),rustc$(X)) $(Q)$(call INSTALL,$(HB3),$(PHB),cargo$(X)) $(Q)$(call INSTALL,$(HB3),$(PHB),rustdoc$(X)) </ins> $(Q)$(call INSTALL,$(HL),$(PHL),$(CFG_RUNTIME)) $(Q)$(call INSTALL_LIB,$(HL),$(PHL),$(CORELIB_GLOB)) $(Q)$(call INSTALL_LIB,$(HL),$(PHL),$(STDLIB_GLOB))

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:
} let fmtstr = p.parse_expr()?; <ins> let mut first = true; </ins> let mut named = false; while p.token != token::Eof { if !p.eat(&token::Comma) { <del> let mut err = ecx.struct_span_err(p.token.span, "expected token: `,`"); err.span_label(p.token.span, "expected `,`"); p.maybe_annotate_with_ascription(&mut err, false); return Err(err); </del> <ins> if first { // After `format!(""` we always expect *only* a comma... let mut err = ecx.struct_span_err(p.token.span, "expected token: `,`"); err.span_label(p.token.span, "expected `,`"); p.maybe_annotate_with_ascription(&mut err, false); return Err(err); } else { // ...after that delegate to `expect` to also include the other expected tokens. return Err(p.expect(&token::Comma).err().unwrap()); } </ins> } <ins> first = false; </ins> if p.token == token::Eof { break; } // accept trailing commas

Discussion:
See The macro claims that it expects when failing to parse a format string argument, but it actually accepts all tokens that make up expressions in that position. The simplest fix would be to use , but that causes parsing errors directly after the format string to claim that expression tokens are expected in that position are accepted, when they are not. In other words, it would be nice to get diagnostics like this: while avoiding getting diagnostics like this:
Change:
#[derive(Clone, Debug)] crate enum Usefulness<'tcx> { <del> /// Carries a list of unreachable subpatterns. Used only in the presence of or-patterns. Useful(Vec<Span>), </del> <ins> /// Carries, for each column in the matrix, a set of sub-branches that have been found to be /// unreachable. Used only in the presence of or-patterns, otherwise it stays empty. Useful(Vec<FxHashSet<Span>>), </ins> /// Carries a list of witnesses of non-exhaustiveness. UsefulWithWitness(Vec<Witness<'tcx>>), NotUseful,

Discussion:
The match remains exhaustive with highlighted pattern removed, but it does not produce any warnings: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I know where the problem comes from: this bit of code tries to handle unreachable sub-or-patterns diagnostics, but it's a bit of a hack. What remains is to come up with a better solution. claim
Change:
<ins> // unit-test: ConstProp // EMIT_MIR address_of_pair.fn0.ConstProp.diff pub fn fn0() -> bool { let mut pair = (1, false); let ptr = core::ptr::addr_of_mut!(pair.1); pair = (1, false); unsafe { *ptr = true; } let ret = !pair.1; return ret; } pub fn main() { println!("{}", fn0()); } </ins>

Discussion:
This code has UB under Stacked Borrows in Miri, but is fine with , and it should print However, under and above, it prints : cc
Here's a pure-surface Rust reproduction
any guess which MIR opt might be the culprit here?
Even more minimized reproducer: My first guess would be that some MIR analysis assumes that means that no pointer to can exist any more -- with Stacked Borrows that was true, but not with Tree Borrows. I usually push back against making Stacked Borrows assumptions in optimizations but looks like something slipped through? Cc
Even stranger, with Rust 1.69 we get . This goes back all the way to ; before that, we didn't have . Only beta and nightly without optimizations seem to do this correctly.
Does this look like the bad optimization?
yes, very much so. Specifically the is wrong, the rest then follows from that. Did ConstProp never learn that locals that have their address taken cannot be propagated?
I'm about to be busy for a few hours, so if someone else wants to bisect what changed with they should do that. I'll check back later.
I've been suspecting such a bug without managing to reproduce it for a few months. The bug is in the visitor, which mistreats place context. I can make a targeted fix in the hour.
I'm curious, how did you come up with this example?
I'm making a fuzzer targeting custom MIR :D It's still quite incomplete and currently hosted on an ETH Zürich private GitLab instance I guess I should make a public mirror on GitHub soon...
That is awesome! This is exactly the kind of stuff I was hoping to find with one.
Ah so should we report these? I think I read somewhere that custom mir is likely to get wrong and would always cause crashes then or something which is why I have ignored all of the / ICEs that I came across.
This isn't an ICE, this is a change in behavior due to enabling an optimization.
ah right sorry, I was confused with
Change:
//~^ ERROR no rules expected the token `d` bar!(Level::Error, ); //~^ ERROR unexpected end of macro invocation <ins> check!(<str as Debug>::fmt, "fmt"); check!(<str as Debug>::fmt, "fmt",); //~^ ERROR no rules expected the token `,` </ins> }

Discussion:
I don't know what to make of this error. () Errors: On stable (1.34) the output is
I'm pretty sure this is fallout from the "missing comma here" suggestion for macros, that evaluates the macro again with the current arguments but adding a comma token in between the argument tokens in different combinations to see if it would be correct. My guess is that that is causing a parse error that doesn't happen for normal things than only have one token in them. We can disable the suggestion when fully qualified paths are involved.
Change:
<del> // 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. // Check that coercions are propagated through match and if expressions. // pretty-expanded FIXME #23616 #![allow(unknown_features)] #![feature(box_syntax)] pub fn main() { let _: Box<[isize]> = if true { let b: Box<_> = box [1, 2, 3]; b } else { let b: Box<_> = box [1]; b }; let _: Box<[isize]> = match true { true => { let b: Box<_> = box [1, 2, 3]; b } false => { let b: Box<_> = box [1]; b } }; // Check we don't get over-keen at propagating coercions in the case of casts. let x = if true { 42 } else { 42u8 } as u16; let x = match true { true => 42, false => 42u8 } as u16; } </del>

Discussion:
Put (copies of?) coercematch{,calls} and related tests into run-pass-valgrind. Because our current testing infrastructure is not aggressive enough in checking that tests like this are actually behaving in a sound manner. spawned off of: (I did not attempt this in PR because I wanted to expedite landing the fix for the trans bug.)
clarified the situation to me: even if is not available on a host, the tests in will be run (just without checking them). So resolving this is probably just a matter of moving the tests over. (having said that, I am wary of the risk of injecting usage of will cause a PR to be inadvertently blocked, and thus I still want to wait to fix this until after PR lands.)
Triage: it looks like these two tests are not yet in . This should be easy to do, though which tests exactly are "related" isn't quite clear to me.
Triage: no news.
Change:
type BreakTy = ty::GenericArg<'tcx>; fn visit_ty(&mut self, ty: Ty<'tcx>) -> std::ops::ControlFlow<Self::BreakTy> { if let Some(origin) = self.0.type_var_origin(ty) <del> && let rustc_infer::infer::type_variable::TypeVariableOriginKind::TypeParameterDefinition(_, def_id) = origin.kind </del> <ins> && let TypeVariableOriginKind::TypeParameterDefinition(_, def_id) = origin.kind </ins> && let generics = self.0.tcx.generics_of(self.1) && let Some(index) = generics.param_def_id_to_index(self.0.tcx, def_id) && let Some(subst) = ty::GenericArgs::identity_for_item(self.0.tcx, self.1)

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
cc
Thanks for the ping. It seems to be that here it's not always the parent which has , sometimes its on the as-is. I'm not entirely sure when we need the (IIRC it doesn't work for my test case if I don't add ).
Now if I stick to only using and not its parent, the line ICEs on my PR's test case because it can't find the param index for the . cc sorry for the ping, but do you know if here is special somehow? The debug path for my PR's test case seems to have another layer compared to this issue's ICE example, namely . I think this is why getting for my PR test case's parent worked but not for this ICE?
going to look into this, I think using is correct and the bug is somewhere else :sweat_smile:
Change:
pub fn get_implementations_for_trait(&self, filter: Option<DefId>, result: &mut Vec<DefId>) { <ins> if self.proc_macros.is_some() { // proc-macro crates export no trait impls. return } </ins> // Do a reverse lookup beforehand to avoid touching the crate_num // hash map in the loop below. let filter = match filter.map(|def_id| self.reverse_translate_def_id(def_id)) { Some(Some(def_id)) => Some((def_id.krate.as_u32(), def_id.index)), Some(None) => return, <del> None if self.proc_macros.is_some() => return, </del> None => None, };

Discussion:
: : Steps to reproduce: This is failing when the crate attempts to import the crate (which is a crate). That is, if I modify 's file to only contain: rustc will ICE. <details<summaryBacktrace:</summary</details
I suspect this is a duplicate of , but I only count 2 #[procmacro] and 1 #[procmacro_attribute] in the repository.
The crate only has 1 and 1 . If I comment both of them out, the compiler still ICEs. The crate used to compile a couple weeks ago, so this was a fairly recent change.
To give some bounds on this: the crate compiles with . It fails with . I would bisect this with rustup to determine which nightly the issue started with, but .
Derp, I just remembered I could remove the component. Okay, doing that, I was able to bisect the nightlies: Last working version: First failing version:
I just did a git bisect, and it looks like commit (from PR ) is the source of the breakage. cc
visited for triage. Going to try to followup with . Assigning to self to keep myself honest about that claim.
also, P-high
Am looking at this.
Minified: // #[allow(unused)] // enum ProcMacroHack { // Input = (stringify!(ARGS), 0).1, // } // The problem is caused by containing "host" defids and being used in [trans]. I don't think that this field has any business containing host libraries when compiling a proc macro, but I'll ask for confirmation. [trans]:
visited for triage. Seems like PR handles this. Leaving as P-high