jiebi/CodeConvo huggingface dataset:
Change:
"src/tools/compiletest", "src/tools/tidy", "src/tools/rustdoc-gui-test", <ins> "src/tools/libcxx-version", </ins> ] [autolabel."T-infra"]

Discussion:
Spawned off of I'm not 100% sure what would be involved in such a check here, but it seems like a good thing to investigate, because the nature of the resulting bootstrap failures is super frustrating. (I'll admit, I don't know if the right thing would be to hard error out of all uses of download-ci-llvm for potentially-incompatible libstdc++, or only to hard error out for defaulting uses... but a warning seems warranted in any such cases.
I guess the problem here is that we're compiling the locally and linking that against the downloaded toolchain. A check like suggested here makes sense to me in the meantime, but I suppose long-term the "right" fix here is to get rid of any C++ code we need to separately compile by upstreaming C bindings into LLVM proper, and then we can just call those on the Rust side without any ABI issues. (FWIW, I was initially confused since we explicitly statically link in the stdcpp in the distributed I guess maybe we could also fix this by skipping linking to a local stdcpp while compiling the Rust wrapper code? Not sure if that works out.)
This is the particular line which leads to failure with download-ci-llvm when there is an ABI mismatch. In my experiment removing it resulted in linking errors on rustcdriver. I agree, this solves the problem completely without applying hacks (in my opinion, there is no simple or clean way of comparing ABI or libstd versions) on bootstrap. Maybe, for now, we should just print a warning when downloading ci llvm?
You mean always print a warning? I don't think that's a good idea, it's noisy and we generally expect that people are happy using download CI LLVM. I don't think a warning is helpful here if we can't scope it down to where it matters (in which case it can probably be an error).
Not always, only once while downloading it.
I think that falls in the same "not particularly helpful" case. Most users will miss the message, and even if they don't it's not clear how they should respond. I at least don't know how to check whether my machine has everything setup right. If we could check then we could limit the warning, in which case I'm broadly in favor of making it perhaps even a hard error.
Change:
} // Parse and strip the disambiguator from the link, if present. <del> let (path_str, disambiguator) = match Disambiguator::from_str(&link) { Ok(Some((d, path))) => (path.trim(), Some(d)), Ok(None) => (link.trim(), None), </del> <ins> let (disambiguator, path_str, link_text) = match Disambiguator::from_str(&link) { Ok(Some((d, path, link_text))) => (Some(d), path.trim(), link_text.trim()), Ok(None) => (None, link.trim(), link.trim()), </ins> Err((err_msg, relative_range)) => { // Only report error if we would not have ignored this link. See issue #83859. if !should_ignore_link_with_disambiguators(link) {

Discussion:
Consider this code: I'm not sure if this is a deliberate decision or not. If it is, what's the rationale for not accepting and ? cc
It isn't valid markdown syntax.
Well, might be. But [] definitely is not.
seems to work fine (it renders as and the link is correct). But maybe you're saying that we shouldn't accept because it wouldn't be valid markdown? Is it worth implementing?
hmm, it might be valid in that position, but it's not valid as a link reference: But I guess there's no reason for rustdoc to explicitly reject it. I would be ok with it, may have opinions.
I'm okay with it. I'm mostly wary about characters that are common in URLs, curly braces are not.
Oh, the reason why works is because the rules for inline links are more relaxed: vs So instead do you think rustdoc should parse ?

