jiebi/CodeConvo huggingface dataset:
Code change:
<ins> error: the `wait` method cannot be invoked on a trait object --> $DIR/issue-35976.rs:20:9 | LL |         fn wait(&self) where Self: Sized; |                                    ----- this has a `Sized` requirement ... LL |     arg.wait(); |         ^^^^ | help: another candidate was found in the following trait, perhaps add a `use` for it: | LL | use private::Future; | error: aborting due to previous error </ins>

Related discussion:
text: <!-- 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 following is not always necessary. --Ideally the output should suggest -ing the out-of-scope trait, similar to E0599: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --Someone tried to do dynamic dispatch between two underlying used a boxed trait object (with the type spelled , so wasn't in scope) and call the method on the boxed reader, and it was unclear from the error why the method wasn't accessible: <!-- 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. --This is reproducible on nightly (rustc 1.67.0-nightly ( 2022-12-01)).
Note: A sign there may be a problem worth fixing here is the code I wrote is a near copypaste of a top stack overflow answer for a :)
So, after some investigating, this appears to be a regression of , which essentially the same suggestion I proposed here: adding a for the trait object's trait. When generating the error when the lookup fails, the trait is initially included in the list of candidates, but it's filtered out by this (because the callee is the trait method, and so the parent of the callee is the trait, which is the candidate): This was introduced in by which also removed the corresponding suggestion from the test's expected output. It's not immediately clear to me from the PR () why this change was necessary. If the call is removed, the only UI test that fails is the one. Reverting that change would fix this issue, but I'm not sure if there are other cases I'm missing.
Code change:
<ins> error: the `wait` method cannot be invoked on a trait object --> $DIR/issue-35976.rs:20:9 | LL |         fn wait(&self) where Self: Sized; |                                    ----- this has a `Sized` requirement ... LL |     arg.wait(); |         ^^^^ | help: another candidate was found in the following trait, perhaps add a `use` for it: | LL | use private::Future; | error: aborting due to previous error </ins>

Related discussion:
text: (cc with whom I was discussing this on Mastodon)
Haven't look at this yet, maybe I misinterpreted what was achieving, and that commit just needs a revert -- can't recall why I did that.
Yeah, lol, I totally overlooked that the would be load-bearing due to the way we treat trait methods on as inherent. I'll revert , modify the test, etc.
Code change:
"rustc_data_structures", "rustc_hir", "rustc_hir_pretty", <ins> "rustc_lexer", </ins> "rustc_middle", <del> "rustc_parse", </del> "rustc_session", "rustc_span", "serde_json",

Related discussion:
text: contains a function, which allows to to, well, retokenize existing span: There's only caller of this function: And there's only one caller of that caller: In other words, the only reason why we need is to get the span of hir::Usewhich happens to be a glob import. ( rls needs to know the span of use foo:: with explicit list of imported items" code action. This was the first demoed code action and is still that is implemented ) I'd like to remove the function, as it is one of the few remaining things that requires to be public, and as it is very much a hack anyway. Additionally, I believe I've broken this function accidently a while ago: Rather than retokenizing a span, it retokenized file from the begining until the end of the span (whcih, as uses are usually on top, worked correctly most of the times by accident). What would be the best way to fix this? Add hir::Use-- this seem to be the "proper" solution here Move hack's implementation to where it belongs: in , just fetch the text of the file and look for ('') Remove the deglog functionlity from RLS? I don't like this option as it handicaps the RLS before we formally decided to deprecated it. But I don't completely disregard it either, as, as a whole, it seems to be a full-stack one off hack penetrating every layer of abstraction. WDYT?
I'd suggest the second alternative (move hack's implementation to in librutcsaveanalysis), save analysis is a home of many hacks already and one more until save analysis is deprecated in its entirety won't hurt. Adding span for would be ok if it were useful for anything else at least.
Code change:
// Region folder impl<'tcx> TyCtxt<'tcx> { <del> /// Folds the escaping and free regions in `value` using `f`, and /// sets `skipped_regions` to true if any late-bound region was found /// and skipped. </del> <ins> /// Folds the escaping and free regions in `value` using `f`. </ins> pub fn fold_regions<T>( self, value: T,

