jiebi/CodeConvo huggingface dataset:
Change:
fn run(self, builder: &Builder<'_>) { let stage = self.stage; let target = self.target; <del> let out = builder.doc_out(target); </del> <ins> let out = match self.format { DocumentationFormat::HTML => builder.doc_out(target), DocumentationFormat::JSON => builder.json_doc_out(target), }; </ins> t!(fs::create_dir_all(&out)); builder.ensure(SharedAssets { target: self.target }); let index_page = builder.src.join("src/doc/index.md").into_os_string(); <del> let mut extra_args = vec![ OsStr::new("--markdown-css"), OsStr::new("rust.css"), OsStr::new("--markdown-no-toc"), OsStr::new("--index-page"), &index_page, ]; </del> <ins> let mut extra_args = match self.format { DocumentationFormat::HTML => vec![ OsStr::new("--markdown-css"), OsStr::new("rust.css"), OsStr::new("--markdown-no-toc"), OsStr::new("--index-page"), &index_page, ], DocumentationFormat::JSON => vec![OsStr::new("--output-format"), OsStr::new("json")], }; </ins> if !builder.config.docs_minification { extra_args.push(OsStr::new("--disable-minification"));

Discussion:
running only builds the html doc, but builds the json doc. I expected the json flag to act as the documentation says (): using the master branch of this repo commit running with a library profile.
I can't reproduce this. The files show up for me in .
Seems to reproduce, I could totally have overlooked a step tho
oh no it's even simpler than that lol it's calling the wrong function that should be JsonStd, not Std
Should I make the PR or are you gonna do it ?
If you could make a PR that would be great :)
Made the PR but since just changing the ensure wasn't enough there's a thing I'm unsure about (tested it, worked, but could be cleaner)
Change:
ToLowercase(CaseMappingIter::new(conversions::to_lower(self))) } <del> /// Converts a character to its titlecase equivalent. /// /// This performs complex unconditional mappings with no tailoring. /// See `to_uppercase()` for references and more information. /// /// This differs from `to_uppercase()` since Unicode contains /// digraphs and ligature characters. /// For example, U+01F3 “ǳ” and U+FB01 “ﬁ” /// map to U+01F1 “Ǳ” and U+0046 U+0069 “Fi”, respectively. /// /// # Return value /// /// Returns an iterator which yields the characters corresponding to the /// titlecase equivalent of the character. If no conversion is possible then /// an iterator with just the input character is returned. #[unstable(feature = "unicode", reason = "recently added")] #[inline] pub fn to_titlecase(self) -> ToTitlecase { ToTitlecase(CaseMappingIter::new(conversions::to_title(self))) } </del> /// Converts a character to its uppercase equivalent. /// /// This performs complex unconditional mappings with no tailoring:

Discussion:
Converting a string to titlecase requires a word-breaking algorithm, which std does not provide. We do have the method for converting a single char to titlecase, if one can identify the first char of a word. This method requires a few kb of lookup tables. We might want to consider whether its wise to ship one without the other. This is marked for stabilization in 1.2 so we need to decide soon. cc
so I'm fine just deleting it, I don't think it's marked to be stable.
Change:
trait X<K>: Sized { fn foo<'a, L: X<&'a Nested<K>>>(); //~^ ERROR may not live long enough // check that we give a sane error for `Self` fn bar<'a, L: X<&'a Nested<Self>>>(); //~^ ERROR may not live long enough <ins> // check that we give a sane error for nested generics fn baz<'a, L, M: X<&'a Nested<L>>>() { //~^ ERROR may not live long enough } </ins> } <ins> trait TraitB {} </ins> struct Nested<K>(K); impl<K> Nested<K> { fn generic_in_parent<'a, L: X<&'a Nested<K>>>() {

Discussion:
When using to build one of my projects, I got the error I tried to minimize my code and got to . : with the command I got the error : : backtrace :
I can reproduce this with:
Change:
cargo.arg("--no-deps"); cargo.arg("-p").arg("rustdoc"); <del> cargo.env("RUSTDOCFLAGS", "--document-private-items"); </del> <ins> cargo.rustdocflag("--document-private-items"); </ins> builder.run(&mut cargo.into()); } }