Consider this code: In the generated docs, the link on the page appears as , with the correct link, but without the parentheses.
Sorry, I stole this from you :smile:
That's okay! Thanks for fixing this :)
Change:
} impl<T> Default for T { <del> default type Id = T; //~ ERROR type annotations needed </del> <ins> default type Id = T; </ins> } fn test<T: Default<Id = U>, U>() {}

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: compiles, or a helpful error message Instead, this happened: Confusing error message, there doesn't seem to be a future that could be awaited?... Interestingly if the default implementation is removed, it compiles. Playground: <!-- 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
The error message on the playground is a bit different, seems to be correlating with the actual problem more, but even more confusing: Expected and found are the same!
Minimal: Something funky going on with the default projection predicate installed for the GAT. I'll look into it
I'm impressed by the speedy handling of this issue! Was hoping this would get a fix in a few weeks . You're awesome!
Once the pr is merged, it will be available the next day on nightly, correct? Btw, the pr failed some tests.
Change:
<ins> #![feature(edition_macro_pats)] #![allow(unused_macros)] macro_rules! foo { ($x:pat2021 | $y:pat2021) => {} } //~ ERROR `$x:pat2021` is followed by `|`, which is not allowed for `pat2021` fragments macro_rules! baz { ($x:pat2015 | $y:pat2015) => {} } // should be ok macro_rules! qux { ($x:pat2015 | $y:pat2021) => {} } // should be ok macro_rules! ogg { ($x:pat2021 | $y:pat2015) => {} } //~ ERROR `$x:pat2021` is followed by `|`, which is not allowed for `pat2021` fragments macro_rules! match_any { ( $expr:expr , $( $( $pat:pat2021 )|+ => $expr_arm:pat2021 ),+ ) => { //~ ERROR  `$pat:pat2021` may be followed by `|`, which is not allowed for `pat2021` fragments match $expr { $( $( $pat => $expr_arm, )+ )+ } }; } fn main() { let result: Result<i64, i32> = Err(42); let int: i64 = match_any!(result, Ok(i) | Err(i) => i.into()); assert_eq!(int, 42); } </ins>

Discussion:
In Edition 2021, the following should error: for the same reason that the following already errors: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I was wondering if you were interested in fixing this as a follow-up to -- I don't think you included it in that PR, right?
claim
I think the problem is here: , but if we allow , then will also be allowed. This does not seem right. But in the current function we can't yet tell what token comes next in . Do you have any suggestions?
Actually, the code may already be correct? It appears that is not allowed for , which is the goal: Maybe we just need a test -- or maybe there already is one!
Yes this part of the logic I have , but my question is about . I will add an additional test for pat2021.
I expect to be an error -- it is, right?
Yes. I see what you mean. I misunderstood your description in the issue.
Change:
Tuple(fields) => Variant::Tuple( fields .into_iter() <del> .map(|f| { if let clean::StructFieldItem(ty) = *f.kind { ty.into_tcx(tcx) } else { unreachable!() } </del> <ins> .filter_map(|f| match *f.kind { clean::StructFieldItem(ty) => Some(ty.into_tcx(tcx)), clean::StrippedItem(_) => None, _ => unreachable!(), </ins> }) .collect(), ),

Discussion:
Found via and extract into the root dir and run with rustdoc JSON is built labels +A-rustdoc-json +T-rustdoc +I-ICE +requires-nightly
modify labels: +E-needs-mcve
Same ICE can also be reproduced with which crater also found
The tzdb ice is the same issue, it also used on enum fields: Could you rename the issue? modify labels: -E-needs-mcve
Thanks for the MCVE! I'm planning to work on it tomorrow if no one did until then.
Change:
| LL |     : [u32; 5i8 as char as usize] |             ^^^^^^^^^^^ invalid cast <ins> | help: try casting from `u8` instead --> $DIR/const-eval-overflow-4b.rs:22:13 | LL |     : [u32; 5i8 as char as usize] |             ^^^^^^^^^^^ </ins> error: aborting due to 3 previous errors

Discussion:
Given the following code: The current output is: This is not very clear. There are two pieces of background information the user needs here: s are Unicode scalar values, which are any integer value from 0 to 0xD7FF and 0xE000 to 0x10FFFF. Only u8 can be statically guaranteed to meet this requirement so only u8 can be cast to char. is probably what the user wants, if they are interested in non-ASCII values. The user is directed to further information available at and , neither of which explains either of those two points. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think a good improvement would be to a) Add more detail about this to b) Add a to this error that suggests are you interested in working on one or both of those? :)
claim
While I was reading the docs I noticed a minor error in : This isn't true; a USV is a Code Point within either of two ranges, not one. It's also a bit cagey about what the ranges are numerically; I don't know if this is intentional. Personally I would re-write it to the below: Would I put that in the same PR (as they're both documentation) or a new issue?
A new PR would be better.
Change:
// Check if this is a ident pattern, if so, we can optimize and avoid adding a // `let <pat> = __argN;` statement, instead just adding a `let <pat> = <pat>;` // statement. <del> let (ident, is_simple_pattern) = match input.pat.node { PatKind::Ident(_, ident, _) => (ident, true), _ => (ident, false), </del> <ins> let (binding_mode, ident, is_simple_pattern) = match input.pat.node { PatKind::Ident(binding_mode, ident, _) => (binding_mode, ident, true), _ => (BindingMode::ByValue(Mutability::Immutable), ident, false), </ins> }; // Construct an argument representing `__argN: <ty>` to replace the argument of the

Discussion:
Code: Error: Rustc version: rustc 1.36.0-nightly ( 2019-05-02)
modify labels: A-async-await and T-compiler.
I wonder if this is related to the drop order fix desugaring?
Oops, looks like it is. Thanks for the fix.
Change:
#[derive(Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash)] #[repr(transparent)] #[rustc_layout_scalar_valid_range_start(1)] <del> #[cfg_attr(not(stage0), rustc_nonnull_optimization_guaranteed)] </del> <ins> #[cfg_attr(not(bootstrap), rustc_nonnull_optimization_guaranteed)] </ins> pub struct $Ty($Int); }