Related discussion:
text: <!-- 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
probably Regression in searched nightlies: from nightly-2023-02-15 to nightly-2023-03-16 regressed nightly: nightly-2023-02-20 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It's actually
Or at least, the logic broke because of , so the ICE message probably changed in that PR from some other message, to this one in the title.
label +S-bug-has-mcve
Code change:
<ins> #![feature(stmt_expr_attributes)] fn foo() -> String { #[cfg(feature = "validation")] [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>() //~ ERROR expected `;`, found `#` #[cfg(not(feature = "validation"))] String::new() } fn bar() -> String { #[attr] [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>() //~ ERROR expected `;`, found `#` #[attr] //~ ERROR cannot find attribute `attr` in this scope String::new() } fn main() { println!("{}", foo()); } </ins>

Related discussion:
text: Error code: Metadata:
What is the issue you are reporting here ?
Well, I thought that compiler can understand that is related to the block of code, but it fails.
Can you post a minimal reproducible example that demonstrates your issue? Or at least mention exactly what you'd expect to happen and why. Even code that is cfged out is still required to parse successfully.
Let's show you what exactly problem I have. Full code: And I get this error:
You seem to already have posted this a month ago. What you're asking seems a rather big change to me, I'm not that familiar with how the compiler parser works but I believe it currently requires your program syntax to be correct before macros are expanded, which is not true for your example, so some fundamental changes would be needed.
Oh, damn, sorry. I totally forgot that I made a post. Well, if it's not a bug and parser works like this it is bad, anyway, exists alternative way to write like this. But for me my issue is a candidate to feature request or a bug. Anyway, I'm not a lang dev, so I don't know what scales of this defect (?).
The workaround for this is to wrap the expressions in a block:
I solved this issue exactly as you did.
Another way to do this is using the macro and . I personally thinks it is more clear, and should optimize the same.
Work is not the same, due to compile-time evaluating an expression that we pass in it and evaluates only it, but at the same time everything compiles what is inside of .
Code change:
t!(fs::create_dir_all(&out_dir)); let mut cfg = cmake::Config::new(builder.src.join("src/llvm-project/lld")); <del> if let Some(ref linker) = builder.config.llvm_use_linker { cfg.define("LLVM_USE_LINKER", linker); } </del> configure_cmake(builder, target, &mut cfg, true); // This is an awful, awful hack. Discovered when we migrated to using

Related discussion:
text: When I install the latest master toolchains via and try to build with them, linking fails: I did some bisection, and it looks like the problem started happening with Cc
The error is actually already mentioned in However, I am building Miri with cargo, so I don't know how I'd "use LLD instead".
Hm, we probably need to revert that PR. I did not realize we'd need lld downstream too, I thought that was only on our builder. cc
Yes, a revert seems appropriate. We're going to have to figure out where that's actually coming from. The only change I saw between 10 and 11 by grepping was the removal of llgo, but maybe there's some bad remnant.
Yeah, I thought this issue would be limited to the rustc build, but it makes sense that it can also affect project linking against rustc shared objects. I've looked a bit into what the root cause is, and what I have so far as that the symbol comes from and is present as a weak symbol both when compiling with clang-10 and clang-11. The only difference I see from is this: So apparently was treated as a symbol of the library, while now it's treated as a symbol of -- I'm not sure what that actually means, but presumably that refers to the compiler runtime libraries. My guess is that previously it just ended up being nulled out as a missing weak symbol, but now it's actually being found and linking fails because ... reasons. I'm not good at linkers :) Edit: shows these as:
can you prepare a revert PR?
Done in . If nobody has an idea on how to avoid the linker error, two more options would be to comment out the symbol in our llvm-project fork, or to avoid upgrading clang altogether and just build both Python 2 and Python 3 for that image.
The issue is probably going to be in how exactly the objects that comprise are compiled, not linked. I suspect just ends up ignoring the malformed object or otherwise not reporting the issue, but the object and the relevant symbols ultimately end up in the anyway. Alas, reasons these obscure failures can occur are many – I've seen them occur from things as trivial as forgetting to . The question is: is there perhaps a way to disable ExecutionEngine entirely? Intuitively nothing we do should depend on that code.
Code change:
t!(fs::create_dir_all(&out_dir)); let mut cfg = cmake::Config::new(builder.src.join("src/llvm-project/lld")); <del> if let Some(ref linker) = builder.config.llvm_use_linker { cfg.define("LLVM_USE_LINKER", linker); } </del> configure_cmake(builder, target, &mut cfg, true); // This is an awful, awful hack. Discovered when we migrated to using

