jiebi/CodeConvo huggingface dataset:
Change:
let outputs = OutputTypes::new(&[(OutputType::Exe, None)]); let sessopts = config::Options { <del> maybe_sysroot: maybe_sysroot.or_else( || Some(env::current_exe().unwrap().parent().unwrap().parent().unwrap().to_path_buf())), </del> <ins> maybe_sysroot, </ins> search_paths: libs, crate_types: vec![config::CrateType::Executable], output_types: outputs,

Discussion:
On OpenBSD, the function fails if the binary is not invoked with a full path (see ). This leads to the following crash when running doc tests: Note that this using rustc/cargo 1.33.0, installed on OpenBSD 6.5 using its native package (). The offending code, I believe, must be one of the calls in , which are both unwrapped, and have to do with figuring out the sysroot, if not already known. The issue can be worked around by adjusting the command line like this: I guess solving this completely may be tricky, but I think the code should definitely not panic, and ideally cargo/rustdoc would issue an error message pointing (OpenBSD) users to the workaround.
It seems that simply using the code of from would be an improvement over using directly; the latter is patched on OpenBSD to consider the environment variable; see .
Change:
// lldbg-check:[...]$0 = vec![1, 2, 3] // lldbr-check:(alloc::vec::Vec<i32>) v = vec![1, 2, 3] // lldb-command:print zs <del> // lldbg-check:[...]$1 = StructWithZeroSizedField { x: ZeroSizedStruct, y: 123, z: ZeroSizedStruct, w: 456 } </del> <ins> // lldbg-check:[...]$1 = StructWithZeroSizedField { x: ZeroSizedStruct[...], y: 123, z: ZeroSizedStruct[...], w: 456 } </ins> // lldbr-check:(issue_22656::StructWithZeroSizedField) zs = StructWithZeroSizedField { x: ZeroSizedStruct { }, y: 123, z: ZeroSizedStruct { }, w: 456 } // lldbr-command:continue

Discussion:
The test has the following failing assertion: Note the , so this is for an LLDB that is not rust-enabled. Here's what I see in the failing test stdout: <details<summaryFull dump</summary</detailsSo, it seems like LLDB 8 - even without built-in Rust support - does a better job than older versions when printing that local. It only fails to resolve the local var name . It could be that we think there's something off about my local lldb. If not, and lldb 8+ is just doing a better job by default, we may need to refine the conditional assertions in the debuginfo tests, since they depend on debugger version. Platform: x86-64 Linux Distro: Void Linux lldb: 8.0.0 My lldb version string: Note the absence of the string , which is what we look for in to set .
cc I wonder if this is the no-assertions equivalent to
Maybe this could be fixed by making the check a bit more lenient. can be used as a wildcard in the check patterns. would you mind giving this a try locally by changing the check to: That version should work for both old and new versions of LLDB.
Using code from comment above does fix the error for LLDB 8.0.1.
I'd be happy to r+ a PR providing that fix.
Change:
match *self { MonoItem::Fn(ref instance) => { let entry_def_id = tcx.entry_fn(LOCAL_CRATE).map(|(id, _)| id); <del> // If this function isn't inlined or otherwise has explicit // linkage, then we'll be creating a globally shared version. if self.explicit_linkage(tcx).is_some() </del> <ins> // If this function isn't inlined or otherwise has an extern // indicator, then we'll be creating a globally shared version. if tcx.codegen_fn_attrs(instance.def_id()).contains_extern_indicator() </ins> || !instance.def.generates_cgu_internal_copy(tcx) || Some(instance.def_id()) == entry_def_id.map(LocalDefId::to_def_id) {

Discussion:
Code: If the function is marked as , it doesn't get compiled into the dll file: The reason a function may be marked as both and is so that it gets inlined when compiling the crate as a rust library, but not inlined when compiling the crate as a cdylib. There should be a warning to use something like instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Related to - I think is that we should include 'd functions in s and s, but as a short term solution, a warning is a nice idea
claim

I currently use Rust to generate a static library for FFI consumption. In some public interfaces, I call other FFI public interfaces as primarily a wrapper with a few tweaks. I'd like to mark these "inner" functions as inline, however, this seems to cause them to not show up in the final staticlib. Given this drastically simplified example: The function makes it to the static library, but the function does not: If I remove the attribute, we see both functions in the static lib: The don't seem to hint that can prevent / items from surviving all the way to the final library, or that they shouldn't be used together. I would expect any function marked and/or should be present in the final artifact, regardless of attributes. I see this behavior on stable, as well as a recent nightly. I don't know if this is a regression, as this is the first time I've run into this. Thanks! Edit: Simplified profile settings, they are not needed to reproduce. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tried with = same result
I’ve noticed this for a while but I always assumed it was intended... It would be really nice if this was fixed
This appears to have been done deliberately: Maybe it shouldn't apply to s.
Expanding on note, I would also expect this not to apply to s as well (I used the staticlib for my example, but my use case generates code for both static and dynamic library usage).
I think I'm going to take this on claim
Change:
} h3.impl, h3.method, h3.type { margin-top: 15px; <ins> padding-left: 15px; </ins> } h1, h2, h3, h4,

Discussion:
When pressing the hotkey on type's documentation such as on the , the methods of the are still shown. This is however mostly useless information that gets in the way of scrolling to see what traits a type implements. It would be more ergonomic if would hide every method of every trait but still show all associated items (types and consts) for each (since they carry useful information). In addition, a / link should be on all the s (including non-trait impls) either besides or to the left of the (as done with s this expands and collapses the impls but keeps associated items shown.
I can rewrite this as an RFC if required, but I was unsure about the protocol wrt. rustdoc.
Similar request:
Closing as resolved.

For example, looking at the docs for , some important trait implementations are hard to find in between all the implementations for each size of fixed-size arrays: Hopefully these impls will eventually become generic, but in the meantime we should consider some way of hiding or collapsing them in the docs.
cc
Dupe of
Change:
impl<'tcx> From<&LayoutError<'tcx>> for Err { fn from(err: &LayoutError<'tcx>) -> Self { match err { <del> LayoutError::Unknown(..) | LayoutError::ReferencesError(..) => Self::UnknownLayout, </del> <ins> LayoutError::Unknown(..) | LayoutError::ReferencesError(..) | LayoutError::NormalizationFailure(..) => Self::UnknownLayout, </ins> LayoutError::SizeOverflow(..) => Self::SizeOverflow, LayoutError::Cycle(err) => Self::TypeError(*err), <del> err => unimplemented!("{:?}", err), </del> } } }

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'not implemented: NormalizationFailure(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. }), Type(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. })))'', 'thread 'rustc' panicked at 'not implemented: NormalizationFailure(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. }), Type(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. })))'' 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: [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2024-08-22 seems to bisect to
Slightly more reduction:
(Note that this reduction should drop the feature gate, as this ICEs without the feature gate)
claim
Change:
find_testable_code(&dox, &mut tests, ErrorCodes::No, false, None); <del> if tests.found_tests == 0 { </del> <ins> if tests.found_tests == 0 && rustc_feature::UnstableFeatures::from_environment().is_nightly_build() { </ins> if should_have_doc_example(&item.inner) { debug!("reporting error for {:?} (hir_id={:?})", item, hir_id); let sp = span_of_attrs(&item.attrs).unwrap_or(item.source.span());

Discussion:
As of , the lint is no longer working. /// let x = 1; /// I expected to see this happen: should issue Instead, this happened: No warnings emitted. This appears to have changed in . I don't see any discussion there about this, so I'm guessing it was unintentional. cc
This was definitely unintentional. I thought I a test for this ...
Hmm, it tests with but not with . Maybe the name_ of the lint wasn't registered?
The issue is . Compiletest runs with RUSTC_BOOTSTRAP set. I don't recall off the top of my head how to force a test to be stable.
Wait now I'm confused. I thought the point of this lint was that it only runs on nightly, because we're not sure if we want to stabilize it. cc
are you sure this used to work?
The lint has been on stable since 1.32. It is documented .
Got it, I mixed it up with . Yeah this is a bug then - the two lints should be treated differently.
Actually it looks like I introduced the opposite bug for - it now runs on beta when it shouldn't.
Assigning as and removing .
Change:
op: PlaceOp, expr: &hir::Expr<'_>, base_expr: &hir::Expr<'_>, <del> arg_tys: &[Ty<'tcx>], </del> ) { <del> debug!("convert_place_op_to_mutable({:?}, {:?}, {:?}, {:?})", op, expr, base_expr, arg_tys); </del> <ins> debug!("convert_place_op_to_mutable({:?}, {:?}, {:?})", op, expr, base_expr); </ins> if !self.typeck_results.borrow().is_method_call(expr) { debug!("convert_place_op_to_mutable - builtin, nothing to do"); return;

Discussion:
I tried to compile this code: I expected the code to compile Instead, it failed to compile with this lifetime error: If I change the function in these ways it compiles. This compiles successfully on Stable Rust 1.45.0 back to 1.26.0 (when lifetimes were stabilized) This fails to compile on these versions(haven't tried previous ones in the same channels): 1.46.0-beta.2 (2020-07-23 ) 1.47.0-nightly (2020-07-28 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Let’s find the culprit for this. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Assigning as and removing .
Regressed in which is a roll-up, likely
cc in case you want to fix this is a follow-up of
The explicit lifetimes are edit: the lt of doesn't matter
assigning to but they will probably need to delegate as there time is limited in near future.
Will look into this today. claim
This code compiles in Rust 1.17 but not in Rust 1.18+: unifies DerefMut/IndexMut to use the "fix-up" path originally used when performing method calls, so it broadens the bug to assignments as well.
Okay, this is an issue near convertplaceoptomutable. Just re-infer the index type and re-do the coercion is sufficient to fix the regionck failure (). However I am not sure why the existing code does not work. This piece of code is last touched in . cc do you have any clue why the existing approach does not work well with regionck?
Hmm.. I would not have expected that code to have to change, since the failure seems to try to make the anonymous lifetime on in the method match , which it should not. I think your patch is sound, but touching the "wrong" thing.

Basically now we are creating new lifetimes for the index, when I would have thought that the container type's reference's lifetime needs adjustment. So looking at , I'm guessing is taking the wrong region and should instead invent a new one?
This issue is not related to anonymous lifetime actually, if you spell out the lifetime explicitly it's still the same. The root cause has been identified and that line actually is the culprit, a detailed analysis can be found in .
I a couple of examples of workarounds that allowed the function to compile, with the same signature.
Change:
} fn d() -> X<X<String, String>, String> { <del> X { </del> <ins> let x = X { </ins> x: X { x: "".to_string(), y: 2, }, y: 3, <del> } </del> <ins> }; x </ins> } fn e() -> X<X<String, String>, String> { <del> X { </del> <ins> let x = X { </ins> x: X { x: "".to_string(), y: 2, }, y: "".to_string(), <del> } </del> <ins> }; x </ins> } fn main() {}

Discussion:
fails to type check, while succeeds.
This coercion is important when using byte string literals.
The tuple struct case is actually the function call "expected type" propagation, which would have to be adapted to struct literals as well.
Yes.
Coercion already happens in non-generic struct literals:
Yes, but the field types are taken from the struct and not combined with the overall expected type for the struct literal.
I just discovered this bug/unexpected behavior today (). I would like to see some movement on it because it's surprising that these two don't work the same way. Here's a workaround I found; it's ugly as hell but I'm using it in a generated file that no human would want to look through anyway: I tried type ascription but it seems to not cue coercion, it just moves the type error: It seems that forcing a concrete type on the struct literal works as well (I didn't expect this syntax to work, honestly): Unfortunately this won't work for me because I'm using too and I can't add this extra syntax myself.
Any news on this?
Is anyone working on it?
It seems like implemented a partial fix in but suggests that there are backwards incompatibility issues to be considered that preventing him from going further. I'm not quite sure what he had in mind there, perhaps he can elaborate.
Making sure we remember to look at this.
What I did is I computed a "light hint" (which becomes "strong hint", i.e. forcing coercion, if it reaches a block, and it's enough to help integer inference for ). This is a common problem with coercion hints, in that unless there's enough type information to prevent them from triggering, they will trigger early even if that breaks later on. The thing to try here is to replace with the simpler: doesn't even need to be computed if that works, since is at least as specific - AFAICT, we already have that "specificity" with function calls, but since it hasn't been used with struct literals before, crater/cargobomb might reveal regressions.
ok, I was mostly wondering if you encountered actual regressions in practice, or just theorize that this might lead to problems.
I don't think I got the chance to do a crater run and then I lost track of it.
will open a PR and we can try a crater run at least.

There is still a similar problem with the type inference of temporaries when you have an array that should be interpreted as a slice buried in a tuple inside an outer slice.
Change:
if probably_big or verbose: print("downloading {}".format(url)) <del> platform_is_win32 = sys.platform == 'win32' </del> try: if probably_big or verbose: option = "-#"

Discussion:
I tried this: I expected to see this happen: Bootstrap rebuilds the compiler. Instead, this happened: <!-- 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. --is
In particular, this happens when rust-analyzer is running in the background and you have this config set: We currently recommend that config in https://rustc-dev-
This would be fixed by having a "public" and "private" sysroot: https://rust-
This happens because Windows doesn't allow deleting a running executable/DLL. The way forward would be to special-case it as it is already the case with the file and ignore failures, or to make a double sysroot as you proposed.
You can usually rename a running executable so it may be possible to simulate a delete by moving it within the same filesystem. However, having a public and a private sysroot seems like a more generally useful solution.
I'm happy with both solutions. I think special casing proc-macro-server in the short term seems fine, but if we do that, we should open another issue for the public and private sysroot.
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // error-pattern:expected macro name without module separators </del> fn main() { <del> globnar::brotz!(); </del> <ins> globnar::brotz!(); //~ ERROR expected macro name without module separators ::foo!(); //~ ERROR expected macro name without module separators foo::<T>!(); //~ ERROR expected macro name without module separators </ins> }

Discussion:
is valid syntax and compiles to a regular vector. This is because macros use s, not s as their names. Multi-segment paths are disallowed, but the path can have type parameters. We can move macros to s, however this would not be backwards compatible since anyone using would get a syntax error (even though the original syntax is meaningless). It's still a bug, so perhaps we can get away with this breaking change. Thoughts? cc
I'd say fix it and do a crater run.
Sounds like a plan to me
Ping?
I don't think anyone worked on it. In case someone wants to work on it, the two relevant points are and . It should be possible to error if the path is absolute, has more than one component, or any lifetime/type parameters. We can then do a crater run to see if these are used in the wild for some reason.
cc
I fixed this in .
Change:
<ins> fn digit() -> str { return {}; //~^ ERROR: mismatched types [E0308] } fn main() { let [_y..] = [box 1, box 2]; //~^ ERROR: cannot find value `_y` in this scope [E0425] //~| ERROR: `X..` patterns in slices are experimental [E0658] //~| ERROR: box expression syntax is experimental; you can call `Box::new` instead [E0658] //~| ERROR: box expression syntax is experimental; you can call `Box::new` instead [E0658] //~| ERROR: pattern requires 1 element but array has 2 [E0527] } </ins>

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: We shouldn't show here. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
without
another one 
What ideal output would you suggest? Should we remove the suggestion line like:
Ideally we should be checking that the return type . If it's not suggestable, don't mention it.
claim
I actually believe that neither the E0029 nor the E0277 should have been emitted. I would check explicitly for and change the error to be (that way the error isn't printed out, but rustc will ICE if no other error is emitted, which should have happened).
The PR will prevent E0029 and E0277 from printing out after checking the type references.
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-94176.rs:5:32 | LL | pub fn test(a: Option<u32>) -> Option<u32> { |        ----                    ^^^^^^^^^^^ expected enum `Option`, found `()` |        | |        implicitly returns `()` as its body has no tail or `return` expression | = note:   expected enum `Option<u32>` found unit type `()` help: consider returning the local binding `a` | LL ~     println!("Foo"); LL +     a | error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

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: A helpful error message pointing to the end of the block. Instead, this happened: An error message with a wrong span: <!-- 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 labels: +T-compiler +F-let-else +requires-nightly +A-diagnostics
Let's try that again... label +T-compiler +F-let-else +requires-nightly +A-diagnostics
FTR this is the error for the equivalent:
I wonder how is affecting this, as this seems to be a bug in the desugaring and that PR changes it. what is the error output with your PR applied? Does it fix the issue? If so, maybe adding a test to your PR would be helpful.
I meant caused by the desugaring, not in the desugaring.
It won't fix it. This needs a bit of work I think, to push the error further inside the if-let-else branch, so the span marked is the implicit return expression or lack thereof, which is (in the source code) further down in the block.
Hmm if you move the println into the , it gives a similar error to the one emitted by : gives
That's because you have only now reproduced the actual desugaring.
Change:
$(CFG_PANDOC) $(HTML_OPTS) --output=$@ DOCS += doc/tutorial.tex <del> doc/tutorial.tex: $(D)/tutorial.md doc/version.md </del> <ins> doc/tutorial.tex: $(D)/tutorial.md doc/footer.tex doc/version.md </ins> @$(call E, pandoc: $@) $(Q)$(CFG_NODE) $(D)/prep.js $< |  $(CFG_PANDOC) $(TEX_OPTS) --output=$@

Discussion:
Per we should have the docs licensed correctly. Nominating.
I can have a look at this.
Change:
for print in &sess.opts.prints { if print.kind == PrintKind::LinkArgs { <del> let content = format!("{cmd:?}"); </del> <ins> let content = format!("{cmd:?}n"); </ins> print.out.overwrite(&content, sess); } }

Discussion:
Running with doesn't include a trailing so the next shell prompt gets smooshed on: I can't imagine this is intentional since all other options seem to include the newline. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +E-easy +A-cli +T-compiler -needs-triage
claim