Discussion:
We should only pass stage0 in general, should be sufficient for all use cases. cc for awareness and in case there's any concerns
Change:
<ins> error[E0425]: cannot find value `num` in this scope --> $DIR/ice-unwrap-probe-many-result-125876.rs:4:24 | LL |     std::ptr::from_ref(num).cast_mut().as_deref(); |                        ^^^ not found in this scope warning: type annotations needed --> $DIR/ice-unwrap-probe-many-result-125876.rs:4:29 | LL |     std::ptr::from_ref(num).cast_mut().as_deref(); |                             ^^^^^^^^ | = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2018! = note: for more information, see issue #46906 <https://github.com/rust-lang/rust/issues/46906> = note: `#[warn(tyvar_behind_raw_pointer)]` on by default warning: type annotations needed --> $DIR/ice-unwrap-probe-many-result-125876.rs:4:40 | LL |     std::ptr::from_ref(num).cast_mut().as_deref(); |                                        ^^^^^^^^ | = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2018! = note: for more information, see issue #46906 <https://github.com/rust-lang/rust/issues/46906> error[E0599]: no method named `as_deref` found for raw pointer `*mut _` in the current scope --> $DIR/ice-unwrap-probe-many-result-125876.rs:4:40 | LL |     std::ptr::from_ref(num).cast_mut().as_deref(); |                                        ^^^^^^^^ | help: there is a method `as_ref` with a similar name | LL |     std::ptr::from_ref(num).cast_mut().as_ref(); |                                        ~~~~~~ error: aborting due to 2 previous errors; 2 warnings emitted Some errors have detailed explanations: E0425, E0599. For more information about an error, try `rustc --explain E0425`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'called on an value: NoMatch(NoMatchData { staticcandidates: [], unsatisfiedpredicates: [], outofscopetraits: [], similarcandidate: None, mode: MethodCall })'', 'thread 'rustc' panicked at 'called on an value: NoMatch(NoMatchData { staticcandidates: [], unsatisfiedpredicates: [], outofscopetraits: [], similarcandidate: None, mode: MethodCall })'' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc ^^
claim
Change:
rb.rust_root = os.path.abspath(os.path.join(__file__, '../../..')) rb.build_dir = os.path.join(os.getcwd(), "build") rb.verbose = args.verbose <ins> rb.clean = args.clean </ins> try: with open(args.config or 'config.toml') as config:

Discussion:
Errors like are happening on the bots, e.g.: This is under the covers, but rustbuild's command should blow away the build system directory ahead of time to be more resilient to bugs like this.
Change:
<ins> // We used to ICE here while trying to synthesize auto trait impls. // issue: 123370 //@ check-pass pub struct Inner<'a, Q>(&'a (), Q); pub struct Outer<'a, Q>(Inner<'a, Q>); impl<'a, Q: Trait<'a>> std::marker::Unpin for Inner<'static, Q> {} pub trait Trait<'a> {} </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. --: <!-- 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 --
probably cc
yep yep yep, I got it :) claim

<!-- 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
reduced a bit `
Ah another bug ^^. label T-compiler A-synthetic-impls A-auto-traits
reduce:
All three reproducers will be fixed by .
I can no longer reproduce any of these issues.
Change:
<ins> // revisions: llvm mir-opt3 </ins> // compile-flags: -C opt-level=3 -Z merge-functions=disabled --edition=2021 // only-x86_64 // ignore-debug: the debug assertions get in the way <ins> // [mir-opt3]compile-flags: -Zmir-opt-level=3 // [mir-opt3]build-pass // mir-opt3 is a regression test for https://github.com/rust-lang/rust/issues/98016 </ins> #![crate_type = "lib"] #![feature(portable_simd)]

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: code originally from <!-- 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. --: When compile with , there is a which does not occur with `
Due to inlining of :
does the no_mangle attr have done kind of effect? can't check on mobile right now
I think it's more likely the struct's being ignored when performing that field access. cc
A slightly simplified example: It only arises when inlining a generic function (in this case ) that bitcasts a .
The difference seems to be that bitcasts a pointer to a vector, while the inlined bitcasts a vector directly. I suspect that the extra move that happens when is inlined causes vector value to be stored behind a pointer. I can reproduce the crash using just to force an extra move. As for why puts the vector behind a pointer, the default rust abi passes vector types by-ref to ensure that changing target features doesn't change the abi.
With that crashes at and without it gives the following LLVM ir:
It's interesting that the failure (in my example) required to be generic—that shouldn't affect the ABI of the monomorphized function, should it?
Indeed. It shouldn't affect the ABI.
The original no longer crashes since , but still does
Triage: The above mentioned example now compiles fine with the latest nightly, I guess is related. Marking as .
Change:
} } <ins> for block in &mut basic_blocks.raw[..first_dead_block] { for statement in &mut block.statements { let StatementKind::Coverage(_) = &statement.kind else { continue }; let instance = statement.source_info.scope.inlined_instance(source_scopes); if !live.contains(&instance) { statement.make_nop(); } } } </ins> if live.is_empty() { return; }