Related discussion:
text: And if not, I'm comfortable patching out in our fork as we get closer to Feb 11 and continue having trouble pinpointing exact cause of this problem.
We normally don't link ExecutionEngine, but dist-x8664-linux in particular builds LLVM with ThinLTO, in which case we link as shared, instead of statically linking individual components into rustcllvm.
It seems to be possible to configure the components in using , but I'm not sure to what degree we can restrict those (not sure if this job also ships LLVM tools).
So, I think we could have used to exclude unnecessary parts from , as LLVM tools can still statically link the parts not in the dylib. But in the end, we can't use the option anyway due to
Looks like I'm getting this locally when trying to bootstrap rustc (while building ), might happen since the llvm upgrade but I'm not 100% sure. Are there some workarounds I can put into my for this? I'm using lld to link. <details<summaryBacktrace</summary<p</p</details
which commit are you trying to build?
latest git master
Probably best to open a new issue then; this one has been closed and the steps to reproduce it still work without error -- you might be having a different problem.
Opened
Did anyone file an upstream bug report about this? I'm observing it outside of Rust, but with a similar setup ( with lld+ThinLTO, then linking it into a binary with ). If not, I'd try to build a reproducer.
I've opened for this.
The bug has been fixed, the fix will be in LLVM 12.0.1.
Thanks! We can try updating clang again once the 12.0.1 tag is there.
Code change:
match target { Some(ref target) if target.shadowable != Shadowable::Always => { let ns_word = match namespace { <del> TypeNS => "type", </del> <ins> TypeNS => { if let Some(ref ty_def) = *target.bindings.type_def.borrow() { match ty_def.module_def { Some(ref module) if module.kind.get() == ModuleKind::NormalModuleKind => "module", Some(ref module) if module.kind.get() == ModuleKind::TraitModuleKind => "trait", _ => "type", } } else { "type" } }, </ins> ValueNS => "value", }; span_err!(self.resolver.session, import_span, E0252,

Related discussion:
text: I found an error message that seems a bit off to me. The code: Clearly it should fail to compile, and it does. But the error message is: I would expect something like "a module name has already been imported", instead. Is it accurate to call it a type?
Code change:
LL | pub fn has_error() -> TypeError {} |                       ^^^^^^^^^ not found in this scope <del> error: aborting due to 1 previous error </del> <ins> error[E0412]: cannot find type `TypeError` in this scope --> $DIR/type-errors.rs:18:29 | LL | pub fn autoderef_source(e: &TypeError) { |                             ^^^^^^^^^ not found in this scope error[E0412]: cannot find type `TypeError` in this scope --> $DIR/type-errors.rs:23:29 | LL | pub fn autoderef_target(_: &TypeError) {} |                             ^^^^^^^^^ not found in this scope error: aborting due to 3 previous errors </ins> For more information about this error, try `rustc --explain E0412`.

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'coerceborrowedpointer had no error'', 'thread 'rustc' panicked at 'coerceborrowedpointer had no error'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
Regression in there are no individual builds of the commits yet tho :sweat_smile:
I would guess cc
Code change:
.define("LLVM_TARGET_ARCH", target_native.split('-').next().unwrap()) .define("LLVM_DEFAULT_TARGET_TRIPLE", target_native); <del> if target != "aarch64-apple-darwin" { </del> <ins> if target != "aarch64-apple-darwin" && !target.contains("windows") { </ins> cfg.define("LLVM_ENABLE_ZLIB", "ON"); } else { cfg.define("LLVM_ENABLE_ZLIB", "OFF");

Related discussion:
text: <!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this: (at ) windows-gnu nightly: wasm target: the package for : Result: The invokes . depends on that is not present in the distribution. If I add it manually, the issue goes away. The flavor ships with that does not have this dependency. and (and likely everything between)
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low +T-compiler +O-windows Edit: my assessment was wrong, this requires more prompt attention label -P-low +P-high
I have the same issue with "stable" rust 1.52.1 ( 2021-05-09) on Windows 10 with a wasm32-unknown-unknown target. Can you elaborate on how to quick-fix this by adding manually? Where can I get, and where do I put I only have from Mingw64, Mingw32, and many other SW packages. Is it the same? Btw. what hit me instantly is the move from LLVM 11 to 12. Might that be the issue?
Yes, at least enough so it works for me. Just rename any zlib binary, the library interface has been stable for a very long time, so it should just work. Or, if you are ok with using binaries received from strangers, take this: . When you have , you need to make it visible. Either place it in any location visible in environment variable, or place it next to the . For me it is located in . See if you want in-depth explanation where the Windows looks for the DLLs.
It works, thanks a lot. It was a bit confusing that I don't have rust-lld in the wasm target folder. Now I can work on my fullstack project again without worrying about OS specific issues :-)
Code change:
name = "stdbenches" path = "benches/lib.rs" test = true <ins> [lints.rust.unexpected_cfgs] level = "warn" check-cfg = [ 'cfg(bootstrap)', 'cfg(backtrace_in_libstd)', 'cfg(netbsd10)', 'cfg(target_arch, values("xtensa"))', 'cfg(feature, values("std", "as_crate"))', ] </ins>

Related discussion:
text: With extra verbose flag (), one would see a lots of warnings about check-cfg when building -Zbuild-std. But it doesn't need to be that way. Can we doodfooding check-cfg flag to and to resolve them? Step to reproduce: I expected to see this happen: No warnings about " unexpected " Some are: label +F-check-cfg +-Zbuild-std cc
Code change:
// SAFETY: left and right must be valid and part of v same for out. unsafe { <del> let to_copy = if is_less(&*right.sub(1), &*left.sub(1)) { decrement_and_get(left) } else { decrement_and_get(right) }; ptr::copy_nonoverlapping(to_copy, decrement_and_get(&mut out), 1); </del> <ins> let is_l = is_less(&*right.sub(1), &*left.sub(1)); *left = left.sub(is_l as usize); *right = right.sub(!is_l as usize); let to_copy = if is_l { *left } else { *right }; out = out.sub(1); ptr::copy_nonoverlapping(to_copy, out, 1); </ins> } } } // Finally, `hole` gets dropped. If the shorter run was not fully consumed, whatever remains of // it will now be copied into the hole in `v`. <del> unsafe fn get_and_increment<T>(ptr: &mut *mut T) -> *mut T { let old = *ptr; // SAFETY: ptr.add(1) must still be a valid pointer and part of `v`. *ptr = unsafe { ptr.add(1) }; old } unsafe fn decrement_and_get<T>(ptr: &mut *mut T) -> *mut T { // SAFETY: ptr.sub(1) must still be a valid pointer and part of `v`. *ptr = unsafe { ptr.sub(1) }; *ptr } </del> // When dropped, copies the range `start..end` into `dest..`. struct MergeHole<T> { start: *mut T,

Related discussion:
text: I tried this code, sorting 30 million random : On this machine: Using the vendored version of from mid 2022 see here I expected to see this happen: Runtime ~1.45s Instead, this happened: Runtime ~2s I bisected the issue down to with . The same happens if you do instead of . So this also affects the current implementation which is very similar to my vendored version.
Dinging into it, I think the relevant code that has this impact is in the function. Which has two blocks of logic one for if the left side is shorter and one if the right side is shorter. Previously both sides generated code that is branchless in terms of jumping based on the comparison result. Now the block handling left side is shorter generates a jump based on the comparison result. LLVM 15: ! LLVM 16: ! This can be fixed in code by using 'proper' branchless code: -This would fix the stdlib, but it would still mean a regression for any other code out there that relies on this.
I feel like I should attach the usual disclaimer that this kind of optimization can never be considered fully stable, specifically LLVM has various heuristics that affect whether it compiles a segment of code to use a "branchless" CMOV-alike or use a jump, however that doesn't mean there's nothing we can do here. label: +A-LLVM +A-codegen +regression-from-stable-to-beta +I-slow
WG-prioritization assigning priority (). label -I-prioritize +P-low +T-compiler
out of curiosity. What is the future for a perf regression marked as P-low? Is there any work planned on this? Personally I was surprised that it even generated branchless code in the first place.
A P-high or P-critical compiler issue means that it will be reviewed regularly by T-compiler until it is resolved, where "regularly" is a much higher frequency for P-critical. So a P-low implicitly means "this isn't so important that we need to keep putting it on the agenda". Though I should note that periodically, all T-compiler issues do get reviewed and triaged, just on a more irregular basis.
Code change:
// SAFETY: left and right must be valid and part of v same for out. unsafe { <del> let to_copy = if is_less(&*right.sub(1), &*left.sub(1)) { decrement_and_get(left) } else { decrement_and_get(right) }; ptr::copy_nonoverlapping(to_copy, decrement_and_get(&mut out), 1); </del> <ins> let is_l = is_less(&*right.sub(1), &*left.sub(1)); *left = left.sub(is_l as usize); *right = right.sub(!is_l as usize); let to_copy = if is_l { *left } else { *right }; out = out.sub(1); ptr::copy_nonoverlapping(to_copy, out, 1); </ins> } } } // Finally, `hole` gets dropped. If the shorter run was not fully consumed, whatever remains of // it will now be copied into the hole in `v`. <del> unsafe fn get_and_increment<T>(ptr: &mut *mut T) -> *mut T { let old = *ptr; // SAFETY: ptr.add(1) must still be a valid pointer and part of `v`. *ptr = unsafe { ptr.add(1) }; old } unsafe fn decrement_and_get<T>(ptr: &mut *mut T) -> *mut T { // SAFETY: ptr.sub(1) must still be a valid pointer and part of `v`. *ptr = unsafe { ptr.sub(1) }; *ptr } </del> // When dropped, copies the range `start..end` into `dest..`. struct MergeHole<T> { start: *mut T,

Related discussion:
text: Performance work is one of those "never done" things so it's rare for it to be high priority in general, which isn't the same as "no one will work on it". It just means it would be addressed in a somewhat irregular fashion.
I'm not sure I understand the difference between "never done" and "no one will work on it".
"Never done" as in "never finished" not "never worked on"
Ohh, thanks for clarifying. Anyway from my perspective me and other people I've talked to were surprised this even generated branchless code in the first place, I'd be fine with closing this issue as won't fix.
since you have opened a PR (thanks a lot for that!), it makes totally sense to try fixing it, no matter the priority we assign to issues.
I think the issue can be split into two parts: A) A significant regression in . B) LLVM no longer generating branchless code for a certain pattern. I think A should definitely be fixed, and that's what my PR is for. B however I'd argue doesn't really need fixing, because the code in question was not obviously branchless.