Discussion:
Compare , this was intentional Items which are private, like , have disappeared
The warnings is removed in .
The haven't never been public. Not sure if I made it disappeared. cc
Also this page is 404 now. Before it listed all the internal crates.
I don't see how your PR could've done that -- cc I think you recently had a PR touching document-private-items?
The PR just changed some warnings around intra-doc-links, nothing to do with . My suspicion since the index page is gone is that something changed in bootstrap.
I take it back, I did modify href in That was a few weeks ago now and should have documented strictly more items, though.
This is the issue I pointed out in the second part of I clearly didn't explain the issue well enough.
Change:
// which diverges, that we are about to lint on. This gives suboptimal diagnostics. // Instead, stop here so that the `if`- or `while`-expression's block is linted instead. if !span.is_desugaring(DesugaringKind::CondTemporary) && <del> !span.is_desugaring(DesugaringKind::Async) </del> <ins> !span.is_desugaring(DesugaringKind::Async) && !orig_span.is_desugaring(DesugaringKind::Await) </ins> { self.diverges.set(Diverges::WarnedAlways);

Discussion:
I tried this code: I expected to see this happen: no build warn Instead, this happened: :
We . The likely cause is that parts of the await desugaring are being linted against. We can likely check the span to see if the code that is being linted against is part of the desugaring, but we do want to be careful to ensure that still gets a lint warning.
Marking as deferred as this doesn't seem like a problem that needs to block stabilization.
cc who has done some work on the inhabited logic stuff.
I'm now getting this warning even for functions that loop but eventually return. It worked fine with nightly-2019-08-21, but the latest nightly (2019-09-17) is broken. For example, this code generates a warning: with the warning repeated twice:
Can confirm. I believe this regressed somewhere after nightly 09-09-2019.
I think I have this in my code here: Can somebody confirm this? If not I'll file another bug report.
yeah that's the same, the function can "never" return from the unconditional loop.
Change:
import rustc::syntax::{ast, codemap}; import rustc::syntax::parse::parser; import rustc::util::filesearch::{get_cargo_root, get_cargo_root_nearest, <del> get_cargo_sysroot}; </del> <ins> get_cargo_sysroot, libdir}; </ins> import rustc::driver::diagnostic; import std::fs;

