jiebi/CodeConvo huggingface dataset:
I've been playing around with today, and it comes in super handy in blocks. However, it seems to run into issues when combined with the feature. I tried this code: I expected to see this happen: the code should compile just fine. Instead, this happened: This is a continuation of the discussion . As , this code (following the from the label-break-value RFC) compiles: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
So the error is generated here if I had to guess, I would assume that this function ought to be modified to check whether the and, if so, not to emit the error. (See  rust docs for a bit more info.)
Tagged as E-mentor since there are some instructions above.
claim
<!-- 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 attach a tarball with a small reproducer (few dependencies from , lock file, empty ). Now run this using rustc 1.56.0: I expect the sha256sum to be the same for the libpalette so file but it's often different. This breaks any binary caches, similarly to what did but that ticket turned out to be a problem with the crate. This time it seems problem with itself (or rather LLVM: stay tuned): 1.55.0 produces same binary/crate hash on every build. Note that in there's: Without this, the issue does not present itself. This perhaps makes it look similar to or but I think it's different. As far as I saw, it didn't produce a difference in ordering of symbols in the resulting though I may be mistaken. Please feel free to close as duplicate if you deem it to be the same issue. I have ran with and after careful sifting through few GiB of output, I found the differences seem to start in . I have bisected itself and ran it on our original code which exhibited the problem. I started the bisect at common merge point with 1.55.0 though the problem turned out well into the 1.56.0 release: cc who did the update : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
One thing I found: if I run it with I can't reproduce it anymore. claim
Well, I was wrong. Still reproducible even with . Produced files are identical though.
Consistent with my findings with as well.
Update: this IS a LLVM bug, I'm able to reproduce it with just ll input file using mainline LLVM. Filed to LLVM.
I have a fix: Do we want to apply it to llvm-rust or are we going to wait for LLVM review?
Good job, thank you!
I wonder if rust needs too.
Answering my own question: it does.
Could you also do a PR for
Sure, will do.
Created
Actually I was too slow, there is already
FWIW, while taking the 1.56.0 source and applying the 2 LLVM reproducibility patches fixes the issues we have with Firefox, the latest nightly doesn't: there's a remaining reproducibility issue on i686 linux. I'll test a patched beta next.
The next beta release should be fixed, per . (Should go out near 00:00 UTC -- I guess it will be .)
the beta branch + the patches seems to fix it, but I've found something new: depending how llvm is built, the result can vary. Specifically, llvm built with a sysroot exhibits reproducibility issues that are not present when not building with a sysroot. I'll wait for the official build for 1.57.0-beta.4 for a definite answer whether the issue is fixed. One thing is sure, though, there's an additional regression in nightly.
So, as far as Firefox is concerned, everything is fixed in the latest betas. I did find a source of non-determinism that is not fixed, but a) it seems to also affects clang (as in, I also have found one in clang, and I think it's the same root cause) b) it goes away with PGO, so it doesn't actually affect Firefox.
is there a ticket about this one somewhere? It's great that it doesn't impact Firefox but it may be impacting other rust software
I haven't filed it because the smallest reproducer I have at the moment is "build firefox with these flags and observe how sometimes some functions have an extra mov", and from experience, those don't lead to any action.
I see, thanks. It sounds like binary-reproducability thing and ABI should(?) be the same at least. And this is a regression in new LLVM version (rustc 1.56 and beyond)?
I don't know if this affects rustc, but I narrowed down yet another source of non-determinism in debuginfo, and upstream came up with a patch:
We tried using 1.57.0 and it seems broken still. I'll try to get a repro tomorrow. Should I open a new ticket or will someone reopen this one?
Actually, seems it comes from a derive crate in our dependency tree, similar to what we saw in ; So maybe it's fine.
<!-- 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. --When compiling on an Apple M1 processor: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can also reproduce this when compiling on an Intel Macbook
I've encountered the same error on a different platform (x8664) when compiling . The project doesn't use cargo so repro is nontrivial, but from I can see that the ICE started occurring at which is a rollup of . <details<summary<strongBacktrace</strong</summary<p</p</details
Also seems to be hitting starlark-rust, , as per
Somewhat minimized standalone testcase: Builds on stable, fails on nightly. cc
Thanks for the minimization! Seems like we've hit again, but through a different code path. I'm investigating.
I think might be another duplicate of this, triggered when compiling the crate.
This code, when compiled for , results in an ICE: Putting smaller integers in does not trigger this, even if you use a ton of them. Edit: It also does not occur when taking it only as argument, or when only returning it. Panic message and backtrace: Rust version: cc
Looks like this could be caused by this common skipping of padding arguments: Combined with this call (which internally also skips padding arguments): When the latter gets used, each padding argument is skipped twice. I assume this is fallout.
triage: P-high Beta regression. Has pending fix.
When a type has no impl, it fields appear to be destructed in order of declaration. When a type does have a impl, that order is apparently reversed. This is very surprising. Example: Prints:
cc who first hit this bug.
The LLVM IR for the Drop glue for : The LLVM IR for the Drop glue for : I don't know why it's getting pointers to each field before calling , they're not used until the cleanup, and they're cleaned up in reverse order. It's also, for some reason, grabbing a pointer to the drop flag (), even though it doesn't use it.
Nominating. Seems pretty strange.
I have an approved commit for this already, it's just failing on the pretty-rpass test at the moment.
I'm OK with disabling the test. Going forward the pretty printer should mainly be used for compiler diagnostics and rustfmt should cover the reformatting use cases, IMO.
This used to work fine at some point, but now leads to some strange errors:
somehow Miri searches for its sysroot in instead of its own built sysroot?
When executing Miri: I thought the sysroot was passed to the process with , but I cannot find such an argument... how exactly does it find from this... I don't really understand how that works. But this may help.
I see, it gets the sysroot because is in . Slightly strange, that sysroot is not really one it can use. Why is it linked from there? But either way, the sysroot we want to use for Miri here is an entirely different one that needs to be override manually. How did that work previously?
oh lol, this was almost certainly broken by , in which you even specifically mentioned , looks like you forgot about it :D
oops thanks for fixing!
We've recently begun testing Bevy against the beta toolchain, where it has incorrectly raised an lint against . is not imported in this file, yet rustdoc believes that it is. (See the imports .) As a temporary workaround, I've created to ignore the error. Here is that first failed. In case it expires, here's . Look at . I can reproduce it on using by running the following command: The is optional, but it makes the command finish quicker. I'll continue testing to see if I can create a minimum reproducible example. :
I've created a minimal reproduction in my -repro branch of my fork. Go to the  folder and run . I've managed to squish it down to this:
I've created a reproduction that removes the dependency on Bevy . I've simplified it down to this:
I bisected it, and this bug appears to first be introduced in . I could not reproduce it in .
Ferrocene CI has detected that this test was broken by rust-lang/rust . Specifically, by the change in , shown below: Test output: Reverting that single line diff fixes the test for the QNX7.1 targets, e.g. and can the change be reverted or does QNX7.0 need to use , instead of , here? from looking at libc, it appears that both and are available on QNX7.0 so reverting the change should at least not cause compilation or linking errors. if the case is the latter, then we should use in addition to .
thanks for the report! I will need to re-test it for QNX 7.0, to see if it is a 7.0 requirement (i don't recall why this was required initially, but clearly I ran into some issues with it). I also plan to do a similar automation to ensure 7.0 builds run without problems on our hardware. Is there a list of tests you see failing on 7.1 that are OK to ignore? I see a list - is this the most relevant one? Thx!
we do not ignore any single unit test at the moment and we run library (e.g. libstd) tests as well as (cross) compilation tests using . we don't pass to but instead pass the list of test suites as arguments. we currently run these test suites:
WG-prioritization assigning priority (). label -I-prioritize +P-low
fixed in
Happens on stable 1.34.2, 1.35.0 and current nightly (2019-05-28). . Results in:
Reduced:
Compiles fine on 1.34.0; haven't tested 1.34.1.
both my repro and your reduced one do ICE on (and ) for me, can you verify that again?
Happens all the way back to 1.30.0 (with ) for me, as long as is passed to rustc.
Ah of course! is needed for NLL on older versions... :) I forgot that godbolt doesn't have that by default.
<!-- 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. --This used to work on Rust : is present in the framework (on macOS +10.13; on lower versions, in the framework). The framework uses internally, so the symbol is available through that (I think). Linking like this worked previously, but since Rust it started failing. This is . <!-- 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. --OS: macOS Mojave 10.14.6. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Sorry if the issue is not very well explained, I'm very inexperienced with how linking works
This is affecting  as well from what I can tell.
This appears to have regressed via , cc As a temporary workaround, you can try setting the environment variable to something like .
With Rust sets to 10.7 for the linker, if not set, to match what we are passing to LLVM. Setting it to 10.8 or above get rids of the linker failure. I will look into this more.
Can you elaborate on that? Building it locally with worked fine for me on an M1.
I can confirm that using gets rid of the linker failure in . For , is required. You need to build a binary, so that the linker is actually invoked. Try building an example (e.g. ).
I can clarify this a little more: If you were building a Rust program for an Apple platform that linked to APIs with availability somewhere between 10.7+ and 12.0+, and you weren't setting your own deployment target, has revealed a bug in your build process. Your binaries were only ever going to run on recent OS releases, but you would have been unaware without testing.
For coreaudio, if it really requires APIs from 11.0+, that seems a bit recent/limiting for a library that's existed since forever on macOS. If the authors were unaware of this, has revealed that they need to do more work to attain backwards compatibility. There will be more breakage like it, but it is the good kind, because anyone using newer Apple APIs should be aware of their minimum platform requirement, just as Xcode forces you to be.
Hmm, this change had more impact than I thought. to determine which minimum Macos version to pass as part of the target triple to LLVM and to ld via by looking at the various command line options and environment variables that have accumulated over the years. If nothing is specified, it apparently defaults to the minimum of the specified in the SDKROOTs and the host Macos version . I think ideally we should probably try to mimic this behavior somewhat so we don't confront users with having to set , while they don't have to do it using clang. Not sure how we can easily accomplish this though.
Actually, that makes a lot of sense, thanks! I fully agree that it's better to catch these issues when developing (instead of later, when users complain that the application doesn't work on their older system)! I've opened to fix the linking in , and would fix the linking in .
Note that this is a breaking change for macOS users, before, they didn't have to specify , now they do. Furthermore, they have no easy way to find out that they need to (they just get a confusing linker error)! Additionally, the affected crates (that we know about) are quite widely used (at least half of all Rust games depend on and/or ), and have not yet fixed the issue, nor yet released updated versions which includes these fixes. And even when this has been done, it will take time before users have run and received working versions (can probably be helped along by yanking the affected versions). I don't really know the procedure for this, but I would like to propose reverting (at least from the current beta) to give the affected crates more time to update. Again, I really do agree with the change, I just also want to minimize the breakage macOS users will experience from upgrading Rust.
Like I wrote I think ideally we should match clang's behavior and thus fall back to the default of the currently configured Macos SDK. That would mean looking at the property of the in the currently configured SDK. Unfortunately I don't really see a reliable way to do get the path to that without running .
I think we should revert the change until you find a way to do this - it seems to be causing a lot of breakage and my understanding is the goal was just to turn a runtime error into a link time error.
Oh sure. I am not against a revert until that is sorted out. I will open a PR. claim
reopening as this is a beta-regression, and we keep those open until beta fix lands (or we explicitly decline to fix).
Backport merged.
Just for reference, the linking in the noted crates have since been fixed: , ,
I root-caused this a little bit more today, sharing my findings: The problem can be reproduced with and the following file: Weirdly enough, if you remove the linking to , everything links fine. I think this is actually a bug in , it seems like: The linker is reading the symbol tables from and to try to figure out where comes from. When reading , it sees that it has a few "", which includes , which is where the symbol actually comes from (well, nowadays from , but that is re-exported from ). But when reading , it finds the symbol , which is intended to indicate that "when linking on older platforms, use instead" But instead, it ends up making it seem like is actually the real , and does not expose , so the linking fails. Again, I believe this to be a linker bug because the problem does not happen with (try passing ).
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: ().haserrors().issome()'', 'thread 'rustc' panicked at 'assertion failed: ().haserrors().issome()'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
cc
in 'ish ICEs, I am seeing ice now, im wondering if that also relates to somehow :thinking:
Quite likely, I'll take a look.
I can reproduce this. It's Saturday morning here, I might get to it today, if not I'll look on Monday morning.
Fixing this is really easy, I just need to adjust the assertion a tiny bit. The hard part is deciding where to put the test. is the obvious place, but then I get complaining that there are too many files in that directory. Suggestions?
just bump the limit by one like everybody else? :upsidedownface: :seenoevil:
I ended up putting the test in , because it happens during type checking.
One of the easiest ways to make CI faster is to make things parallel and simply use the hardware we have available to us. Unfortunately though we don't have a lot of data about how parallel our build is. Are there steps we think are parallel but actually aren't? Are we pegged to one core for long durations when there's other work we could be doing? The general idea here is that we'd spin up a daemon at the very start of the build which would sample CPU utilization every so often. This daemon would then update a file that's either displayed or uploaded at the end of the build. Hopefully we could then use these logs to get a better view into how the builders are working during the build, diagnose non-parallel portions of the build, and implement fixes to use all the cpus we've got. cc
On Windows this can be done by taking advantage of job objects. If the entire build is wrapped in a job object then we can call with to get a bunch of useful data.
I made script that will print output into the travis log every 30 seconds , . Some findings: Cloning submodules jemalloc, libcompilerbuildtins and liblibc alone takes 30 seconds. While building bootstrap, compiling serdederive, serdejson and bootstrap crates seems to take 30 seconds (total build time: 47 seconds). stage0: Compiling tidy crate seems to take around 30 seconds. Compiling rustcerrors takes at least 2 minutes, only one codegen-unit is used Compiling syntaxext takes 9 minutes, only one CGU used stage0 codegen artifacts: Compiling rustcllvm takes 1,5 minutes, one CGU During stage1, rustcerrors and syntaxext builds are approximately as slow as during stage0, rustc_plugins 2 minutes, one CGU. stage2: rustdoc took 2 minutes to build, one CGU compiletest suite=run-make mode=run-make: It looks like there is a single test that takes around 3 minutes to complete and has no parallelization. Testing alloc stage1: building liballoc takes around a minute Testing syntax stage1: building syntax takes 1.5 minutes, one CGU Notes: When the load average dropped towards 1, I assumed only one codegen unit was active.
The script was only applied to the default pullrequest travis-ci configuration.
As shown in , the CPUs assigned to each job may have some performance difference: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz The clock-rate 2.4 GHz vs 2.5 GHz shouldn't make any noticeable difference though (this would at most slow down by 7.2 minutes out of 3 hours if everything is CPU-bound). It is not enough to explain the timeout in .
I was working on recently for this where it periodically prints out the CPU usage as a percentage for the whole system (aka 1 core on a 4 core machine is 25%). I only got Linux/OSX working though and was unable to figure out a good way to do it on Windows. My thinking for how we'd do this is probably download a binary near the beginning of the build (or set up some script). We'd then run just before we run . That way we could correlate the two timestamps of each log (the main log and the to similar moments in time. Initially I was also thinking we'd just at the end of the build and scrape it later if need be.
Part of Here's what needs to be done to close out this issue: is fine, but should point out why and the primitive type are different. should use the same boilerplate as  has the same issue. has the same issue. has the same issue. should link to the method it comes from. should use the same boilerplate as . should link to those functions. should have an example of implementing it. should link the types it mentions. should link that .
As shown in , there's a lot of junk there that could be in instead.
I am happy to mentor anyone who wants to tackle this issue.
Hello! I'd like to give this issue a try.
that'd be great! this issue is very general, so any improvements would be welcome. Let me know if you need any help!
Shouldn't this remain open? 3 points have been hit on, but the rest of the bullets need to be addressed
Yes, whoops! That was an auto-close from a PR message; gotta be careful with that!
Can you explain what you mean by "the same boilerplate" in points 2-5? Boilerplate as in the description text or the struct line, or something else? Getting some clarification could get those knocked out in short order
Yes, absolutely! is the main set of iterators, for . When I did these docs, I took care to make them all consistent: etc. and etc don't use this; when I wrote it, I was thinking that would be the right way to go; but looks like is slightly different than the ones. So we should change all of these to look like the ones in . Make sense?
Ahhh, so for , it should be something along the lines of: An iterator over the lines of a string, as string slices. With the proper links to and as well, yes? I could run through each of those structs, format them like that, with a commit for each and then do one big pull request for the lot of them if that would be convenient
Exactly. Sure thing! That'd be great.
I think the last two PRs should take care of the remaining bits of the task list. When they're merged, I think we'll be good to close this issue out!
Module documentation () Bytes should use the same boilerplate as Lines () CharIndices has the same issue. () Chars has the same issue. () EncodeUtf16 has the same issue. () ParseBoolError should link to the method it comes from. () SplitWhitespace should use the same boilerplate as Lines. () Utf8Error should link to those functions. () FromStr should have an example of implementing it. () fromutf8 should link the types it mentions. () fromutf8_unchecked should link that &str. ()
Everything's merged! Good to close
Yes! Thank you for all the help!