jiebi/CodeConvo huggingface dataset:
Change:
impl Step for Assemble { type Output = Compiler; <ins> const ONLY_HOSTS: bool = true; </ins> fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { <del> run.never() </del> <ins> run.path("compiler/rustc") } fn make_run(run: RunConfig<'_>) { run.builder.ensure(Assemble { target_compiler: run.builder.compiler(run.builder.top_stage + 1, run.target), }); </ins> } /// Prepare a new compiler from the artifacts in `stage`

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've lost so much of my life to this. It looks like the critical missing line is . I would expect this to happen whenever I pass .
The part of emitting is , which is called by . The bit emitting 'Copy ...' is . Notably, does not_ call .
This does not fix the issue and I'm not sure why:
It looks like bootstrap mistakenly thinks that the compiler has been linked and is cached.
So this is still a bug, but it turns out it wouldn't do what I want anyway because it doesn't build . So it would only be able to build crates with (basically nothing).
Yeah you want something like build --stage 1 src/libcore (though we don't support separate crate builds currently, but we could). I think it's not possible today to get bootstrap to copy the compiler but not build anything with it - the compiler itself isn't considered an artifact in some sense.
Right, this issue is asking that to change. I think this would still be useful for what I'm doing now which is only printing the AST and not even doing name resolution ().
Once this is fixed, the docs for in rustc-dev-guide () should be moved to .
Change:
- [abi_sysv64](abi-sysv64.md) - [abi_unadjusted](abi-unadjusted.md) - [abi_vectorcall](abi-vectorcall.md) <ins> - [abi_x86_interrupt](abi-x86-interrupt.md) </ins> - [advanced_slice_patterns](advanced-slice-patterns.md) - [alloc_jemalloc](alloc-jemalloc.md) - [alloc_system](alloc-system.md)

Discussion:
see I'm happy to help mentor anyone who wants to fix this issue.
Hello, I would like to work on this issue.
I would love to work on this and be mentored as well in case topecongiro can not. Thank you!
got sent in, so maybe we can work together on some other issue? Just let me know, happy to help you help me.
That would be great, thank you so much would love to work with you.
Awesome. Maybe jump on IRC and message me? Or comment in another issue marked E-mentor? Whatever works
Awesome! What is your nick on IRC? Mine is jhorwitz
same as github: steveklabnik
Change:
[[package]] name = "clippy" <del> version = "0.0.166" </del> <ins> version = "0.0.171" </ins> dependencies = [ "cargo_metadata 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)", "clippy-mini-macro-test 0.1.0", <del> "clippy_lints 0.0.166", "compiletest_rs 0.2.10 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "clippy_lints 0.0.171", "compiletest_rs 0.3.1 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "duct 0.8.2 (registry+https://github.com/rust-lang/crates.io-index)", "lazy_static 0.2.9 (registry+https://github.com/rust-lang/crates.io-index)", "regex 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)",

Discussion:
branch: master Compiling cargometadata v0.2.3 Compiling clippylints v0.0.166 (file:///home/ryan/git/rust/src/tools/clippy/clippylints) error: :vis fragment specifier is experimental and subject to change (see issue ) --<declarelint macros:1:3 | 1 | ( NAME : ident , desc : expr ) =( | ^^^^^^^^^^^ | = help: add #![feature(macrovismatcher)] to the crate attributes to enable error: :vis fragment specifier is experimental and subject to change (see issue ) --<declarelint macros:1:3 | 1 | ( NAME : ident , desc : expr ) =( | ^^^^^^^^^^^ | = help: add #![feature(macrovismatcher)] to the crate attributes to enable error: aborting due to previous error error: aborting due to previous error error: Could not compile . warning: build failed, waiting for other jobs to finish... error: Could not compile . warning: build failed, waiting for other jobs to finish... error: build failed This failure is expected (see ) Build completed successfully in 1:46:49
Everything is actually fine, as you can see by the last two lines of the log. I hope to remove the error log if the failure is expected in the future, but not sure yet how best to do that.
Is it related to rust-lang-nursery/rust-clippy?
Change:
fn is_never(this: TyAndLayout<'a, Self>) -> bool; fn is_tuple(this: TyAndLayout<'a, Self>) -> bool; fn is_unit(this: TyAndLayout<'a, Self>) -> bool; <ins> fn is_transparent(this: TyAndLayout<'a, Self>) -> bool; </ins> } impl<'a, Ty> TyAndLayout<'a, Ty> {

Discussion:
The types and do not have the same ABI, as demonstrated by this testcase: The first is The second is Not sure whom to ping for RISC-V issues.
I think the fix will have to be to treat repr(transparent) unions specially somewhere around here
Cc
I'm afraid that the semantics of on unions are not clearly defined enough to figure out exactly how they should be specially treated (which variant should be used? etc.). Can you ping other people who have more knowledge on this? (If on unions turns out to be incompatible with ABIs that have content destructuring semantics that depends on the types of the field in the (e.g. the RISC-V C psABI) then we definitely have a bigger problem.)
I have no idea who would know anything about RISC-V calling conventions. :shrug: and no other ABI is failing this test. Basically, when the ABI description says "unions do X", then this should only apply to repr(C) and repr(Rust) unions. A repr(transparent) union must be treated exactly like its non-ZST field.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
I haven't seen the Rust representation before - is the example saying that is splitting the values into float and integer registers and passing them, whereas is treating the whole thing as an bigger opaque integer? If so then based on section 18.2 here, I think the first one would be correct, assuming Rust doesn't ever make its tuples opaque helped me with something RISC-V at some point so may know where to look. Or deferring to clang
I honestly don't know what that means, it is sadly mostly undocumented. But I know it must be the same for the types to be ABI-compatible. has been opened to fix this issue.
now that this is fixed, is there a CI test to catch regressions?
There is a test in  but we don't run tests for riscv, since it's a tier 2 target.
Also see for another ABI issue that affects riscv (and more).
Are tier 2 tests run once before release or anything like that? It seems like at least a subset of tests (this one) are important enough that we should raise a red flag if we brake them somehow on any targets.

But that doesn't fit well into the tiering structure...
I'm not aware of any process like that. Part of the point of being tier 2 is not to burden all contributors with keeping the target working, is it? If we do want to accept that burden, we could consider running something like for tier 2 targets. But having this discussion in a closed issue makes little sense. Do you want to open a new issue or Zulip thread for discussing tier 2 target test coverage?
Inspired by I found a way to have a test for this:
Awesome! Thanks for the update here
Change:
for target in TARGETS .iter() .map(|target| Target::expect_builtin(&TargetTriple::from_triple(target))) <ins> .chain(iter::once(current_target.clone())) </ins> { values_target_os.insert(Symbol::intern(&target.options.os)); values_target_family

Discussion:
doesn't seem to know that custom targets can extend the set of values. The following creates a custom spec with a . No warning Got the warning: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
<ins> pub trait TraitEngine<'tcx>: 'tcx {} pub trait TraitEngineExt<'tcx> { fn register_predicate_obligations(&mut self); } impl<T: ?Sized + TraitEngine<'tcx>> TraitEngineExt<'tcx> for T { //~^ ERROR use of undeclared lifetime name `'tcx` //~| ERROR use of undeclared lifetime name `'tcx` fn register_predicate_obligations(&mut self) {} } fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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 --
claim
are you working on this?
yes
Change:
let (dest, ret) = match ret { None => match intrinsic_name { sym::transmute => throw_ub_format!("transmuting to uninhabited type"), <ins> sym::unreachable => throw_ub!(Unreachable), </ins> sym::abort => M::abort(self)?, // Unsupported diverging intrinsic. _ => return Ok(false),

Discussion:
Currently one cannot call in constant functions, so one cannot add hints of the form: These types of hints can heavily influence code generation, which can substantially change the performance of when they are invoked at run-time. It would be a shame to have to write and call and because the code generated for is sub-par. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
One cannot do any sort of conditional control flow, so would currently be less than useless. Any test you can write would be undefined behaviour
the RFC for / in const was merged and is pending an implementation right? When that's implemented, will still be useless?
No it makes sense after we have conditional control flow.
As I understand / in const functions is now implemented. Can be made into a now?
yes. Basically you just need to add the attribute to the intrinsic and wrapper function. This is documented at https://rustc-dev- Let me know if anything is unclear (in which case we should update the guide)
Hi, It looks like previous PR is not being worked on currently. I'm working on this and will create a PR soon. claim
As mentioned in , this issue should be reopened (to track stablization)
cc ^
After a short discussion on Zulip, it was decided that it's best to wait for to stabilize to avoid a potential footgun wherein users use this instead of , leading to UB at runtime. I'm subscribed to the issue and intend to file a PR to stabilize this once the aforementioned happens.
Change:
<ins> fn takes_option(_arg: Option<&String>) {} fn main() { takes_option(&None); //~ ERROR 4:18: 4:23: mismatched types [E0308] let x = String::from("x"); let res = Some(x); takes_option(&res); //~ ERROR 8:18: 8:22: mismatched types [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. 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: The error is correct, but I think the diagnostic is wrong. The second recommendation to call is sound, but the first one () seems like bad advice. This reproduces on 1.61 (on my workstation), as well as 1.63 (stable channel in playground), 1.64 (beta channel in playground), and 1.65 (nightly channel in playground). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Intresting.. This code also make wrong help, The current output is: Using is a bad advice.
claim
Change:
if let Some(block) = recover_block_from_condition(self) { block } else { <ins> let let_else_sub = matches!(cond.kind, ExprKind::Let(..)) .then(|| IfExpressionLetSomeSub { if_span: lo }); </ins> self.sess.emit_err(IfExpressionMissingThenBlock { if_span: lo, <del> sub: IfExpressionMissingThenBlockSub::AddThenBlock(cond_span.shrink_to_hi()), </del> <ins> missing_then_block_sub: IfExpressionMissingThenBlockSub::AddThenBlock( cond_span.shrink_to_hi(), ), let_else_sub, </ins> }); self.mk_block_err(cond_span.shrink_to_hi()) }

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: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest removing the additional keyword in front of the . This mistake can occur due to muscle memory as , , and in the future are somewhat similar syntactically. Thanks. label +D-confusing +F-let-else <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think the current suggestion is valid. Because one writes instead of writing . So the suggestion if changed maybe fall-negative.
We should likely add an alternative suggestion to remove the , but keep both. I think that the current suggestion is likely going to be the more common situation, so it should still come first.
claim
What would be the best way to go about adding an alternate suggestion? I'd like to try my hand at this. What I think needs to be done is adding help text to , add a variant to , and then add something to to add the alternate after the primary suggestion. Is this a good starting point?
it sounds like you are in the right path.
I looked a bit into this issue and have already found where to add text to the and the as mentioned, but i am a bit overwhelmed how and where to start in the in the . Does anyone have a hint for me?
claim
claim
You can add instructions in the parser to track your progress.

I'm not sure about the specifics out of the top of my head here of what type each step in the parse is, but you will have successfully parsed the , the condition and then you'll encounter an token when a body/block was expected. That's where the new recovery should kick in, pointing at the span saying that you might want to remove it.
claim
Change:
error: aborting due to 5 previous errors <del> Some errors have detailed explanations: E0277, E0310, E0478. </del> <ins> Some errors have detailed explanations: E0277, E0478. </ins> For more information about an error, try `rustc --explain E0277`.

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 slightly better error message Instead, this happened: A slightly confusing error message <!-- 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
Change:
<ins> // build-pass // compile-flags: -Cdebuginfo=2 --crate-type=rlib // Fixes issue #94998 pub trait Trait {} pub fn run(_: &dyn FnOnce(&()) -> Box<dyn Trait + '_>) {} </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. -- rust- <!-- 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 --
works fine, but crashes with ICE.
This is probably a duplicate of .
My guess is this is caused by . Specifically cc
(That might not be the cause though)
No, you're probably right I'll either erase regions during candidate assembly or use something infcx-local to probe if something is Copy. claim
Compiling with debug assertions on should be able to pinpoint exactly where things go wrong.
Bisecting this lead to though cc
Actually, I do agree that this is probably not due to . I can still fix this though, unless you're gonna take a look at it?
feel free to take a look. might be relevant here too (although it does look like a different problem).
Welp sorry
For either of the two Michaels looking at this: big thanks to for the from . ()
Here's a minimization I left on a duplicate issue: Note that without this does not ICE.
Marking as P-critical, since this seems to be getting hit by several people.
Also changing title and pinning to try to help curb some duplicates.
any solution!, I am still facing same error when i try to build
No, the PR that fixes this is blocked on a CI issue, which will not likely be resolved until tomorrow at this rate. You may find a temporary fix by downloading an old nightly revision with (e.g.) and setting that as your default for the time being, but please make sure to set it back later. Or, if your project does not use any nightly-only features, I recommend using or releases for now.
Thanks!
Same error!

thread 'rustc' panicked at 'assertion failed: !value.hasescapingboundvars()', /rustc/compilerrustcmiddlesrcty note: rustc 1.61.0-nightly ( 2022-03-16) running on x86_64-pc-windows-msvc note: compiler flags: --crate-type lib -C embed-bitcode=no -C debuginfo=2
Pinning this at least for a day or so, since the nightly with the fix hasn't even been released.
Change:
<del> A type or lifetime parameter that is specified for `impl` is not constrained. </del> <ins> A type parameter that is specified for `impl` is not constrained. </ins> Erroneous code example:

Discussion:
Unconstrained lifetime parameters are actually allowed: Unlike what's described here: For comparison, unconstrained type parameters do generate error:
I would like to address this. What should be error message for E0207?
Maybe just don't mention lifetime parameter?
I think this has been fixed already. Can you please try again?
I don't think it has been: still mentions lifetime parameter.
Sorry My bad. I missed checking this file. Let me fix and raise PR.
Thanks :+1:
Change:
/// /// [drop check]: ../../nomicon/dropck.html #[lang = "phantom_data"] <ins> #[structural_match] </ins> #[stable(feature = "rust1", since = "1.0.0")] pub struct PhantomData<T:?Sized>;

Discussion:
Given: results in: Is this intentional due to some soundness issue with having it otherwise? (I cannot think of any...) We could fix this by attaching to manually. While having be structurally matchable is quite boring and useless on its lonesome it prevents other types that contain it from being structurally matchable. (not likely to occur very often, but when it occur it seems like it would be annoying...) r? cc
Change:
/// Extract LLD flavor name from the lld-wrapper executable name. fn get_lld_flavor(current_exe_path: &Path) -> Result<&'static str, String> { <del> let stem = current_exe_path.file_stem(); Ok(match stem.and_then(|s| s.to_str()) { </del> <ins> let file = current_exe_path.file_name(); let stem = file.and_then(|s| s.to_str()).map(|s| s.trim_end_matches(EXE_SUFFIX)); Ok(match stem { </ins> Some("ld.lld") => "gnu", Some("ld64.lld") => "darwin", Some("lld-link") => "link", Some("wasm-ld") => "wasm", <del> _ => return Err(format!("{:?}", stem)), </del> <ins> _ => return Err(format!("{:?}", file)), </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: and this happened: I expected to see this happen: it would compile my crate. Instead, this happened: lld failed. <!-- 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. --: fixed the problem that I reported in There seems to be a new problem with an unknown linker name. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Could you post the list of files in the directory in Rust distribution?
I found in the clang invocation:
It looks like maybe clang replaces and changes it from to when calling lld-wrapper?
I can't confirm whether that's the case right now, but if that's true then the fix would be as simple as adding the alternative to in lld-wrapper.
Apple ships its linker as . I couldn't find a file.
I believe the issue is with the usage of in the PR, see: You probably meant to use . Wait. is because of Windows? is the only one that does not play well with it. One solution is to normalise the string or before the match statement.
This is not happening only on osx. I can reproduce this. The path is correct and unchanged by clang, but it's indeed the call that trims too much on unixes because of the weird executable name with a dot. I'll fix it.
The problem still exists, but the error changed to on macos. Need more investigation..
Change:
// edges.  But this was not actually sound without // other constraints that we stopped enforcing at // some point. <del> while let Some(prev) = prev_guards.pop() { self.add_contained_edge(prev, guard_start); </del> <ins> if let Some((prev_guard, prev_index)) = prev_guard.take() { self.add_exiting_edge(prev_guard, prev_index, match_scope, guard_start); </ins> } // Push the guard onto the list of previous guards <del> prev_guards.push(guard_exit); </del> <ins> prev_guard = Some(guard_exit); </ins> // Update the exit node for the pattern <del> pat_exit = guard_exit; </del> <ins> pat_exit = guard_exit.1; </ins> } // Add an edge from the exit of this pattern to the

Discussion:
ICE with the borrow checker on nightly. Tried on stable/beta and it correctly errors with in nightly, I get : Backtrace:
Reduced: cc
Bisected this one to and , that is, PR . cc
Change:
// @!has type_layout/trait.MyTrait.html 'Size: ' pub trait MyTrait {} <ins> // @has type_layout/enum.Variants.html 'Size: ' // @has - '2 bytes' // @has - '<code>A</code>: 0 bytes' // @has - '<code>B</code>: 1 byte' pub enum Variants { A, B(u8), } // @has type_layout/enum.WithNiche.html 'Size: ' // @has - //p '4 bytes' // @has - '<code>None</code>: 0 bytes' // @has - '<code>Some</code>: 4 bytes' pub enum WithNiche { None, Some(std::num::NonZeroU32), } </ins>

Discussion:
introduced a basic section on layout information, with only one piece of information: the total size of the type. I think one useful but easy extension to this is reporting the size of each variant for an enum. cc The "Layout" section is rendered in The variable is a .In that case we have access to an . The part will give us the size of the variant To get the name of the variant, we'll need the stored in , which we can hopefully get from . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think we could just look up the to find the name (there's probably a function for that). Also, it might be worth showing the sizes of each union field.
claim