jiebi/CodeConvo huggingface dataset:
Code change:
host: opt_str2(matches.opt_str("host")), gdb_version: extract_gdb_version(matches.opt_str("gdb-version")), lldb_version: extract_lldb_version(matches.opt_str("lldb-version")), <ins> llvm_version: matches.opt_str("llvm-version"), </ins> android_cross_path: opt_path(matches, "android-cross-path"), adb_path: opt_str2(matches.opt_str("adb-path")), adb_test_dir: format!("{}/{}",

Related discussion:
text: I believe this is due to travis using system llvm which misses the fix backported in . cc
Can we do anything about this?
Our best bet is to add a for tests, I think (alternative is to drop support for LLVM pre 3.9, which would be a shame, even if its buggy in certain cases). Implementation of such directive could be implemented by injecting an environment variable or some such (done ) and checking for that in
There's no need to set an extra environment variable, just check if is set (or if you're boring :wink: )
but… but… what if people have on their own systems too?
cc
no we do not have existing infrastructure for this. I'd prefer to avoid as that's not the relevant piece here, but rather something like or . Distros or anyone else building with an older LLVM are likely to hit this and we'd need a solution for them as well. That being said I think it's fine to temporarily disable the test until we get that. There's basically a 0% chance of us regressing that test as it's just an LLVM bug, and they already have a regression test upstream as well.
Another option would be to create a base Docker image (publishing it to Docker Hub) that is just and the appropriate steps to build whatever version of LLVM we want.
We currently advertise ourselves as supporting LLVM 3.7+, and Travis is kinda our test for that, so I'd prefer to not pull that forward just yet (but instead just fix this)
For the record, I downgraded our LLVM version in a botched rebase and only this test stopped it at bors. Hopefully, someone would have noticed the absence of a fix, but you can't count of that.
touche!
Code change:
.as_ref() .cloned() .map(|version| (version, true)) <del> .unwrap_or_default(); // `is_present` defaults to `false` here. </del> <ins> .unwrap_or_default(); </ins> <del> // Miri is nightly-only; never ship it for other trains. </del> <ins> // miri needs to build std with xargo, which doesn't allow stable/beta: // <https://github.com/japaric/xargo/pull/204#issuecomment-374888868> </ins> if pkgname == "miri-preview" && self.rust_release != "nightly" { <del> is_present = false; // Pretend the component is entirely missing. </del> <ins> is_present = false; // ignore it </ins> } let targets = targets.iter().map(|name| { if is_present { <del> // The component generally exists, but it might still be missing for this target. </del> let filename = self.filename(pkgname, name); let digest = match self.digests.remove(&filename) { Some(digest) => digest, <del> // This component does not exist for this target -- skip it. </del> None => return (name.to_string(), Target::unavailable()), }; let xz_filename = filename.replace(".tar.gz", ".tar.xz");

Related discussion:
text: Seems like no nightly was released today. That might be related to Unfortunately I don't think I have access to the logs. Cc
Logs are missing on the server, let me start a manual release...
Well that is odd. You wouldn't know what commit is is using? ( file in the tarball, if I recall correctly.)
Is there a way for me to download the "dist" artifacts for better testing? Right now I am manually grabbing a bunch of files from https://s3-us-west- (and we only get dir listing for alt builds there it seems so I am using those). That's not very convenient at all.
Apparently not all commits are pushed to toolstate ( vs ), for example the latest one () is missing in toolstate .
Reverting the cause in the meantime --
Alternatively we could land which will just skip of the toolstate is not found. That installs a toolchain based on these artifacts, but I don't think it gives me access to the tarballs. FTR, for now I did So we are only committing when the toolstate changed? Ouch. That kills my entire approach :(
It should print the URLs it's downloading though, and you can use to avoid it actually downloading stuff.
Code change:
/// [arc]: ../../std/sync/struct.Arc.html /// [ub]: ../../reference/behavior-considered-undefined.html #[stable(feature = "rust1", since = "1.0.0")] <del> #[cfg_attr(not(test), rustc_diagnostic_item = "Send")] </del> <ins> #[cfg_attr(all(not(test), bootstrap), rustc_diagnostic_item = "send_trait")] #[cfg_attr(all(not(test), not(bootstrap)), rustc_diagnostic_item = "Send")] </ins> #[rustc_on_unimplemented( message = "`{Self}` cannot be sent between threads safely", label = "`{Self}` cannot be sent between threads safely"

