jiebi/CodeConvo huggingface dataset:
Change:
<ins> pub mod foo { pub mod bar { pub fn do_the_thing() -> usize { 42 } } } fn main() { println!("Hello, {}!", crate::bar::do_the_thing); //~ ERROR failed to resolve: unresolved import } </ins>

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:
pub fn SetLastError(dwErrCode: DWORD); pub fn GetCommandLineW() -> *mut LPCWSTR; <del> pub fn LocalFree(ptr: *mut c_void); pub fn CommandLineToArgvW(lpCmdLine: *mut LPCWSTR, pNumArgs: *mut c_int) -> *mut *mut u16; </del> pub fn GetTempPathW(nBufferLength: DWORD, lpBuffer: LPCWSTR) -> DWORD; pub fn OpenProcessToken(ProcessHandle: HANDLE,

Discussion:
An showed that removing the dependency from LLVM speed up its test suite by a huge amount. For us libstd doesn't depend on directly but it does depend on which depends on (according to the blog post). Specificaly it looks like , the same function as LLVM, is used by us! It'd be great to investigate removing the shell32 dependency from libstd (may be a few other functions here and there). We should run some tests on Windows to see if this improves rustc cycle times!
Based on my limited investigation, it's likely that replacing with a pure Rust equivalent should be good enough to get rid of the gdi32 dependency in things that only use libstd. So really someone just needs to write that pure Rust implementation which should be easy to do.
It would be nice to get rid of this in the compiler too. We spawn a lot of compiler instances during bootstrapping.
So now that the change has been implemented, have we actually investigated how much of an impact the change made?
Perf, an lolbench are both linux only. So nether help with this question. So don't waste your time like I did.
Here are just number for on 8 cores / 16 threads on Windows 10 v1809: Without the dependency: 333.012 325.587 320.650 With : 310.852 319.165 323.645
For what it's worth, though there's no good way to differentiate PR-to-PR due to very high variance, it does look like there was a recent regression in PR build times: <img width="1409" alt="image" src="https://user-"
I see that the CPU usage averages about 40% when running , so maybe we'd see some real improvements if we got rid of in the compiler too. Something is certainly holding things back.
Yeah, I saw that the compiler doesn't load . So there's probably some other reason why doesn't load all the cores.
Change:
let ast::Path { ref segments, span } = *path; let path: Vec<_> = segments.iter().map(|seg| respan(seg.span, seg.identifier)).collect(); let invocation = self.invocations[&scope]; <del> self.current_module = invocation.module.get(); </del> <ins> let module = invocation.module.get(); self.current_module = if module.is_trait() { module.parent.unwrap() } else { module }; </ins> if path.len() > 1 { if !self.use_extern_macros && self.gated_errors.insert(span) {

Discussion:
Given this procedural macro: and this crate: Building: I saw no output :( I find that is resolved, it just doesn't seem to get expanded!
cc
I saw this earlier and I've been thinking about it. I don't remember anything special in the invocation collector concerning trait methods though. Isn't there some codepath that strips attributes from trait methods, stuff like that doesn't make sense on them?
Not that I know of -- I'll do some debugging to figure out where the issue is (, , etc.).
Ok I've debugged this a bit and I think I've narrowed it down to resolve. The attribute is first resolved as and then resolved as which triggers to I think fill in a "dummy" invocation, which ends up effectively stripping the item. Still trying to figure out why this isn't resolved right.
In attempting to debug further I think I'm pretty far out of my league here. I think what's happening is that resolution is attempting to resolve in the "trait's namespace", but that predictably fails and it in theory should go up to the parent module namespace and then do resolution there again, right? What I've found though is that is returning because while the trait does have a parent which presumably points to the crate's module they both have an of . The loop in currently enforces which means that it can't go up one level. Does that ring any bells or Or maybe this is all a red herring?
Haven't looked into this yet, but this explanation makes sense. I believe the issue here is that shouldn't be called with a trait module. enforces for modules since in the normal, non-hygienic case, modules don't have lexical parents (except for the prelude). That is, However, due to hygiene, the following resolves: If this issue is as I expect, I can fix quickly tomorrow.
Ah ok, I'll leave you to it as I suspect you'll find it much more quickly than I will! If you run out of time though just let me know and I will resume digging!
Change:
<ins> // run-rustfix trait TraitWithAType { type Item; } trait Trait {} struct A {} impl TraitWithAType for A { type Item = dyn Trait; //~ ERROR E0277 } fn main() {} </ins>

Discussion:
Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: A similar error message with an unsized generic type argument does mention the implicit bound. Unfortunately, it also doesn't explain the implicit bound up front in the "required by this bound" text. (It mentions it when suggesting to relax the implicit bound, but I think it would be better to mention it up front as well.) Both error messages could benefit from changing the "required by this bound" text to "required by an implicit bound". <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-associated-items +A-traits +A-typesystem +D-papercut +D-terse
I'm working on a pull request for this issue. claim
Oh! Very sorry, if you spent too much time on this already, but I have done some work around this already in If you want, you can take over it and bring it to completion, there are some cases, like that still need to be addressed and I haven't yet figured out. Alternatively, if you can find a way to accomplish the same result without touching the and instead deal only with a new , that would be preferable to my approach.
I've pushed what I have so far to , sorry if it conflicts with stuff you've already done. If you'd like to take a look at it, that would be great. I'll take a look at what you have as well. There are some issues to be worked out with conflicting suggestions for associated types for vs the existing suggestion for adding an explicit to a trait's bounds, in test cases such as within a trait declaration.
Change:
scapegoat: ty::t) { let mut offset = 0; for &llty in fields.iter() { <del> // Invariant: offset < ccx.max_obj_size() <= 1<<61 </del> <ins> // Invariant: offset < ccx.obj_size_bound() <= 1<<61 </ins> if !packed { let type_align = machine::llalign_of_min(ccx, llty); offset = roundup(offset, type_align); } <del> // type_align is a power-of-2, so still offset < ccx.max_obj_size() // llsize_of_alloc(ccx, llty) is also less than ccx.max_obj_size() </del> <ins> // type_align is a power-of-2, so still offset < ccx.obj_size_bound() // llsize_of_alloc(ccx, llty) is also less than ccx.obj_size_bound() </ins> // so the sum is less than 1<<62 (and therefore can't overflow). offset += machine::llsize_of_alloc(ccx, llty); <del> if offset >= ccx.max_obj_size() { </del> <ins> if offset >= ccx.obj_size_bound() { </ins> ccx.report_overbig_object(scapegoat); } }

Discussion:
LLVM does not support objects larger than bytes, because it represents sizes as counts of bits. Currently, to be safe, I'm blocking compile-time objects bigger than 2 GiB (in case LLVM uses an int count of bytes somewhere). It would be nice to find out how much can we increase this, especially on 64-bit targets.
bounds object size by 2 GiB on 32-bit architectures and 128 TiB () on 64-bit architectures.
Change:
} } <del> pub(in super::super) fn suggest_missing_return_expr( </del> <ins> pub(in super::super) fn suggest_missing_break_or_return_expr( </ins> &self, err: &mut DiagnosticBuilder<'_>, expr: &'tcx hir::Expr<'tcx>,

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: Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --It may not be immediately clear to a user why implicit-return/break style works for expressions, but not for . Adding a hint to explicitly break with would be helpful. <!-- 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 --
label +A-suggestion-diagnostics
claim
Change:
/// /// [`with_capacity`]: ../ffi/struct.OsString.html#method.with_capacity /// [`OsString`]: ../ffi/struct.OsString.html <del> #[unstable(feature = "path_buf_capacity", issue = "58234")] </del> <ins> #[stable(feature = "path_buf_capacity", since = "1.44.0")] </ins> pub fn with_capacity(capacity: usize) -> PathBuf { PathBuf { inner: OsString::with_capacity(capacity) } }

Discussion:
, should probably not be stabilized before , see
Happy to take this on as a first contribution to rust.
Great! I'd be happy to help you get started, just let me know if you want mentoring/instructions at any level!
are you able to define a list of the methods that need to be implemented as part of this PR?
I think all of these will essentially call the underlying functions on . [ ] [ ] [ ] [ ] [ ] [ ] [ ] -- this one is more of a maybe, since it's unstable on OsString. We can reuse the same tracking issue for this. We'll probably want to add all of these under the same feature gate.
thanks for that. I have the implementation drafted locally. I'm having some difficulty however in running the tests for stdlib - even a is producing errors not related to my changes. Is there any documentation I've missed for best practices on compiling / working on stdlib?
You'll want to use x.py; for your scenario I believe and/or are the commands you want. I'm not sure where the most current documentation is.
describes how to use .
Triage: since has been merged, can this be closed?
No, this is now the tracking issue for the stabilization of those APIs.
Reviewing this since then, I think it may be worth removing these APIs and replacing them with something like and . These aren't really commonly used so hiding them as such seems reasonable and is less heavy.
I'd love to see these stabilized. I have a tool that manipulates lots of paths, so I'd like to avoid needless reallocations. I generate lots of temporary paths in a loop. would work nicely to reuse the buffer. I need to concatenate several components. I know their length, so I could use I want to store lots of paths for later. is a bit smaller than , but if I can't reserve exact capacity, will reallocate.
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See for info about what commands tagged team members can give me.
reviewed assuming we're only stabilizing capacity + withcapacity + clear + reserve + reserveexact + shrinktofit;&ensp;and shrink_to is being moved to instead.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
I've posted a stabilization PR in .
Change:
Applicability::MachineApplicable, ); } <ins> } else { let printable: Vec<char> = lit .chars() .filter(|&x| { unicode_width::UnicodeWidthChar::width(x).unwrap_or(0) != 0 && !x.is_whitespace() }) .collect(); if let [ch] = printable.as_slice() { has_help = true; handler.span_note( span, &format!( "there are non-printing characters, the full sequence is `{}`", lit.escape_default(), ), ); handler.span_suggestion( span, "consider removing the non-printing characters", ch.to_string(), Applicability::MaybeIncorrect, ); } </ins> } if !has_help {

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 -- (which has a zero width space between the and its ending ) The current output is: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --If there are any non-printing characters, show where they are (debug unicode representation on the whole string, maybe?), and if there's only one printing character, make a suggestion to remove everything but the printing character. <!-- 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 --
claim
Change:
<ins> enum Either { One(X), Two(X), } struct X(Y); struct Y; fn consume_fnmut(f: &dyn FnMut()) { f(); } fn move_into_fnmut() { let x = move_into_fnmut(); consume_fnmut(&|| { let Either::One(_t) = x; //~ ERROR mismatched types let Either::Two(_t) = x; //~ ERROR mismatched types }); } 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
searched toolchains through Regression in
Alternative: As long as the variants for and are different.
label +S-bug-has-mcve
This ICE caused by different root cause.
Change:
| DefKind::AssocTy | DefKind::TyParam | DefKind::ConstParam <ins> | DefKind::LifetimeParam </ins> | DefKind::Fn | DefKind::Const | DefKind::Static(_)

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. --cc still crashes after <!-- 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 --
Sigh, yeah, this is just the same bug but for lifetime params. I'll fix it, shouldn't be too hard. claim
Hey, , thanks for getting this fixed! Unfortunately, I seem to be running into the same issue (or a very similar one) using the latest nightly, and I've not been able to create a standalone reproducer: <details<summaryBacktrace</summary<p</p</detailsSorry if this is the wrong place to be reporting this ICE, but I wasn't sure whether to file a new issue or maybe get one of the resolved issues re-opened. Thank you!
Change:
fn_metadata: DISubprogram, argument_counter: Cell<uint>, source_locations_enabled: Cell<bool>, <ins> source_location_override: Cell<bool>, </ins> } enum VariableAccess<'a> {

Discussion:
Rust version: OS: Gentoo Linux AMD64
cc
The same thing happens with openssl-sys 0.4.1:
For anyone running into this, you can disable debug info to work around the issue until it's fixed:
Same problem here. Rust version: rustc 1.0.0-nightly ( 2015-02-17) (built 2015-02-18) Operating System: OS X Yosemite 10.10.2
It looks like I have the same problem: Compiling mio v0.2.1 () Running 1:1 error: internal compiler error: debuginfo: Could not find scope info for node NodeExpr(Expr { id: 5326, node: ExprStruct(Path { span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() }, global: false, segments: [PathSegment { identifier: StaticMutex, parameters: AngleBracketedParameters(AngleBracketedParameterData { lifetimes: [], types: [], bindings: [] }) }] }, [Field { ident: Spanned { node: lock, span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }, expr: Expr { id: 5327, node: ExprPath(Path { span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() }, global: false, segments: [PathSegment { identifier: sys, parameters: AngleBracketedParameters(AngleBracketedParameterData { lifetimes: [], types: [], bindings: [] }) }, PathSegment { identifier: MUTEXINIT, parameters: AngleBracketedParameters(AngleBracketedParameterData { lifetimes: [], types: [], bindings: [] }) }] }), span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }, span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }, Field { ident: Spanned { node: poison, span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }, expr: Expr { id: 5328, node: ExprPath(Path { span: Span { lo: BytePos(0),

hi: BytePos(0), expnid: ExpnId() }, global: false, segments: [PathSegment { identifier: poison, parameters: AngleBracketedParameters(AngleBracketedParameterData { lifetimes: [], types: [], bindings: [] }) }, PathSegment { identifier: FLAGINIT, parameters: AngleBracketedParameters(AngleBracketedParameterData { lifetimes: [], types: [], bindings: [] }) }] }), span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }, span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }], None), span: Span { lo: BytePos(0), hi: BytePos(0), expnid: ExpnId() } }) #![allow(noncamelcasetypes, nonuppercaseglobals, nonsnakecase)] ^ Rust version: rustc 1.0.0-nightly ( 2015-02-17) (built 2015-02-18) OS: 3.13.0-24-generic -Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x8664 x8664 x86_64 GNU/Linux
A minimized version:
Minimized a bit further actually, perhaps you could publish a version which uses instead of on the vector of ?
Er, nevermind, I have against rust-openssl to temporarily fix this.
I encountered a similar problem with constants in match patterns. This very probably has the same root cause, which is that the AST of constants gets substituted for the constant-reference during trans, but then we suddenly have a bunch of unrelated AST node ids in there. I'll try to fix this this week.
My minimal case:
Change:
<ins> // Regression test for #70934 fn f() { const C: [S2; 1] = [S2]; let _ = S1(C[0]).clone(); //~^ ERROR cannot move out of type `[S2; 1]` } #[derive(Clone)] struct S1(S2); #[derive(Clone)] struct S2; fn main() { f(); } </ins>

Discussion:
I get an ICE when I try to build : I tried stable, beta and nightly. All ended with an ICE.
Important detail: Only happens on the branch, not
(bisecting)
It happens with master branch as well if I do before building. Without it, it fails due to nalgebra issue before it even gets to evolvim-lib.
Ah, I see
regression in nightly-2019-08-17
great :). Unsure if you're bisecting this further, anyway pinging cleanup crew in case you are not doing it further and also to see if someone is able to get an mcve. 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
There don't seem to be any prebuilt artifacts for that commit range, so I've stopped there.
Assigning meanwhile we don't have an mcve as .
() Errors: modify labels to -E-needs-mcve
The reduced example regresses at nightly-2019-09-29 (..). Edit2: For me, evolvim (develop branch) regresses on that nightly, too. <br<br<details<summary<del<ttgit log</tt<iafter bisection</i</del</summary</detailsEdit3: Damn it, recompiling didn’t make realize that the code had to be recompiled and I didn’t really notice that it had just skipped compilation entirely all the time.
Even smaller: () Errors: <details</details
regression in commit (part of ) cc modify labels: -E-needs-bisection
Error: Label ICEBreaker-Cleanup-Crew can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Label ICEBreaker-Cleanup-Crew can only be set by Rust team members Please let know if you're having trouble with this bot.
Now that we have an -- thanks -- let's prioritize again
prioritize -- just testing the command
Error: This issue has already been requested for prioritization. Please let know if you're having trouble with this bot.

prioritize -- just testing the command
Looks like this compiles but it shouldn't: Dumping the MIR for this you get: Presumably, what should happen here is: The occurs here: cc
This issue is already prioritized as removing label.
I guess we need to track down where [S; 1] is emitted and make that code also look at the MIR of promoteds. We can't avoid that code from getting promoted without getting into an unfun game of whack-a-mole in the promotion code.
The error is constructed here: which is called here: and here:
hmmm... not sure what borrowck does to promoteds. I mean we basically declared all lifetimes to be static, but the same is true for the body of constants which we do run borrowck on. So... let's try to just run borrowck on promoteds and see how it goes.
alternatively we just run the logic on promoteds instead of full borrowck, as the latter may have a significant perf impact.