jiebi/CodeConvo huggingface dataset:
Change:
}).unwrap_or(HashMap::new()); let mut cache = Cache { impls: HashMap::new(), <del> external_paths: paths.iter().map(|(&k, &(ref v, _))| (k, v.clone())) </del> <ins> external_paths: paths.iter().map(|(&k, v)| (k, v.ref0().clone())) </ins> .collect(), paths: paths, implementors: HashMap::new(),

Discussion:
The recent attempts to improve hashmap seem to have exposed a bug in regionck where it fails to link the lifetimes of ref bindings in some situations. A mostly minimized test case is here: This test fails to compile but (I believe) should succeed. The problem is that the lifetime of the binding inside the callback from is not "linked" (in regionck terminology) to the lifetime , and hence region inference infers a lifetime for that is too small. It was not immediately obvious what the best way is to fix this -- the code around handling ref bindings seems a bit ... off in regionck, so I need to think about it some. Perturbing the code in various ways can workaround the issue, which is bad for making minimized test cases but good for landing the hasmap patch in the meantime!
I've run into (I think) another manifestation of this issue that forces the destructuring of a reference to a tuple from the arguments to the closure body: This works, but this does not
I think this is the original problem, updated to current syntax: error: Actually, maybe this should be using something other than Box... ugh old closures.
If you use a boxed closure, remember to box it: This runs on modern rustc.
Ah duh. Thanks!
Change:
}, }; <del> let memory_locals = analyze::memory_locals(&fx); </del> <ins> let memory_locals = analyze::non_ssa_locals(&fx); </ins> // Allocate variable and temp allocas fx.locals = {

Discussion:
Context: In order to experiment with an -aware , I was preparing to modify the lang item signature, and my first step was to ensure MIR passes the right type to begin with, as noted in Legitimately, I assumed that the MIR inline code was doing the right thing, so I mimicked it in . The resulting code actually works fine, as far as completing the 3 stages of rustc bootstrapping is involved. But before going the route for the -aware , I first tried removing the special handling of 's , trying to leave it to , shortcutting the lang item. This didn't go well, and produced a stage 1 compiler that would crash on a bad in libsyntax's . From which I derived a small test case that would exhibit the problem with my code. Anyways, I was going well over my head with this approach, thus switched to the signature change. So, what's the deal with this issue, will you ask? Well, it turns out that my MIR changes, essentially copied from MIR inlining, while they worked to produce an apparently working compiler, failed to compile that reduced testcase with an LLVM ERROR. I was wondering if I did something significantly different from what the MIT inlining pass was doing, so I tried to trigger it manually (since it's not enabled by default), and after some trial and error, got it to happen on a plain nightly compiler, with the following reduced testcase: Building with yields: (Note the is only there to force MIR inlining to happen without having to go over the required threshold ; liballoc's has ; similarly, the on avoids inlining of dealloc, to limit the effects on the MIR) Interestingly enough, and fail with the same error. The former outputs a truncated MIR (truncated at the entry of the first basic block), and the latter outputs nothing.
This is what from a run with looks like: Edit: and what the llvm-ir, as disassembled from output, looks like:
The problem is that the code path bb1-bb9-bb21-bb20 in IR, corresponding to bb0-bb1-bb6-bb5 in MIR, is impossible, yet exists. And in that code path, in MIR, in IR, is never initialized, and that's what LLVM doesn't like.