Discussion:
There's some code for this in cargo now, but it doesn't quite do the right thing. See .
Also worth considering the difference between sysroot and the install prefix - they are not the same. For instance, I never install cargo, always running it out of the build directory, in which case the build directory is sysroot.
I think this is resolved.
Change:
} ``` <del> Any type parameter or lifetime parameter of an `impl` must meet at least one of </del> <ins> Any type parameter parameter of an `impl` must meet at least one of </ins> the following criteria: - it appears in the _implementing type_ of the impl, e.g. `impl<T> Foo<T>`

Discussion:
Unconstrained lifetime parameters are actually allowed: Unlike what's described here: For comparison, unconstrained type parameters do generate error:
I would like to address this. What should be error message for E0207?
Maybe just don't mention lifetime parameter?
I think this has been fixed already. Can you please try again?
I don't think it has been: still mentions lifetime parameter.
Sorry My bad. I missed checking this file. Let me fix and raise PR.
Thanks :+1:
Change:
//! parent directory, and otherwise documentation can be found throughout the `build` //! directory in each respective module. <del> // NO-RUSTC-WRAPPER #![deny(warnings, rust_2018_idioms, unused_lifetimes)] </del> use std::env; use bootstrap::{Config, Build};

Discussion:
When using 1.38 beta to bootstrap itself, I get:
This is expected and not a supported bootstrapping configuration; if you want to not see these errors you'll want to either bootstrap with N-1 compiler (so, in this case, 1.37) or I believe remove from bootstrap and some other libraries, as well as set deny-warnings in to false. Note that only the 1.37 bootstrap method is officially supported as "guaranteed to work", the deny warnings fix is more of a hack. Closing as won't fix.
Huh? In the past this was always fixed as it's a very common practice for distribution packaging (I don't know of a single packager not doing that). See e.g. or (in which you sort of acknowledged that yourself) deny-warnings is already set to false in , so I guess it somehow doesn't apply to building bootstrap itself.
I hope is an acceptable compromise wrt this. Thanks for pointing out the deny-warnings option which I forgot (since it has been set to false forever for us and never had any effect on the build of bootstrap itself)
Yeah is great; in this case the unsafe block is needed for 1.37 but not on 1.38; if there was an easy way to support both use cases then I'd be happy to accept a PR targeting beta but I'm not personally aware of one -- it looks like we don't seem to have an or similar? We try to support distros and such where possible in this configuration, it's just that this specific case I'm not sure how much we can do. deny-warnings=false is always my recommendation when using a different bootstrap compiler, or manual patches to the code.
Change:
Self::Prefix(prefix) => format!("{}@{}", prefix, path_str), Self::Function => format!("{}()", path_str), Self::Macro => format!("{}!", path_str), <ins> Self::RemoveDisambiguator => path_str.into(), </ins> } } }

Discussion:
Unfortunately I don't have an easy-to-repro case. This happened while working on Rocket's docs. I renamed a method which made a previously valid link invalid and I got this ICE. Fixing the doc link fixes the error. Backtrace from rustc 1.54.0-nightly ( 2021-05-21) follows: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If someone can compile a build of rustdoc that comments out this line: you should get a much better error message that says exactly what went wrong (it will start with "incompatible link kind"), and that should give an idea of where the bug is.
can you link to the exact commit of Rocket that caused the ICE?
This is the current tip, You may be able to replicate this by referencing in the struct's docs in and then changing the method's name to something else. If this fails, I will try to create a reproducible case.
MCVE: label -E-needs-mcve
claim
Error: Parsing relabel command in failed: ...'needs-MCVE' '): rs'... Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'needs-mcve' '): rs'... Please let know if you're having trouble with this bot.
Change:
<ins> error: generic `Self` types are currently not permitted in anonymous constants --> $DIR/issue-47814.rs:8:32 | LL |     pub fn to_buffer() -> [u8; Self::LENGTH] { |                                ^^^^ | note: not a concrete type --> $DIR/issue-47814.rs:5:10 | LL | impl<'a> ArpIPv4<'a> { |          ^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
EDITED: MCVE is here: I tried to compile the following, which caused the rust compiler to panic. The following compiles just fine: The error message: And running again with verbosity and backtrace: Running nixos 17.09 using rust nightly installed using the mozilla nixpkgs overlay. It's about a month out of date, so I'll check the updates.
This still crashes as of the most recent nightly. Self-contained repro: Mentioning who this assertion in .
That was confusing at first, heh - the multi-line message which doesn't split custom messages on their own line doesn't help at all (can we split it off?). So what's happening is the length expression is using a generic parameter in its outer scope. This hasn't ever been supported, but it's extremely obnoxious to prevent - we could ban in but that already works in some specific situations, so it'd be backwards-incompatible. This problem would get properly fixed once we actually start supporting generics-in-scope for array expressions, and that can't happen without lazy normalization (cc
I'm having the same problem still. succeeds in making the compiler cry about the function call in the array size, but with the compiler panics. Here's my :
exampe ICEs at , cc
Issue is still present on current stable and nightly. Just wanted to add that it only occurs when using a lifetime parameter. example ICEs whereas the following with removed lifetime parameter works fine.
Triage: This is no longer ICE with the latest nightly:
Change:
<ins> mod glob_ok { pub mod something { pub mod something_else {} } } mod single_err {} use glob_ok::*; // glob_ok::something use single_err::something; //~ ERROR unresolved import `single_err::something` use something::something_else; fn main() {} </ins>

Discussion:
the code i tried: noticed there was a typo, fixed it, still getting an ICE i expected: cargo-generate/pull/135, to not compile and give an error about typo cargo-generate/pull/136, to compile (and no longer display 2018 warnings about path clarity) instead, what happened: system info:
i also get this on stable and earlier nightlies, if that is at all useful.
(also please feel free to let me know if i can provide any more info- this is my first time filing a compiler bug! thanks for all your hardwork and help <3)
Nominating -- we should keep focus on Rust 2018-related bugs like this, I think.
Did you? I mean, there is a typo, right? Do you mean, you expected a controller error? Specifically I see this in the diff: and I think it should be ?
I guess you are saying you get the same ICE from , which has a fix... did you try a cargo clean? (I'm wondering if it is related to incremental compilation.)
yeah, so i noticed the typo, and then fixed it (hence the 2 PRs- i included both on the offchance that there were 2 issues.) i expected the 2nd one to compile, and the first one (after i noticed the typo, to not compile but give an error re: the typo). i will run a cargo clean and see if it helps!
OK, thanks for the clarification.
just ran and then and have the same error message.
Fixed in
Change:
pub fn lvalue_temps<'bcx,'tcx>(bcx: Block<'bcx,'tcx>, mir: &mir::Mir<'tcx>) <del> -> FnvHashSet<usize> { let mut analyzer = TempAnalyzer::new(); </del> <ins> -> BitVector { let mut analyzer = TempAnalyzer::new(mir.temp_decls.len()); </ins> analyzer.visit_mir(mir);

Discussion:
In MIR we want values to be SSA, however ensuring that constraint in trans (i.e. in TempRef) is wrong, I think. Namely, for code like this: we will generate following MIR (graphviz version, because easier to visualise): ! which will result in Note how we assign twice, but the two branches are fully disjoint, and thus, for the purposes of data-flow is still SSA, but for the purposes of translator is assigned multiple times. If we want s to stay across translation of the whole function, we will need something like a in the MIR. cc
Another option would be to convert these temporaries into lvalues (i.e. variables). Could it be that the unfinished is supposed to do just that?
I am confused. We do not require temps to be SSA, either in Mir or trans... But in trans we optimize in those cases where we can (I.e., where temps are SSA). Right?
suggests they are SSA with borrowing and mutation possible. Might be me misinterpreting what SSA means, but what I mean is that these are not supposed to be assigned more than once, for some definitions of once.
I see. Yes, ok, I agree that comment was in error. I think though that you probably ought to update it in :) I would still expect temps to be "DSA" -- which afaik I just made up -- that is, no two writes can reach one another without exiting the "live scope" of the temporary, but I don't know that it's an important property. FWIW I think SSA usually implies that values are "pure values", i.e., you can't take their address and mutate them. But I know what you mean in any case.
er, ought to have updated it
I’ll keep updating the comment in mind in whatever PR that comes next.
Change:
fewer_names: Option<bool> = (None, parse_opt_bool, [TRACKED], "reduce memory use by retaining fewer names within compilation artifacts (LLVM-IR)  (default: no)"), <ins> fixed_x18: bool = (false, parse_bool, [TRACKED], "make the x18 register reserved on AArch64 (default: no)"), </ins> flatten_format_args: bool = (true, parse_bool, [TRACKED], "flatten nested format_args!() and literals into a simplified format_args!() call  (default: yes)"),

Discussion:
On the target, specifying the target feature using the flag results in the following warning: The desired effect of this flag is to reserve the x18 register so that LLVM does not use it during codegen. Note that despite the warning, the flag still works fine today since it is passed on to LLVM. This feature is necessary for Rust to work when using the Linux Kernel's dynamic shadow call stack feature on aarch64 (). The shadow call stack feature requires that the x18 register is reserved, since it is used to store the shadow stack. In C code, the dynamic version of shadow call stack requires you to pass but not (which is only used for non-dynamic SCS). Clang has a collection of flags for reserving other registers than x18 as well. I think it would make sense to add those as well, even if they are less useful than x18. Related to . Related to .
This affects the ABI, right? I think adding a target spec option makes the most sense (or actually you can already set it as target feature in the target spec without giving a warning). That way you can't enable or disable it for individual functions or crates, which would break the ABI.
Yeah, it would be nice to have a flag for this (or having something like "global target features", i.e. like , but that it ensures it is set the same way for all compilation units).
There could be ABI concerns with this in general. AAPCS64 defines x18 as a platform register if required, or temporary if a platform register isn't needed. For x18 it's probably unlikely for it to have ABI concerns as it's already reserved for use on some platforms, the ones where it's not already reserved, it's only supposed to be a temporary register so not using it should be OK as it is not used for any fixed purpose. That's obviously assuming a platform defines its ABI based on the Arm standards. LLVM does support reserve on other registers, most notably for ABI reasons, x1 through x7 which would have ABI problems. LLVM does have test cases to ensure that a function call doesn't occur if any of the argument registers have been reserved. I'm not sure what other codegen backends do in that case though, or if they even support reserving those registers.

The analysis that LLVM does, doesn't seem to care if it would need to use that register for ABI reasons, even a function such as can't be called in a quick test. Using target features for this feels strange to me though, I'm wondering if a codegen option to reserve certain registers would be a better approach here. While this issue is specifically about reserving a register on AArch64, LLVM does support this for multiple other architectures and multiple registers, which we should maybe consider for the future.
Change:
<ins> // check-pass #![feature(type_alias_impl_trait)] type Opq = impl Sized; fn test() -> impl Iterator<Item = Opq> { Box::new(0..) as Box<dyn Iterator<Item = _>> } fn main(){} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- Regressed between ( 2022-07-17) .. ( 2022-07-21). ~Probably ~. Cc Edit: Regressed in Minimized from . Cc label regression-from-stable-to-nightly A-impl-trait <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Duplicate of
No wait, huh? That's another issue
This must've been broken before. That revert should not be able to cause a stable to nightly regression
I was wrong, bisection points to . I guess it is . Cc
claim
Change:
pub span: Span, #[help] pub item_span: Span, <ins> // Used for evading `-Z deduplicate-diagnostics`. pub force_duplicate: usize, </ins> } #[derive(Subdiagnostic)]

Discussion:
I tried the following code: output after running for a very long time: modify rustc as follows results in the following output: changing the invocation to actually prints the warning at each power of two of steps. This warning should not be affected by . It's whole point is to be repeated multiple times. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I honestly don't remember if we want it to be repeated or not. Is there even a way for a single diagnostic to opt-out of deduplication? I guess we could put some number into the error message so that it's not the exact same diagnostic each time.
yes, we have full ownership of rustc, we can the deduplication code to stop duplicating this single warning while keeping everything else the same :grin:
claim
Change:
use rustc_data_structures::fx::{FxIndexMap, FxIndexSet}; use rustc_errors::{ codes::*, pluralize, struct_span_code_err, Applicability, Diag, DiagCtxt, DiagStyledString, <del> ErrorGuaranteed, IntoDiagArg, </del> <ins> ErrorGuaranteed, IntoDiagArg, StringPart, </ins> }; use rustc_hir as hir; use rustc_hir::def::DefKind;

Discussion:
Here it's obvious, but when the error says that it is mismatched with and that "types differ in mutability" then I have zero chance of figuring what's going on. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim Sounds like a feature I would like to use as well.
Change:
} /// Return `a` <= `b` lexicographically (Using partial order, `Ord`) <del> pub fn le<A: Ord, T: Iterator<A>>(mut a: T, mut b: T) -> bool { </del> <ins> pub fn le<A: Ord, T: Iterator<A>, S: Iterator<A>>(mut a: T, mut b: S) -> bool { </ins> loop { match (a.next(), b.next()) { (None, None) => return true,

Discussion:
They're currently very restricted as they only work with a single iterator type for both arguments, so, e.g. doesn't work. It should be easy to just add another parameter for the second argument.