Related discussion:
text: I came across this while working on . Sadly I wasn't really able to minimize this. this branch: and go to (but other commits will likely work too). to and paste in the following:
See also
Slightly minimized: place in Then run: will produce the ICE.
Caused by , cc That PR renames a lot of diagnostic items, but didn't use to gate the name change, so causes breakage when compiling stage 0 std or stage 1 compiler.
Oops, sorry!
Code change:
<ins> error: lifetime must precede `mut` --> $DIR/issue-73568-lifetime-after-mut.rs:2:13 | LL | fn x<'a>(x: &mut 'a i32){} |             ^^^^^^^ help: place the lifetime before `mut`: `&'a mut` error[E0178]: expected a path on the left-hand side of `+`, not `&mut 'a` --> $DIR/issue-73568-lifetime-after-mut.rs:14:13 | LL | fn y<'a>(y: &mut 'a + Send) { |             ^^^^^^^^^^^^^^ help: try adding parentheses: `&mut ('a + Send)` error: lifetime must precede `mut` --> $DIR/issue-73568-lifetime-after-mut.rs:6:22 | LL |         fn w<$lt>(w: &mut $lt i32) {} |                      ^^^^^^^^ help: place the lifetime before `mut`: `&$lt mut` ... LL | mac!('a); | --------- in this macro invocation | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error[E0423]: expected value, found trait `Send` --> $DIR/issue-73568-lifetime-after-mut.rs:18:28 | LL |     let z = y as &mut 'a + Send; |                            ^^^^ not a value warning: trait objects without an explicit `dyn` are deprecated --> $DIR/issue-73568-lifetime-after-mut.rs:14:18 | LL | fn y<'a>(y: &mut 'a + Send) { |                  ^^ help: use `dyn`: `dyn 'a` | = note: `#[warn(bare_trait_objects)]` on by default warning: trait objects without an explicit `dyn` are deprecated --> $DIR/issue-73568-lifetime-after-mut.rs:18:23 | LL |     let z = y as &mut 'a + Send; |                       ^^ help: use `dyn`: `dyn 'a` error[E0224]: at least one trait is required for an object type --> $DIR/issue-73568-lifetime-after-mut.rs:14:18 | LL | fn y<'a>(y: &mut 'a + Send) { |                  ^^ error: aborting due to 5 previous errors; 2 warnings emitted Some errors have detailed explanations: E0178, E0224, E0423. For more information about an error, try `rustc --explain E0178`. </ins>

Related discussion:
text: Expected result: a diagnostic suggests placing before Actual diagnostic output: <details</details
Output from rustc 1.43 (): The size of the output appears to be a recent regression.
: searched nightlies: from nightly-2020-03-09 to nightly-2020-06-21 regressed nightly: nightly-2020-03-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsLooks like ?
Further testing confirms , specifically  introduced the large number of diagnostics.
Assigning .
Code change:
// u8 literal, push to vector expression ast::LitUint(v, ast::TyU8) => { if v > 0xFF { <del> cx.span_err(expr.span, "too large u8 literal in bytes!") </del> <ins> cx.span_err(expr.span, "too large u8 literal in bytes!"); err = true; </ins> } else { bytes.push(cx.expr_u8(expr.span, v as u8)); }

Related discussion:
text: With landed, the lifetime of is now problematic. Specifically, the following used to work and now fails: The lifetime of is now limited to that branch of the match, so it doesn't live long enough to be assigned to . I'm not sure if this means lifetimes need to change. The other option is that needs to return a . Unfortunately, the only way to do that right now is to make it equivalent to , which makes it no longer usable as the value of a constant (e.g. ). I'm thinking the right solution is to make it legal for me to say . I can type that right now, but the lifetime seems to be wholly ignored, as I get the exact same error with the following as I do with the example above: If becomes a valid expression with the lifetime, then could start evaluating to that and everything should work as expected. Furthermore, it would be nice (but perhaps not required) if , where all elements are compile-time constants, would implicitly be given the lifetime.
/cc
Yeah, this is kind of annoying. I worked around it in one specific case by having bytes! expand as follows: I certainly think one should be allowed to write a concrete lifetime as part of a slice or borrow expression, and ought to be legal -- we'll obviously have to impose more stringent constant-related rules. In the short term, we could adjust to expand in the pattern I showed above. What was unclear to me was whether this is sufficient workaround, or whether we'll want something more general. Interestingly, even if we used full inference, the expression you gave above would be illegal unless we introduce a special case for static byte strings, because it generates a conditional temporary (only on one arm of the match) and we can't handle the cleanup for such a case without zeroing, which we plan to remove (well, I guess we could also have a special case for temporary types [like ) that do not require drop glue, but I'd rather not).
Perhaps the simplest fix for now is to adjust the macro itself to expand to a static item as I showed. I should probably have done that more generally but I was ready to land that expletive branch already.
Won't that prevent from being able to expand to a static?
I already adjusted like that and is correct, it prevents , which is definitely already used in our codebase.
Ah, unfortunate.
Code change:
// u8 literal, push to vector expression ast::LitUint(v, ast::TyU8) => { if v > 0xFF { <del> cx.span_err(expr.span, "too large u8 literal in bytes!") </del> <ins> cx.span_err(expr.span, "too large u8 literal in bytes!"); err = true; </ins> } else { bytes.push(cx.expr_u8(expr.span, v as u8)); }

Related discussion:
text: (I actually think we should allow statics to include nested blocks with other statics, but I guess that's a separate bug) Well, I'm not sure what's the easiest fix in that case, I guess just to fix the semantics of so that it guarantees static data. I'm not 100% sure what's implied by such a fix: it doesn't seem too hard ;)
cc
Code change:
<ins> // Test for issues/115517 which is fixed by pull/115486 // This should not ice trait Test<const C: usize> {} trait Elide<T> { fn call(); } pub fn test() where (): Test<{ 1 + (<() as Elide(&())>::call) }>, //~^ ERROR cannot capture late-bound lifetime in constant { } fn main() {} </ins>

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. --: <details<summary<strongError output</strong</summary<p</p</details<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2022-09-05 commit[0] 2022-09-03: Auto merge of - cjgillot:old-no-lt, r=estebank commit[1] 2022-09-04: Auto merge of - matthiaskrgr:rollup-9n0257m, r=matthiaskrgr commit[2] 2022-09-04: Auto merge of - nikic:update-llvm-7, r=cuviper commit[3] 2022-09-04: Auto merge of - jswrenn:transmute, r=oli-obk commit[4] 2022-09-04: Auto merge of - klensy:bump-deps-08-22, r=Dylan-DPC commit[5] 2022-09-04: Auto merge of - compiler-errors:head-span-for-enclosing-scope, r=oli-obk commit[6] 2022-09-04: Auto merge of - matthiaskrgr:rollup-uj24yb5, r=matthiaskrgr commit[7] 2022-09-04: Auto merge of - asquared31415:vec-zero-opts, r=thomcc
Minimal: This has nothing to do with the transmutability feature. Also, it's fixed by , since the above desugars to:
WG-prioritization assigning priority (). label -I-prioritize +P-medium -needs-triage
This is but needs a test. To whoever does it, please commit the example I minimized and not the other one, since we don't need to make the test depend on the transmutability feature.
Code change:
mingw-check: IMAGE: mingw-check <del> # TODO: enable this job if the commit message matches this regex, need tools # figure out how to get the current commit message on azure and stick it in a # condition somewhere #     if: commit_message =~ /(?i:^update.*b(rls|rustfmt|clippy|miri|cargo)b)/ # - job: Linux-x86_64-gnu-tools #   pool: #     vmImage: ubuntu-16.04 #   steps: #     - template: steps/run.yml #   variables: #     IMAGE: x86_64-gnu-tools </del> <ins> - job: LinuxTools pool: vmImage: ubuntu-16.04 steps: - template: steps/run.yml parameters: only_on_updated_submodules: 'yes' variables: IMAGE: x86_64-gnu-tools </ins>

Related discussion:
text: This issue is meant to track where on Travis we currently whenever the commit message looks like it updates a submodule. We should enable something similar for Azure Pipelines where whenever a PR is detected as updating a submodule (either via actually looking at the git history or at the git commit message) then we schedule the builder on the PR. The purpose of this PR build is to help weed out errors even sooner than before where we're just running a smoke tests on Linux on each PR.
Code change:
<ins> warning: public documentation for `private_from_crate_level` links to private item `my_module` --> $DIR/private-from-crate-level.rs:3:6 | LL | //! [my_module] |      ^^^^^^^^^ this item is private | = note: `#[warn(rustdoc::private_intra_doc_links)]` on by default = note: this link will resolve properly if you pass `--document-private-items` warning: 1 warning emitted </ins>

Related discussion:
text: It should say instead.
Relevant code: I think the fix is to use the crate name instead of .
Also, I would be curious to see if you can remove altogether by using : That might break renamed modules maybe? I don't remember how modules interact with re-exports.
Code change:
use crate::flags::{Color, Flags, Warnings}; use crate::util::{exe, output, t}; use once_cell::sync::OnceCell; <ins> use semver::Version; </ins> use serde::{Deserialize, Deserializer}; use serde_derive::Deserialize;

Related discussion:
text: I'm trying to build Rust on a Tier 3 platform (; actually it's that's listed in Tier 3, but I don't think that affects the problem). Since there are no snapshots for this platform, I installed rustc from the distro's package manager (apk) and created a file to force using the pre-installed rustc rather than downloading snapshots: And the output of : I ran ; when it got as far as building the core library, I got a series of errors that were very hard to make sense of until I realized that it's because core library code depends on unstable features and I was using a stable rustc to compile it: There were many more errors, but I think they all relate to unstable features. It took me ages to figure out that (for example) the first error is due to the feature being disabled in stable. I understand that the stable compiler won't allow using unstable features even with , but is it possible for the parser to recognize this code even so and reject it with something like "feature is not enabled" instead of the much more generic "expected identifier" error?
Huh, usually Rust gets around this by setting , and usually when we bootstrap it's with a beta compiler, which does need that set by , and that would allow all the features. I wonder if wasn't set?
It's set, but the command that's actually failing (it took some effort to figure out which executable was actually failing) is: And what's installed for me in is a stable compiler. I realized after the fact that I can't use it to bootstrap, but with a different error message I might have noticed that sooner.
Forwards compatibility in diagnostics seems extremely hard. I think a much simpler and more helpful fix is to check the output of in bootstrap and give a hard error if it's not either the current version or N-1.
Note that the problem here is that you were trying to use 1.68 to build 1.70; it's unrelated to stable vs beta, the problem is that it was two versions behind instead of only one.
Mentoring instructions: in , if is set, run that process with . Compare that output to the contents of using the crate; if the minor versions aren't either the same or 1 apart, give a hard error. Note that this should also disallow e.g.
Code change:
use crate::flags::{Color, Flags, Warnings}; use crate::util::{exe, output, t}; use once_cell::sync::OnceCell; <ins> use semver::Version; </ins> use serde::{Deserialize, Deserializer}; use serde_derive::Deserialize;

Related discussion:
text: building 1.68 with 1.69; we use deny-warnings in most cases and have no guarantees that unstable features will be the same between releases. Only building 1.68 with 1.67 or 1.68 should be allowed.
btw I've noticed you running into a few different bootstrap bugs the past few days — reading through https://rustc-dev- may or may not make it easier to diagnose these issues without having to spend ages interpreting the diagnostics. I'm also happy to chat about "how should this work" sorts of things .
Yes, I've read that. Thanks!
The error message could be improved though. Maybe one could make the to put into libcore/bootstrap's
I don't think rust-version is a good way to solve this, no - that won't give a warning or error if you use a future version to compile an older version. Also it won't be able to catch local-rebuild issues where the nightly version of the bootstrap compiler is too old. See my suggestion in
Hmm, I'm afraid I might have said something unclear. I'm not asking for forward compatibility in diagnostics. The feature was in version 1.68.0, according to , and I was using rustc version 1.68.2. So it should "know" about that feature, but my understanding is that when I was invoking rustc it was with flags that prevent unstable features from being used.
hmm, in that case something strange is going on because playground gives a much more reasonable error than the one you saw:
what commit of rustc were you trying to build when you got this error? I'm going to see if I can replicate it locally.
I was trying to build .
Ah ok, it was related to the context of the closure: If you look at the same gist with beta, the error message is much better: So I think this particular diagnostic issue has already been fixed. I still want to keep this issue open to track checking the version of the bootstrap compiler, though.
Code change:
<ins> // Regression test for <https://github.com/rust-lang/rust/issues/100529>. #![no_core] #![feature(no_core)] // @has "$.index[*][?(@.name=='ParseError')]" // @has "$.index[*][?(@.name=='UnexpectedEndTag')]" // @is "$.index[*][?(@.name=='UnexpectedEndTag')].inner.variant_kind" '"tuple"' // @is "$.index[*][?(@.name=='UnexpectedEndTag')].inner.variant_inner" [null] pub enum ParseError { UnexpectedEndTag(#[doc(hidden)] u32), } </ins>

Related discussion:
text: At some point their should also be a for , and probably a way to tell what position each of the non stripped items are, as currently each of these 3 variants are documented with the same inner. but HTML gets a good representation:  The solution is probably to do what we do for structs, and store the , and a , such that each field of a varient gets an to hold the . We also should have a numfields, as even in that schema, you can't tell the difference between This also effects struct AFAIKT. I don't think this needs to be done now. I'll file an issue for it. Originally posted by in modify labels: +A-rustdoc-json +T-rustdoc
Related:
Code change:
let f1: f64 = FromStrRadix::from_str_radix("1p-123", 16).unwrap(); let f2: f64 = FromStrRadix::from_str_radix("1p-111", 16).unwrap(); let f3: f64 = FromStrRadix::from_str_radix("1.Cp-12", 16).unwrap(); <del> assert_eq!(Float::ldexp(1f64, -123), f1); assert_eq!(Float::ldexp(1f64, -111), f2); </del> <ins> assert_eq!(1f64.ldexp(-123), f1); assert_eq!(1f64.ldexp(-111), f2); </ins> assert_eq!(Float::ldexp(1.75f64, -12), f3); assert_eq!(Float::ldexp(0f64, -123), 0f64);

Related discussion:
text: has an unusual format: it takes as it's first parameter where everything else in the trait takes . It should take as it's first parameter for consistency with everything else. It is located in 
+1. There are a few different things to consider here, though: does not operate on any FP number per se like most other operations do, but rather constructs a new FP number from two arguments one of which happens to be FP number. This function’s signature is consistent with most other methods that construct some kind of FP number (e.g. ). We might want to consider whether methods such as shouldn’t just go ahead and take instead. can’t currently be chained, but I see literally 0 cases where anybody would chain this function. cc
Okay, but from a consistency standpoint, it's like 1/80 for vs . It it keeps the same format, it and it's similar functions would probably be better to go at the end or beginning of the function list where they won't be so unusual.
Nominating for 1.0-beta P-backcompat-libs
One should be able to call this thing as a method, one way or another. We need to make sure that is resolved.
0 beta, P-backcompat-libs
I started to fix this.
Code change:
} if !provided.is_empty() { write!(w, " <del> <h2 id='provided-methods'>Provided Methods</h2> </del> <ins> <h2 id='provided-methods' class='section-header'> <a href='#provided-methods'>Provided Methods</a> </h2> </ins> <div class='methods'> ")?; for m in &provided {

Related discussion:
text: A page like has many things that could be useful to link to. These should be possible to link to by clicking on: [x] The header [x] 's on a page. [x] at the top On it's hit or miss: [x] Examples [x] Associated Types [x] Required Methods [x] Implementors On [x] Provided Methods I don't have any big use cases but when I want to link to these for something like this bug I can't link to any specific line. I gotta say go to vec page, scroll 75% to bottom. Squint hard to see it.
Just ran into this today; I'd really like to have links from the impls in the Implementors section to the source containing the impl.
Triage: we always need more links....
Update: Headers written in docs and (most) auto-generated headers are either fully hyperlinked or have a "section marker" symbol that shows up on hover. Major auto-generated page headers have links in the top of the sidebar of the page. Impl blocks do not have hyperlinks (yet); that's
Since got merged and closed out , that was the last major request on this issue, so i'll close this out. If you think of something else that needs a hyperlinked header, feel free to open a new issue or reopen this one.
Code change:
} else { "traits define" }, <del> action = if let Some(param) = param_type { format!("restrict type parameter `{}` with", param) } else { "implement".to_string() }, </del> <ins> action = action, </ins> one_of_them = if candidates.len() == 1 { "it" } else {

Related discussion:
text: The following example code yields an error: It's unclear from this error message how to proceed - I'm not sure of the syntax, location, or where I should be putting the "GetString" trait bound. It should be shown with a better example or link when this error is presented, as the current message is not sufficient for a resolution to be arrived at.
cc
Fixing in . To fix your code write:
Thanks!