I guess one way to look at is it to wonder why in MIR has a switch in the first place.
And the answer to that last question is false edges, according to the following MIR from the mir_map pass:
Actually, the path bb0-bb7-bb4-bb10-bb12 has without ever being initialized, but that's pre-elaborate-drops, and I hear drop is different then, so I don't know if it bad or not.
The weird switch that eventually causes the LLVM problem is by the elaborate-drops pass. The MIR after that phase looks like the following:
I think the most relevant fact is this difference between MIR inlining being enabled or not: with MIR inlining disabled, this basic block in MIR: becomes the following IR: with MIR inlining enabled, this basic block in MIR: becomes whiich is weird... where did the extra code go?
The changes from fix this issue.
Change:
printTab(currentTab); } <ins> function updateSearchHistory(url) { if (!browserSupportsHistoryApi()) { return; } const params = searchState.getQueryStringParams(); if (!history.state && !params.search) { history.pushState(null, "", url); } else { history.replaceState(null, "", url); } } </ins> /** * Perform a search based on the current state of the search input element * and display the results.

Discussion:
Reproduction: Go to Click the gear next to the search field, enable "Directly go to item in search if there is only one result" Refresh page to ensure it's enabled (was required the first time I tried to reproduce, but seemed to work straight away the second time) Search for You should be taken straight to Press "Back" in your browser I expected this to happen: Go back to Instead, this happened: Goes back to then instantly redirects forward again
Taking a look.
Fixed in
Change:
//! [`Err`]: ../../std/result/enum.Result.html#variant.Err //! [`panic!`]: ../../std/macro.panic.html //! [`Builder`]: ../../std/thread/struct.Builder.html <ins> //! [`Builder::stack_size`]: ../../std/thread/struct.Builder.html#method.stack_size //! [`Builder::name`]: ../../std/thread/struct.Builder.html#method.name </ins> //! [`thread::current`]: ../../std/thread/fn.current.html //! [`thread::Result`]: ../../std/thread/type.Result.html //! [`Thread`]: ../../std/thread/struct.Thread.html //! [`park`]: ../../std/thread/fn.park.html //! [`unpark`]: ../../std/thread/struct.Thread.html#method.unpark <ins> //! [`Thread::name`]: ../../std/thread/struct.Thread.html#method.name </ins> //! [`thread::park_timeout`]: ../../std/thread/fn.park_timeout.html //! [`Cell`]: ../cell/struct.Cell.html //! [`RefCell`]: ../cell/struct.RefCell.html

Discussion:
One can specify the stack size of a thread via . It looks like looks at the env var and attempts to parse it into an integer. If it's not specified or can't parse, it falls back to 2MB. Should we update the thread documentation to mention what the default stack size is and mention that environment variable?
Relevant discussion on IRC
Don't forget that the stack size of the main thread is not determined by Rust.
Opened a PR:
Change:
<ins> //@ run-rustfix fn main() { let s = "123"; println!("{:?} {} {}", {}, "sss", s); //~^ ERROR format argument must be a string literal println!("{:?}", {}); //~^ ERROR format argument must be a string literal println!("{} {} {} {:?}", s, "sss", s, {}); //~^ ERROR format argument must be a string literal println!("{:?} {} {:?}", (), s, {}); //~^ ERROR format argument must be a string literal } </ins>

Discussion:
Cargo does not seem to be detecting the {} outside brackets and provides an incredibly strange fix instead. No response the file is from here: You will need serdejson crate. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
it's worth noting that is a valid rust expression, it evaluates to the empty tuple. this is perfectly valid code: minimal repro:
huh, didn't know that. good to know ig
I think it is worth special casing this in diagnostics though, if someone wanted to print a unit type (for some reason?) they probably should use the value or just embed it directly in the format string. An empty expression as the first argument of a format macro is almost certainly a mistake.
claim
The PR that closed this doesn't seem to actually apply the wanted fix, this should be reopened.
Hello, thank you very much for the suggestion. My idea is to find a slightly more general solution instead of special treatment for rare cases. If you think it should be modified as , I completely agree with reopening the issue. :relaxed:
Change:
} } } <ins> fn check_syntax_directive<S: AsRef<str>>(piece: S, syntax: &str) -> Option<InnerSpan> { let piece = piece.as_ref(); if let Some(idx) = piece.find(syntax) { let end = idx + &piece[idx..].find(|c| matches!(c, 'n' | ';')).unwrap_or(piece[idx..].len()); // Offset by one because these represent the span with the " removed Some(InnerSpan::new(idx + 1, end + 1)) } else { None } } </ins>

Discussion:
People used to gcc/clang inline assembly may try using the or directives directly in the assembly string, which can cause issues. Ideally, we should detect attempts to use those directives. Attempting to use should generate an error stating that that's the default. Attempting to use should generate an error and point to the option, ideally with a rustfix-applicable suggestion. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Is anyone currently working on this? I would like to do it if not.
Not to my knowledge, no.
claim
Change:
<ins> error: byte constant must be ASCII. Use a xHH escape for a non-ASCII byte --> $DIR/key-value-non-ascii.rs:3:19 | LL | #[rustc_dummy = b"ﬃ.rs"] |                   ^ error: aborting due to previous error </ins>

Discussion:
Also tested on and , it errored without ICEing on 1.49 and ICEd on 1.50 so modify labels: +regression-from-stable-to-beta <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning as discussed as part of the and removing .
searched nightlies: from nightly-2020-12-01 to nightly-2021-01-21 regressed nightly: nightly-2020-12-11 searched commits: from ... regressed commit: It's cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
glacier ""
I spent some time looking at this. will not ICE in stable because the assert should be compiled away. What will happen is an incorrect span in the output duplicating a prior error. think this is caused by the double duty that s and have. We sometimes treat as indices into a byte buffer, but there's an additional piece of info in s that isn't carried over with , namely whether the byte position is the beginning or the end of a . This matters because when doing operations being or not being the end is the difference between having to do or not. I believe this is the underlying cause of these issues. if you're taking on this you might want to look at modifying to accept a new stating whether the is the start or end (and depending on that whether we should the assertion and likely other logic or not). are a bunch of small tweaks to these diagnostics that can be done as a separate PR by changing with and even provide a structured suggestion instead of the .
Why would the assert be compiled away in stable but not beta and nightly? I'm pretty sure the issue here is that the PR that causes this ICE was merged for 1.50 (which is the current beta version), not 1.49 (which is the current stable).
Am I wrong to understand that in controls whether ions get evaluated, which in turn is only enabled if ?

Regardless, a small patch to remove that assertion would get around the ICE without major negative impact (the label is shifted one char to the left and nothing else), if we don't cut a more comprehensive PR before the next release.
I'm not sure if that gets rid of calls (it may only get rid of calls). However, what I'm referring to is that you said it wouldn't ICE in stable, whereas my understanding is that if it ICEs in beta, it will ICE in the next stable.
taking over, I've figured out the problem.
Re-opening because this still affects beta and the PR needs to be backported.
The fix landed in 1.51.0, and I cherry-picked a fix for the 1.50.0 stable branch. If the cherry-pick is accepted by CI then we can close this issue!
CI passed on the test runner in the 1.50.0 promotion, but it timed out on an unrelated builder, so the fix worked! Closing this.
Change:
} fn run(self, builder: &Builder<'_>) { <ins> // During ./x.py setup once you select the codegen profile. // The submodule will be downloaded. It does not work in the // tarball case since they don't include Git and submodules // are already included. if !builder.rust_info().is_from_tarball() { if self == Profile::Codegen { builder.update_submodule(&Path::new("src/llvm-project")); } } </ins> setup(&builder.build.config, self) } }

Discussion:
The profile is intended not just for people working on LLVM itself, but also anyone who touches codegen but not LLVM. For example, anyone who modifies or is only changing the IR we send to LLVM, not LLVM itself. We should keep on for them but not for , but ideally we wouldn't build LLVM from source if it's unmodified. points out some things that we should fix before enabling that option by default for the profile: Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Should all 3 tasks be in one PR or is it 3 separate PR's?
I'd say it depends how challenging they are - if it's simple to fix all three in one PR that seems fine, but if it takes a more than a day to do one of the tasks, it probably makes sense to open a PR for it early.
I think I can tackle points 1 and 3 by tonight so I'll make that into one PR. I'll open a separate PR for the second point, since I think it has more work involved, if that's alright :)
release-assignment
Change:
Node::Expr(Expr { kind: ExprKind::Repeat(_, constant), .. }) if constant.hir_id() == hir_id => { <del> Some(parent_def_id.to_def_id()) </del> <ins> Some(parent_did) </ins> } // Exclude `GlobalAsm` here which cannot have generics. Node::Expr(&Expr { kind: ExprKind::InlineAsm(asm), .. })

Discussion:
<!-- [31mICE[0m: Rustc '-Zcrate-attr=feature(effects) -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: [adtdestructor] computing impl for [checkwellformed] checking that is well-formed -- label +F-constmutrefs +F-consttrait_impl +F-effects
Regression in of
doesn't require any features actually, rip
Removed irrelevant errors:
Minimized: or
Change:
let (res, fragment) = { let mut kind = None; let mut disambiguator = None; <del> path_str = if let Some(prefix) = ["struct@", "enum@", "type@", "trait@", "union@"] .iter() .find(|p| link.starts_with(**p)) </del> <ins> path_str = if let Some(prefix) = ["struct@", "enum@", "type@", "trait@", "union@", "module@", "mod@"] .iter() .find(|p| link.starts_with(**p)) </ins> { kind = Some(TypeNS); disambiguator = Some(&prefix[..prefix.len() - 1]); link.trim_start_matches(prefix) <del> } else if let Some(prefix) = [ "const@", "static@", "value@", "function@", "mod@", "fn@", "module@", "method@", ] .iter() .find(|p| link.starts_with(**p)) </del> <ins> } else if let Some(prefix) = ["const@", "static@", "value@", "function@", "fn@", "method@"] .iter() .find(|p| link.starts_with(**p)) </ins> { kind = Some(ValueNS); disambiguator = Some(&prefix[..prefix.len() - 1]);

Discussion:
Starting with an ambiguous rustdoc correctly reports the ambiguity and suggests the possible resolutions: In this case I want to link to the module so let's update accepts this without warnings but the generated html file contains: I would expect [module to link to the module x, not the function x. Mentioning tracking issue:
Workaround: leverage rustc's name resolution instead of rustdoc's.
This is coming directly from , so I'm not sure how to fix it. Maybe has ideas? The issue is that currently we can only select between types, values, and macros, and modules count as all three so there's not a way to say 'only give me modules'.
I think eventually we should switch rustdoc to using . That would also But I have no idea how hard that would be.
Yeah I don't know either. I'm not sure how that overlap works in resolve. might? We could tweak the resolve resolution functions to force looking for modules.
I don't know much about name resolution, you want Only thing I know is that it should be possible to get a and then use whichever namespace you want from there at your discretion.
the problem is that modules seem to be special and exist in all namespaces but also overlap. Do you have an idea of how that works?
"Modules count as all three" sounds wrong? Modules live in the type namespace last I checked.
Oh! Maybe we should just switch modules to being a type then, I was under the impression they lvied in all namespaces
And yeah, seems like types cannot overlap with modules.
Wait I'm confused - I thought functions are in the type namespace? Are they values instead?
Functions are values
Change:
<del> error: arbitrary expressions aren't allowed in patterns </del> <ins> error[E0425]: cannot find value `a` in this scope </ins> --> $DIR/expr_before_ident_pat.rs:12:12 | LL |     funny!(a, a); <del> |            ^ </del> <ins> |            ^ not found in this scope </ins> <del> error[E0425]: cannot find value `a` in this scope </del> <ins> error: arbitrary expressions aren't allowed in patterns </ins> --> $DIR/expr_before_ident_pat.rs:12:12 | LL |     funny!(a, a); <del> |            ^ not found in this scope </del> <ins> |            ^ </ins> error: aborting due to 2 previous errors

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. --Note: this only occurs when the type of the code block is a result. Removing the line and swapping for does not yield the ICE. //! use rustice::sub; //! //! let x = sub::makestruct()?; //! //! assert!(matches!(x, sub::En::A(sub::B { inner: vec![], .. }))); //! Ok::<(), &'static str(()) //! <!-- 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. --: and after a rustup, (still getting the same ICE): <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Here's a reproduction without rustdoc involved:
Minimized:
Change:
let bindir_default = PathBuf::from("bin"); let libdir_default = PathBuf::from("lib"); let mandir_default = datadir_default.join("man"); <del> let prefix = build.config.prefix.as_ref().unwrap_or(&prefix_default); </del> <ins> let prefix = build.config.prefix.as_ref().map_or(prefix_default, |p| { fs::canonicalize(p).expect(&format!("could not canonicalize {}", p.display())) }); </ins> let sysconfdir = build.config.sysconfdir.as_ref().unwrap_or(&sysconfdir_default); let datadir = build.config.datadir.as_ref().unwrap_or(&datadir_default); let docdir = build.config.docdir.as_ref().unwrap_or(&docdir_default);

Discussion:
When I configured with and ran , my install ended up in .
Seems to be because of which was apparently for . If the cannot be removed, then converting to absolute path before installing might work.
I think this is still an issue with rustbuild, but should be somewhat easy to fix.. I think we just want to call canonicalize on the paths here: Does that sound correct to you? If so, this is E-easy and E-mentor (by me).
I believe so!
I can take a crack at this one if nobody else has started on it yet.
Go ahead! Let us know if there's anything we can do to help you.
Just an update - still working on this, just got buried in a move. Will try to get it knocked out this week.
are there any unit-like tests that run against the install scripts? or do they just get tested as part of the full build?
No unfortunately I don't think we test this step at all on CI :(
canonicalizing the prefix breaks when prefix is a symbolic link. e.g., /usr/local -/some/other/location Now if you want to install to <destdir/usr/local, everything goes to <destdir/some/other/location instead with many files including references to /some/other/location internally. Now when I want to change the /usr/local sym link (in my case, the underlying location is a shared NFS mount point) to point to /a/different/location that contains the rust install, all the references to /some/other/location are wrong - leaving the best remaining option to recompile rust (and that's painful) on each occurrence where the underlying path pointed to by <prefixis different. There must be a better way to solve the relative path issue than by manually converting all sym links to their resolved paths. I can't think of any packages right now where defining prefix to a sym link breaks in this way.
Change:
.docblock { margin-left: 12px; } <ins> .docblock code { overflow-wrap: anywhere; } </ins> }

Discussion:
Otherwise, if too long we can't read them: ! With rule: !
You probs want so that it tries to not wrap mid-word (but still does if it can't do otherwise).
With your suggestion it gives: ! It's weird but in a different way haha.
We can tell the browser where to break words by inserting in the right places. E.g. . Together with some other CSS properties that should give us full control where it'll do the breaking.
it's not clear to me that makes wrapping word-aware (that would be quite a task!) In other words, vs differ only in whether the wrap : Emphasis mine. We don't explicitly use min-content in our CSS as far as I can tell, but looking at the screenshots shared, perhaps it is introduced somewhere by browser intrinsics? Long story short, I think we should use . It produces nicer results in these screenshots, and isn't documented to provide benefits that we care about.
I'm certainly not a CSS expert, I just meant "let's not break idents in the middle" and assumed would be enough for that. It seems like gave the proper answer for breaking correctly around instead of in the middle of the words.
Change:
"""Check that vendoring is configured properly""" vendor_dir = os.path.join(self.rust_root, 'vendor') if 'SUDO_USER' in os.environ and not self.use_vendored_sources: <del> if os.environ.get('USER') != os.environ['SUDO_USER']: </del> <ins> if os.getuid() == 0: </ins> self.use_vendored_sources = True <del> print('info: looks like you are running this command under `sudo`') </del> <ins> print('info: looks like you're trying to run this command as root') </ins> print('      and so in order to preserve your $HOME this will now') print('      use vendored sources by default.') if not os.path.exists(vendor_dir):

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 am trying to build Rust from source on my project's continuous integration system. I see the following error: Looking at the message and it seems the intent is to prevent putting root-owned files in a non-root user's home directory. Our CI builders use sudo to step down from root to a sandboxed user. See for an example environment. I believe it should be safe to build without vendoring in this case. should skip the check if SUDOUSER is not root, or an option to bypass this check should be provided. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
If the implementation for this is relatively straightforward, a PR is likely to be accepted.
label; +E-easy +E-help-wanted
Error: Parsing relabel command in failed: ...'tbot label' '; +E-easy '... Please let know if you're having trouble with this bot.
label: +E-easy +E-help-wanted
claim