Discussion:
This can be seen here: To reproduce:
Last passing run was so this regressed between 2022-06-30 and 2022-07-02.
Minimized a reproducer. : : Execution:
label regression-untriaged
Bisection says searched nightlies: from nightly-2022-06-29 to nightly-2022-07-03 regressed nightly: nightly-2022-07-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsSo,
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Unfortunately while this fixes the minimal reproducer, it doesn't fix the full case. Would you prefer I file a new bug, or should this one be re-opened? To reproduce:
It's not very minimized, but slightly better. : : Empty
searched nightlies: from nightly-2022-07-07 to nightly-2022-07-22 regressed nightly: nightly-2022-07-09 searched commits: from to regressed commit:
Interesting, I had assumed based on the matching panic message that it'd have the same regressing commit.
Happy to report that with the latest nightly we're back to green on nightly. Thanks much
Thanks the first fix was enough for Suricata :-)
Thanks so much, pydantic-core has been pinned to but is not back on nightly.
Change:
candidates .sort_by_cached_key(|c| (c.path.segments.len(), pprust::path_to_string(&c.path))); if let Some(candidate) = candidates.get(0) { <ins> let path = { // remove the possible common prefix of the path let start_index = (0..failed_segment_idx) .find(|&i| path[i].ident != candidate.path.segments[i].ident) .unwrap_or_default(); let segments = (start_index..=failed_segment_idx) .map(|s| candidate.path.segments[s].clone()) .collect(); Path { segments, span: Span::default(), tokens: None } }; </ins> ( String::from("unresolved import"), Some(( <del> vec![(ident.span, pprust::path_to_string(&candidate.path))], </del> <ins> vec![(ident.span, pprust::path_to_string(&path))], </ins> String::from("a similar path exists"), Applicability::MaybeIncorrect, )),

Discussion:
just a minor formatting logic bug I think. If a module name is missing in the middle of a chain (here is used, but is defined) the suggestion is the full path, not just the bit in the middle that is missing. No response
looks like this was fixed already, but it's not on nightly yet (or at least, not on ) on commit I see the correct output:
seems it still not be fixed in nightly.
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. // Test calling methods on an impl for a bare trait. static mut COUNT: uint = 1; trait T {} impl<'a> T+'a { fn foo(&self) { unsafe { COUNT *= 2; } } fn bar() { unsafe { COUNT *= 3; } } } impl T for int {} fn main() { let x: &T = &42i; x.foo(); T::foo(x); T::bar(); unsafe { assert!(COUNT == 12); } } </ins>

Discussion:
This code: generates this error: I couldn't find any existing issue on this, but this is expected to work, right?
cc
Was this in an RFC?
DST was pre-RFC (the design anyway), so no, it was not.
It as a good question whether this is supposed to work or not. Since traits are types now, just unsized, I would say "yes". But since an impl for a trait is no different to just providing default methods, perhaps we want to avoid that overlap. Shouldn't be hard to fix if we all agree on "yes", but cc to check he agrees.
As I understand it, an for a trait would be quite different than providing default methods: Even when a trait object is formed, there's no dynamic dispatch (vtable entries) for these methods. The methods cannot be overridden in an . The methods may also exist on the trait, in which case (according to our dispatch rules) the inherent versions would take precedence. I think the closer correspondence is to creating an extension trait with a blanket -- and given that inherent s are in some sense supposed to be equivalent to "anonymous", always-in-scope extension traits, I think that makes sense. My guess is that this was an intended, but implicit part of the DST proposal, but can speak more directly to that.
These subtle differences make me want it less. But the blanket impl-like use case seems legitimate. I agree with the intended but implicit assessment - I vaguely remember this coming up as a use case at some point
I've always assumed this would work but I'm curious was there a specific point in the libraries that required it?
IIRC this came out of playing around with the method definitions, which are currently all provided by extension traits. Not a huge deal if we can't do this for 1.0.
I started looking at this, but the hard bits seem to be some adjustment to method selection, so I'll wait on landing before doing this
I think there is some serious utility in providing this, especially for things like Any. I will try to dig up some other use-cases. Note that since is currently marked adding this later would mean deprecations etc.