jiebi/CodeConvo huggingface dataset:
<!-- 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. --Given a public type, I expected all traits implemented by that type to be part of rustdoc JSON output. However, rustdoc JSON output sometimes does not include information about all the traits implemented by a type unless is specified. For example, in this : The following invocation on v3.1.18 generates JSON stating that is implemented for : However, the following invocation has no mention of for at all: Related to: :
cc
modify labels: +E-needs-mcve
Interestingly, rustdoc-json is providing no impls at all: norunn# use clap::{Command, Arg};nlet matches = Command::new("MyApp")n .arg(Arg::new("out")n .long("output")n .required(true)n .takesvalue(true))n .arg(Arg::new("debug")n .short('d')n .multipleoccurrences(true))n .arg(Arg::new("cfg")n .short('c')n .takesvalue(true))n .getmatches(); // builds the instance of ArgMatchesnn// to get information about the "cfg" argument we created, such as the value supplied we usen// various ArgMatches methods, such as ArgMatches::valueofnif let Some(c) = matches.valueof("cfg") {n println!("Value for -c: {}", c);n}nn// The ArgMatches::valueof method returns an Option because the user may not have suppliedn// that argument at runtime. But if we specified that the argument was "required" as we didn// with the "out" argument, we can safely unwrap because verifies that was actuallyn// used at runtime.nprintln!("Value for --output: {}", matches.valueof("out").unwrap());nn// You can check the presence of an argumentnif matches.ispresent("out") {n // Another way to check if an argument was present, or if it occurred multiple times is ton // use occurrencesof() which returns 0 if an argument isn't found at runtime, or then // number of times that it occurred, if it was.
To allow an argument to appear more thann // once, you must use the .multipleoccurrences(true) method, otherwise it will only return 1 or 0.n if matches.occurrences_of("debug") 2 {n println!("Debug mode is REALLY on, don't be crazy");n } else {n println!("Debug mode kind of on");n }n}n
Missing impls is probably a recent regression, see
MCVE produces () and with () modify labels: -E-needs-mcve
This is almost certanly due to searched nightlies: from nightly-2022-07-01 to nightly-2022-08-08 regressed nightly: nightly-2022-07-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
More minimal (no_core) Is correct in html ! and wrong in json
running produces this record for the type : I would expect "impls" to not be blank, since the matrix implements many traits and has a non-trait implementation as well. The paths entry also does not contain as well as many other types exported by the crate, is this expected ? I know that these paths included all exported types before : :
Now running with produces: So i think there's been a regression since then
Thank you for reporting labels +A-rustdoc-json +T-rustdoc
Seems like this could be another symptom of the regression reported as
This is the same issue as Items in a non-public module (ie accessed only via imports) have no impls
At some point between Rust 1.34.0 and 1.39.0, the ability to add documentation to reexported items was , but I can't find it mentioned in either or the rust- blog posts. Maybe this should be mentioned in the RELEASE notes for the version that that feature? I have a crate that I use to test stuff, and used to document this: !
This was changed in 1.38 (coincidentally also the release rust-std spiked from a 61.2 MB to 173.3 MB download). are you interested in making a PR?
Sure, what are the PRs that made this possible?
Oh I have no idea :laughing: I found it by bisecting.
Looks like is it
I hope this is not already known, but my searching has not turned up anything. Compiling a rust binary with the dependency panices in nightly. How to reproduce: a new rust binary. to dependencies in This gives the following output It compiles on stable and beta. Edit: Just running in gives the same result.
Tried a few different nightlies. And it looks like it broke sometime between and
I have managed to get a much smaller example. Compiling this on nightly gives the above panic:
Looks like it's fixed in the newest nightly ()
Bisecting between ... gives as the regression PR.
Was looking at the printout of llvm passes when I noticed that the functions that was inlined everywhere, and due to this was dead code, was optimized more after inlining. So as a test I at the line and this reduces the compile time of release build in racer by an average of 23%. I do not know if this is a good place to add this extra pass but maybe someone that knows how llvm works can use this information to speedup the compilation of release builds. was also wondering how this works in MIR I see that there is an inline pass but I can not find any dead code elimination
the stage1 compilation of rustc went from 828.89 to 691.75 secs with this fix on my computer but that is only a 15% improvement
15% is pretty significant.
Wow, great work!
That's some nice improvements! If you feel up to it, go ahead an submit a pull request with your suggested changes. That way someone with experience with LLVM is guaranteed to look at the patch and it won't get lost.
I believe the PR should be targeted at
:+1: If you want to push through this patch the general process works like this: Submit the patch against the currently active branch of (which is at the moment) Wait for it to get reviewed & merged Submit a pull request against which updates the submodule. If you have any questions about the process or want someone else to do this, just mention it here or contact me or someone else on one of the .
cc
cc
Ideally, the process should include discussion with upstream LLVM too.
Unfortunately it looks like we were a bit too eager to close this in :(
From what I have learned from the llvm maintainers I think that we have received the improvement that can be expected. The to good to be true improvements I measured was probably due to less optimizations was possible and resulted in less optimized code.
I tried to build on a new machine. Got this message: Which I'm used to. I googled a bit, installed , figured out how to get PATH set up, et cetera. Then I built again. And got this: I'm not sure, but: Isn't solely necessary in our build for building LLVM? if that's the case, then shouldn't both the failure and the failure be providing the same level of feedback (namely, suggesting that one side-step building LLVM altogether as an alternative option to downloading and installing )? (Or is the assumption here that will be used by so many crates, people should just bite bullet and install it? Even so, we could give better guidance up front about where to look for it.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I don't think cmake intentionally has a worse error, it's just that a bunch of people building from source for the first time have been confused what ninja is and where to get it. If you made a PR improving the error for cmake I'd approve it :)
label: +E-easy
claim
Hello I'd like to claim this issue if you're interested in releasing it.
Sorry about that Gave it a try but got sidetracked and wasn't really interested in doing it anymore
claim
The CI tests building with all our supported linkers: Rust's provided , ARM GCC's , and ARM GCC's . It recently encountered an error when using in nightly builds since . The most likely culprit is that the failing version has started to the linker arguments, which was not present in previous working versions. I wonder if we're meant to be adding some other argument to disable adding ? The error occurs with the cortex-m-rt CI and can be reproduced like so: Or viewed in CI . The error is: nightly-2023-07-02 nightly-2023-07-03 bisected to from PR modify labels: +regression-from-stable-to-nightly -regression-untriaged
shows that the default for the target is rust-lld. i wonder if the new code uses the default instead of the linker in -C linker for some reason?
You were not meant to do anything, sorry about that. I'll fix it.
I can't build a toolchain locally, via , which would be complete enough for this test to build. There are issues about missing core/std. I tried on a example, and can also reproduce the issue and investigate more there, and that and work. The code I in is asked to add CLI arguments for a flavor: this asks to link using via a c/c++ compiler, and why is . I assume that flavor is incorrect when using ? (I don't know who the target maintainers are, so I'll also ping the other 2 people involved in : and still work because they result in a non- request, and we don't do anything there as expected. For my own understanding: does use by default maybe ? And if so, I'd expect that explicitly specifying the linker would also fix the issue, à la which seems to work for me ? I'll look into why this surprising flavor is used in this situation, as it seems to be the pre-existing issue here uncovered by the PR, and report back. It could be an issue in the flavor inference, or some information missing in the targets' definitions, and so on.
Technically, the target builds. As a tier 2 target, we would strongly prefer it to not require additional antics to build. There was but I have taken lqd's remarks that this may be just exposed preexisting problems as a reason to set it slightly lower.
The linker flavor used is a mix between what can be inferred from the CLI () and the target's default linker flavor: there is no linker flavor on the CLI (and that also offers another workaround on nightly: ), so it will have to be inferred to . in  infers a cc hint, and no hint about lld. the target's is combined in with these hints. We have our , but there is no hint about lld, . It's . so we now have our flavor is the linker people are expected to use on supposed to be some ? Is the default linker and flavor in correct ? In the meantime, I'll see to change this so that the lld flags are only when the unstable MCP510 options are used, to keep this stable and unfortunate behavior unchanged when the CLI and target conflict instead of compose.
Thanks for looking into this quickly! Most people building for will use the default linker today. It works fine for (I believe) all Rust-only projects. However, it's not uncommon to use , maybe to use specific GCC linker script directives, or just when hunting down linker-related bugs. For both of those use cases there's no problem with nightly, and I think the default in thumb_base is therefore fine. Some people do need to use when linking with pre-compiled C libraries - I understand that using gcc pulls in a target specific libc, and a lot of pre-compiled C libraries will be trying to link against symbols it exports which Rust doesn't. I believe does delegate to . Passing either or does work to get a build without errors, though I don't have a test case handy to check it's actually getting what people need out of . I'll try and dig around a bit more for the specific use cases where it's required over .
My main recollection is that gcc requires you to put in front of your linker arguments and using ld directly you don't But I think and friends are gcc options not ld options so maybe ld won't bring in libc and the C startup automatically. I'll test it out shortly.
main.c: Compile object code: Link with GCC: Link with ld: This does imply that for trivial invocations will include both the default start code (which provides ) and newlib (the C library), whilst will not.
See also , where I set the default target for bare-metal SPARC to be gcc, precisely because the default libraries it links in are so useful - they include not only the start-up code (no idea how that works, didn't need to find out) but also a C library for talking to the stdout of a popular SPARC CPU emulator. So, yeah, GCC is a really useful linker driver in some scenarios and we don't want to stop that from working.
Thanks for the information, it's very helpful. The good news is that using GCC as a linker is still working . In the future where we switch to lld, maybe rustc will also need an explicit linker flavor here, to make sure the flavor it guesses actually matches your expectations. But that's a topic for another day/stabilization: in the more immediate future, things will return to normal for the target and 's tests in a day or two.
Thank you! Just to come back to this point: I was under the impression that Arm Ltd were maintaining the targets. However, they don't appear to have the platform-support documentation that is required for more recently targets. Maybe that could be addressed.
This is now on beta, reopening to track backport.
Pursuant to your concern I have opened to summarize the issue that affects indeed all our tier 2 targets.
The backport of has landed on beta in We can close this issue as fixed.
The build time of html5ever has gone up by more than 70% for debug builds recently: There are quite a few candidates for introducing this regression in the changeset: Would anybody from or care to bisect further?
The "tuple stress" benchmark is affected even more while most of the other things have improved. Maybe that gives a hint?
My first guess would be quadratic or exponential blowup. Maybe someone can do a ?
Yes, good idea!
Bisection for tuple-stress points to (cc Before that PR took ~4s and afterwards I killed it after 2m as I didn't want to wait for it to finish
That may also be the source of the html5ever regression. takes 10s before that commit (the entire time) and 21s afterwards.
Thanks, cc also &
Could you post instructions for replicating the slow down? Neither or I could reproduce it -- despite running perf on the appropriate commit range locally.
So should we revert that PR's commits?
sure yeah, using I did the equivalent of:
We should probably only run the disaggregation pass if the opt level is 1. That's what's done for the copy prop pass already
assuming and can reproduce I think yeah we'll probably want to start off by reverting and possibly doing what suggests in a follow-up
I cannot reproduce, which is odd, since I can't tell what the difference could be that would make this much of a difference...
No repro on macOS, although the c116 version is consistently slower than a272. <details</details
Ok I swear I'm not going crazy! I think though given this data it may only be reproducible on Ubuntu 16.04? I can reproduce with this : Can y'all reproduce the slowdown for html5ever?
Sure enough starting the docker image from 18.04 means I cannot reproduce the regression. Maybe some glibc bug was fixed which I was accidentally running into? The html5ever regression though is still worrisome and seems like it may not be connected to a glibc bug
I can repro the tuple-stress slow down on 16.04.4 LTS. indicates it is stuck at the step.
<details<summaryGDB backtrace sample</summary</details<details<summaryCode surrounding the call of that memmove</summary</details
Presuming the same two commits would be responsible for the html5ever regression, I also cannot reproduce it on 18.04 Ubuntu.
Using this dockerfile: I can reproduce the regression from 10s to 20s on html5ever. Starting from 18.04 it does indeed not show a regression. The perf server is indeed 16.04. Ok so it looks like this is a regression specific to something that changed between glibc 2.23 and 2.27. With the profiles it looks like it's something related to the efficiency of memcpy/memmove. It also seems like this isn't reproducible on OSX (thanks ). I can, however, reproduce it locally on Windows 64-bit MSVC. Since could reproduce a slightly slowdown on OSX, I wonder if these code paths do something like exercise a ton of moves? It may be the case that glibc optimized one of its routines in the 2.23 -2.27 transition (and OSX already had it). In that case it may appear like there's no regression on Linux/OSX but on glibc 2.23 and Windows they may have unoptimized versions of the routines causing slowdowns. All in all I think that this is a regression that is still worth fixing, despite it not immediately being applicable on glibc 2.27 or OSX. The fact that it affects somewhat-recent versions of Ubuntu and Windows is enough for me.
Isn't glibc 2.27 the version released after the spectre/meltdown/whatever fixes that slow (primarily Intel but to a lesser extent AMD as well) systems down?
No sorry glibc 2.27 is just what I tested. I've now narrowed it down (conveniently) to glibc 2.23 and 2.24. Ubuntu 16.04 ships with 2.23 and 16.10 ships with 2.24. On 2.24 I'm seeing a faster compilation Perusing the it looks like may be why we're not seeing the regression in newer Linux
Ok I've found the source of the regression, will post a PR soon.
It's a pleasure watching you folks work!
E.g. if a test doesn't have a fn it can prevent the test from ICEing because ICEing codepath might not yet be reached before compilation is aborted. In this case, the stderr should be printed to help the person figure out that "I forgor to annotate crate type" is the cause.
you can set env var which should print stdout, stderr and exit code
Oh right, good point, I forgor this existed. We should (I'll do this later unless you want to work on it): Mention this env var in the panic message for when the crashes test no longer crash. () Mention this env var in rustc-dev-guide. () EDIT: ended up duplicating some description of ` in because I would not have thought to look there for docs specifically.
Creating a recursive type with infinite size by removing a leads to an internal compiler error. Might be the same issue as . To reproduce this bug, run on this code: Replace by and run again: I expected to see this happen: Instead, this happened: :
triage: P-high. Removing nomination.
assigning to with expectation that they will delegate.
nominating to try to find someone to investigate this.
well spotted ;) Because this issue has the tag and the other doesn't I will post the incremental test here:
triage: Reassigning to self and in hopes that one of us will find time to investigate, since it seems to be an issue with the dep-graph/incr-comp infrastructure.
triage: Downgrading to P-medium. I still want to resolve this, but it simply does not warrant revisiting every week during T-compiler triage.
I encountered the same bug. I starting to create a new issue, but it's exactly the same than this one. In case it's needed, I uploaded the code on on the branch (there is two commits, the first is fine, the second generate the ICE) in case you want to validate your patch when you will eventually have time to fix it.
I am running into this issue as well. Since the corresponding pr has been merged 24 days ago and the latest version was tagged 14 days ago, I am not sure, if this error should have been fixed with . (I did not find the commit on the master but I am also unsure if it was squashed with other commits.) Therefore, I thought I would at least post my error as well, just in case this is supposed to work. In my case I have an enum which holds a struct which in turn references that enum. I know that this can't work and I know how the correct way of handling this scenario is, I just wanted to let you know that this crashes the compiler. If you need a more detailed code sample, let me know and I will try to reproduce the error outside of my project.
run Output: Miri: The underlying issue was found when reviewing the implementation of . The code is a reproduction to trigger the unsoundness. The implementation in question features: Where is turned into and dropped. Yes, that’s , not . The code for seems to be doing the same thing. For comparison: The code for (and the same thing for ) seems to properly use a … no actually, that’s a with zero lengths… notably the allocator is correct though. So the buggy code for should just switch to create a presumably. label I-unsound requires-nightly T-libs
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --- ~Related release note: ~Related PR: ~ ~Though the PR describes the change is related to improve its truncation better, the changed behavior is rounding up which was down before.~ EDIT: The upper changes and issue . It is not related to this issue. I want to check if this is expected change or regression. I tried this code: I expected to see this happen: explanation Until 1.62.1, Instead, this happened: explanation In 1.63.0, <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Until 1.62.1 <!-- Provide the version you are using that has the regression. --:
-- that PR you linked landed in 1.60, not 1.63?
Oh, I am sorry. I probably didn't check how much I scrolled down from release note. Then which change would be related?
Hey! Ran into what appears to be a bug - crate's exported macros each appear twice in the left sidebar: ! Toolchain versions (per log): rustc 1.60.0-nightly ( 2022-02-09), docsrs 0.6.0 ( 2022-02-01) Please let me know if I can provide additional info.
Thank you for the report! This is definitely not an issue with itself, but with rustdoc. is this known? Should a rustdoc issue be created?
Not known afaik. Please do file an issue (or transfer this one)!
Seems similar to
Thanks for transferring the issue. One difference between this and - both macros are exported using a wildcard in crate root (not rename):
Well, just another reexport issue. It's common around here. :laughing: I'll try to take a look in the next days.
This is what I have on currently nightly: ! So I guess it's fixed?
Trying locally with the latest nightly (, more current than that of issue open) I get the same initial landing page for but if I click on one of the macros listed (e.g. "drill down") duplicates still appear on the sidebar: ! So the tiny bug is still there, just deeper/hidden on the latest nightly?
Ah indeed! I can also reproduce it now. Will take another look tomorrow then.
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
It looks like miri just has one instance of , which should be replaced with . Should be easy enough.
This can be closed when the miri submodule is bumped.