jiebi/CodeConvo huggingface dataset:
Code change:
if builder.config.llvm_thin_lto { cfg.define("LLVM_ENABLE_LTO", "Thin"); if !target.contains("apple") { <del> cfg.define("LLVM_USE_LINKER", "lld"); </del> <ins> cfg.define("LLVM_ENABLE_LLD", "ON"); </ins> } }

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:
if builder.config.llvm_thin_lto { cfg.define("LLVM_ENABLE_LTO", "Thin"); if !target.contains("apple") { <del> cfg.define("LLVM_USE_LINKER", "lld"); </del> <ins> cfg.define("LLVM_ENABLE_LLD", "ON"); </ins> } }

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:
} ``` <ins> ### Error example 3 Suppose we have a struct `Foo` and we would like to define some methods for it. The following code example has a definition which leads to a compiler error: ```compile_fail,E0207 struct Foo; impl<const T: i32> Foo { // error: the const parameter `T` is not constrained by the impl trait, self // type, or predicates [E0207] fn get(&self) -> i32 { i32::default() } } ``` The problem is that the const parameter `T` does not appear in the implementing type (`Foo`) of the impl. In this case, we can fix the error by moving the type parameter from the `impl` to the method `get`: ``` struct Foo; // Move the const parameter from the impl to the method impl Foo { fn get<const T: i32>(&self) -> i32 { i32::default() } } ``` ### Error example 4 Suppose we have a struct `Foo` and a struct `Bar` that uses lifetime `'a`. We would like to implement trait `Contains` for `Foo`. The trait `Contains` have the associated type `B`. The following code example has a definition which leads to a compiler error: ```compile_fail,E0207 struct Foo; struct Bar<'a>; trait Contains { type B; fn get(&self) -> i32; } impl<'a> Contains for Foo { type B = Bar<'a>; // error: the lifetime parameter `'a` is not constrained by the impl trait, // self type, or predicates [E0207] fn get(&self) -> i32 { i32::default() } } ``` Please note that unconstrained lifetime parameters are not supported if they are being used by an associated type. </ins> ### Additional information For more information, please see [RFC 447].

Related discussion:
text: As it is currently written, E0207 talks entirely about type parameters. Now that const parameters also need to constrain implementations (under the same rules described for types), they also need to be mentioned in the error explanation. Since other items don't require const parameters to be used at all, we might also want to specifically call out this difference here. Furthermore, E0207 triggers if you use an unconstrained lifetime in an associated type, and this is completely unspecified by the error as well. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
use rustc_hir::definitions::Definitions; use rustc_hir::intravisit::Visitor; use rustc_hir::lang_items::LangItem; <del> use rustc_hir::{ Constness, ExprKind, HirId, ImplItemKind, ItemKind, Node, TraitCandidate, TraitItemKind, }; </del> <ins> use rustc_hir::{Constness, HirId, Node, TraitCandidate}; </ins> use rustc_index::IndexVec; use rustc_macros::HashStable; use rustc_query_system::dep_graph::DepNodeIndex;

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
Code change:
Ok(lhs) } <ins> fn should_continue_as_assoc_expr(&mut self, lhs: &Expr) -> bool { match (self.expr_is_complete(lhs), self.check_assoc_op()) { // Semi-statement forms are odd: // See https://github.com/rust-lang/rust/issues/29071 (true, None) => false, (false, _) => true, // Continue parsing the expression. // An exhaustive check is done in the following block, but these are checked first // because they *are* ambiguous but also reasonable looking incorrect syntax, so we // want to keep their span info to improve diagnostics in these cases in a later stage. (true, Some(AssocOp::Multiply)) | // `{ 42 } *foo = bar;` or `{ 42 } * 3` (true, Some(AssocOp::Subtract)) | // `{ 42 } -5` (true, Some(AssocOp::LAnd)) | // `{ 42 } &&x` (#61475) (true, Some(AssocOp::Add)) // `{ 42 } + 42 // If the next token is a keyword, then the tokens above *are* unambiguously incorrect: // `if x { a } else { b } && if y { c } else { d }` if !self.look_ahead(1, |t| t.is_reserved_ident()) => { // These cases are ambiguous and can't be identified in the parser alone. let sp = self.sess.source_map().start_point(self.token.span); self.sess.ambiguous_block_expr_parse.borrow_mut().insert(sp, lhs.span); false } (true, Some(ref op)) if !op.can_continue_expr_unambiguously() => false, (true, Some(_)) => { self.error_found_expr_would_be_stmt(lhs); true } } } /// We've found an expression that would be parsed as a statement, /// but the next token implies this should be parsed as an expression. /// For example: `if let Some(x) = x { x } else { 0 } / 2`. fn error_found_expr_would_be_stmt(&self, lhs: &Expr) { let mut err = self.struct_span_err(self.token.span, &format!( "expected expression, found `{}`", pprust::token_to_string(&self.token), )); err.span_label(self.token.span, "expected expression"); self.sess.expr_parentheses_needed(&mut err, lhs.span, Some(pprust::expr_to_string(&lhs))); err.emit(); } /// Possibly translate the current token to an associative operator. /// The method does not advance the current token. /// /// Also performs recovery for `and` / `or` which are mistaken for `&&` and `||` respectively. fn check_assoc_op(&self) -> Option<AssocOp> { AssocOp::from_token(&self.token) } </ins> /// Checks if this expression is a successfully parsed statement. fn expr_is_complete(&self, e: &Expr) -> bool { self.restrictions.contains(Restrictions::STMT_EXPR) &&

Related discussion:
text: From The following code should be using the common list parsing utilities: CC
What/where are the common list parsing utilties? Edit: never mind, I've got it. , , etc. for anyone who's wondering.
Code change:
use util::fs::fix_windows_verbatim_for_gcc; use rustc_back::tempdir::TempDir; <ins> use std::ascii; use std::char; </ins> use std::env; use std::ffi::OsString; use std::fs::{self, PathExt};

Related discussion:
text: Compiler crashes while compiling using Cargo. Cargo version: cargo 0.6.0-nightly ( 2015-10-17) rustc version: 1.3.0
It looks like this comes from the linker producing output (normal or error) that is not valid UTF-8. Fixing this in any other way than just using a lossy conversion is going to be really painful because it goes through the error logging infrastructure, which all works with s. That's certainly not ideal, because it would be best to relay other programs' messages to the user unchanged, but it's probably the only realistic way to handle this in the near future.
Just dump the bytes as hexadecimal? I am not sure what is going on here.
My first thought was that the path was probably not UTF-8, but because of the way cargo invokes it that crashes rustc long before it tries to link anything, so that can't be it. I'm not sure why else the message would be non-UTF-8. (I can't reproduce the ICE on that crate (I just get a normal link error), but I can reproduce the ICE by constructing a situation where the linker prints non-UTF-8 messages.) But yeah, some kind of lossy conversion with hex escapes is probably the way to go. I'm not aware of an existing function to do that.
Actually, mapping with is probably good enough.
foo'ncollect2: error: ld returned 1 exit statusn` Not great, but not an ICE and probably good enough until we have a dedicated function to do this sort of thing since this should be a very rare error.
Code change:
Also, please make sure that fixup commits are squashed into other related commits with meaningful commit messages. <ins> GitHub allows [closing issues using keywords][closing-keywords]. This feature should be used to keep the issue tracker tidy. However, it is generally preferred to put the "closes #123" text in the PR description rather than the issue commit; particularly during rebasing, citing the issue number in the commit can "spam" the issue in question. [closing-keywords]: https://help.github.com/en/articles/closing-issues-using-keywords </ins> Please make sure your pull request is in compliance with Rust's style guidelines by running

Related discussion:
text: We expect everyone to rebase instead of merge and we also try to have fixup commits squashed into previous related commits. I think we should document this policy, since it keeps suprising newcomers.
I can take care of this one as it's quite a fresh experience :).
I think we should only rebase when resolving merge conflict, or the review process has completed and reviewer request a rebasing. Otherwise I prefer adding new commits for easier reviewing.
I agree with that this policy is sound for actually merging the PR, but it might cause confusion for reviews. I've had a PR lying around for awhile, and when there is merge conflicts the 'waiting-on-author' label gets so noone reviews it, but when I do the rebasing to get back my 'waiting-on-review' it seems as if Github sometimes loses context of previous reviews, which can be quite confusing...
for the record: I personally want no rebasing and just merging, I'm just stating what the policy is.
Before we close this issue. Could we talk a bit about ? I think we should encourage contributors close issues by keywords in PR descriptions only. Because otherwise the commit could be rebased many times, and each time it creates a reference to the want-to-close issue. Also in the referenced issue, the commit number of the new commit that could close that issue is not really informative. The PR number itself appeared in the issue is more informative and concise. In short, we create another policy for closing issue.
Code change:
#[derive(Default)] struct OptimizationList<'tcx> { <del> and_stars: FxHashMap<Location, Mutability>, </del> <ins> and_stars: FxHashSet<Location>, </ins> arrays_lengths: FxHashMap<Location, Constant<'tcx>>, }

Related discussion:
text: Since InstCombine can now introduce where there was none before, without checking that the value is in fact not used afterwards. This may cause a value to be marked as uninitialized by the dataflow, but still be used in that uninitialized state. If InstCombine ran before the generator transform this would be acutely unsound and could probably be exploited directly, but other than that transform I don't think we rely on this property yet. This impacts , which does run after InstCombine and relies on the dataflow. I've observed this on , where it produces this diff: The second use of occurs despite the first move deinitializing the local. cc
Maybe we should stop making instcombine convert to ? This could be done in the pre-codegen cleanups, but for MIR it is wrong to use or on such values in general. Alternatively instcombine needs to start using dataflow to only insert moves when the site is the last use of the local.
Code change:
<ins> // Test that the `'a` from the impl doesn't // prevent us from creating a `'a` parameter // on the `blah` function. // // check-pass #![feature(in_band_lifetimes)] struct Foo<'a> { x: &'a u32 } impl Foo<'a> { fn method(&self) { fn blah(f: Foo<'a>) { } } } fn main() { } </ins>

Related discussion:
text: The diagnostics ("use of undeclared lifetime name") are bad, but this indeed must be an error because the inner is an illegal use of the outer rather than an implicitly defined fresh lifetime.
Hm, I don't think that's quite what I'd expect: previously using in that context would be fine because there is no shadowing so to speak, that is, this compiles:
From Similarly, if a fn definition is nested inside another fn definition, it is an error to mention lifetimes from that outer definition (without binding them explicitly). This is again intended for future-proofing and clarity, and is an edge case. (In the second example there's an explicit definition that shadows the previous definition for following uses, in the first example there's no second definition, only use)
I see that this is in the RFC, but I think I more or less disagree with the reasoning given. Disallowing the use of inband lifetimes when nesting function seems arbitrary and not entirely helpful; it also makes a mechanical change from "old" to "new" more difficult because shadowing is visible only based on indent levels.
IMO it should be an error, with a helpful note like the one you get when writing . Let's not make in-band lifetimes any more confusing than they already are.
The distinction is that inband lifetime's selling point is that you don't need to declare lifetimes. If we say that, and then clarify it with "except" then I think the feature feels incomplete. Inband lifetimes confusion does not increase with permitting this, IMO.
The problem is if it's allowed, then has a different meaning than This seems unfortunate and confusing. Even unergonomic if I may say so. There's no way that the distinction between and won't be missed in a quick scan of the second one. But, like, the RFC process did decide that isn't important, so whatever.
Well, somewhat, but not really. Nothing outside of imports/definitions inherits into the inner function, unlike the impl where there is a history and multiple things which inherit (, lifetimes, generics).
Code change:
rustflags.arg(sysroot_str); } <del> // https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/.E2.9C.94.20link.20new.20library.20into.20stage1.2Frustc if self.config.llvm_enzyme { rustflags.arg("-l"); rustflags.arg("Enzyme-19"); } </del> let use_new_symbol_mangling = match self.config.rust_new_symbol_mangling { Some(setting) => { // If an explicit setting is given, use that

Related discussion:
text: A while ago we merged the first backend pr to enable automatic differentiation in Rust: This was good enough to add and enable the config in and run . We would now like to improve the integration to also successfully run (to use Rust in our autodiff compiler explorer). and I looked into it for a while and while it seems like a simple linker issue, we didn't fully understood where it comes from and what's the best way to fix it. This commit has a few more changes (not yet upstreamed) that might help for understanding how enzyme is used We also have documentation here: Back to the issue. We first build Enzyme (a git submodule) and then try to link it. To copy Jed's observations: The code to add is in inside fn cargo. Note that linking works correctly when building normal crates. Also, I find it odd that this one line of code yields so many repeat arguments (as in, Is there a better way to link Enzyme? Should we prefer to elide Enzyme linking when it isn't needed or be more explicit with paths so it is always found? A potentially related linking error only happens under MacOS: Related Zulip issue: https://rust- Tracking:
It's not just about dist builds; this happens on any build that triggers tool builds (e.g., running would fail too). This happens because enzyme linking flags are set in the general-purpose cargo function and used in every build even when they aren't needed. changes this so that the flags are set only for the rustc build as they aren't required for other builds.
Thank you for the quick fix!
Code change:
for possible_ancestor in min_cap_list.iter_mut() { match determine_place_ancestry_relation(&place, &possible_ancestor.place) { // current place is descendant of possible_ancestor <del> PlaceAncestryRelation::Descendant => { </del> <ins> PlaceAncestryRelation::Descendant | PlaceAncestryRelation::SamePlace => { </ins> ancestor_found = true; let backup_path_expr_id = possible_ancestor.info.path_expr_id;

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. --This bug popped up in CI on a project of ours. This does not reproduce on stable, but does reproduce on nightly and the latest beta (). Bisection shows that was the first build with the regression. Further bisection points to being the commit that introduced the regression. If I had to guess from the PRs in the rollup I'd say seems the most likely, since it touched the code around the error source. <!-- 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
label: +regression-from-stable-to-beta
Reduced:
This assertion is indeed introduced in . The two captures have the same place but different CaptureInfo. cc
Interesting. It's a bit hard to imagine how could have introduced this, since that just sorts a list. Fascinating! Maybe somebody from has a clue?
Actually, it's not at all hard to imagine, because introduced the following: The projections are actually the same, but the types differ in regions, which probably means that this comment is wrong:
Yeah, I just checked and the region of the match is an inferenced variable and gives an concrete ReFree instead.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Did some analysis: We cannot just replace the with . This will create two mutable references in edition 2021 and fail borrowck. Pre-2018 the places do get merged later so the issue isn't exposed. None of the upvar code makes use of the region info, and writeback will erase it anyway. So I think the fix should just be have the region erased when inserting/looking up from capture_information. I can submit a PR if you haven't started
I just started looking at it but if you have a solution, go for it!
Code change:
for possible_ancestor in min_cap_list.iter_mut() { match determine_place_ancestry_relation(&place, &possible_ancestor.place) { // current place is descendant of possible_ancestor <del> PlaceAncestryRelation::Descendant => { </del> <ins> PlaceAncestryRelation::Descendant | PlaceAncestryRelation::SamePlace => { </ins> ancestor_found = true; let backup_path_expr_id = possible_ancestor.info.path_expr_id;

Related discussion:
text: Happy to review your PR
I'm not sure about region code that much but regionchk uses the regions created: I think at one point mentioned getting rid of the region field entirely in UpvarBorrow, but since it wasn't required the discussion didn't proceed. Also it's more like this is a bug of the capture analysis than the sorting. We should never have two same places going into min capture in the list.
I was thinking about erasing the region from s (i.e. the key of captureinformation). But it turns out that's used later to create upvar tuple... So I switched captureinformation from HashMap to a linear vec looked up with custom eq fn instead.