When there was a change in a or other non-rust file, bootstrap tries to format it, which makes rustfmt very sad. cc and who broke this in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think we just need to filter .rs files before passing them to rustfmt.
This will probably be hit a lot by contributors so I'll pin it for better visibility.
claim
Normally, the walker already filters for files, per Maybe the crate docs are not fully up to date, or I didn't understand them correctly.
The workaround is to run (notice the dot at the end of the command).
I think if we add it like this: will always not ignore it anymore.
Maybe try to put the part I before the ignore part, maybe this makes the ignore list work again? The thing that intrigues me the most is the fact that the files are not ignored later by the file type filter.
For any Rust files we changed locally, our current solution will try to format it, in some scenarios we may not want to format it, such as some files in UI?
Seems right, my current fix is not completed.
I think since you explicitly add the files to , that overrides the types filter.
from my local experiment, seems is still expected, I changed some files which ignored in , they are actually not sent to formatter:
WG-prioritization assigning priority (). label -I-prioritize +P-high


The following code works in 1.56.0 but crashes 1.57.0 as well as the most recent nightly — . <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
According to cargo-bisect-rustc the regression is from — FYI regressed nightly: nightly-2021-09-06 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Seems that this is duplicate of and ; only triggers with incremental compilation enabled. Unfortunately although I authored the original PR, I don't know a lot about incr-comp or the query system to diagnostic the issue. label: +A-incr-comp
Found the bug, I'll put up a PR in a sec. claim
reopening as this is a stable-to-stable regression, and (I think) we keep those open until a fix lands on stable or we explicitly decline to fix.
was this backported / can we close the issue? :)
The fix was backported and released in 1.58.0
Perfect, thanks for checking !


The Unicode Windows API internally works with (potentially ill-formed) UTF-16 paths that must be converted to from Rust's UTF-8 strings. The conversion happens here: does the translation from WTF-8 to UTF-16, leaving a with . The following calling to will then allocate to reserve additional memory for the null-terminating character. This could be resolved in two ways: 1) Call beforehand and then call on EncodeWide. 2) Make a wrapper around that increases by one. Incorporating the final null byte into would add a performance penalty, therefore it would probably be desirable to just adjust the sizehint by one and adding the null-terminator manually. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
In the interest of enumerating possibilities, there's also using (hopefully this will optimize): Or we could test the for nulls before converting.
That's a good idea! Chain actually gives an example for windows paths: Although I'm not sure what's more efficient here, std::iter::once or [0]? Allocations are quite expensive so I believe the additional check (if it's not optimized away) would be worth it. However I also discovered a deeper issue. The sizehint that originates from the WTF-8 iterator is in UTF-32 code points. The lower bound will be (assuming that all code points are U+ or higher), the upper bound is (everything is "ASCII"). When collecting into a vector, the lower bound is chosen as an initial capacity. Since you almost never encounter paths that consists of U+ characters only, the estimated lower bound will always be too low and 4 allocations are required if the path is ASCII only, 2 allocations are required if the path is UTF-16 only, and 1 allocation is required if the path is UTF-32 only. It might be worth a consideration whether to call , as that would be a sane default (on the assumption that the majority of paths are UTF-8). However, this might waste some memory, do we have any idea on whether paths created from this function are primarily used ephemerally?
I believe all uses of are currently ephemeral.


We tend to use it only for as long as necessary to call a Windows API. There are a few places we keep wide strings around longer but those don't use as far as I can tell.
In light of that, I believe that the first solution would be the best. Solution number two would make naming very awkward (EncodeWideWithNul?). And while your solution is very elegant and correct, it would still mostly under-allocate given the interaction between size_hint's lower bound and collect. However, I find both solution 1 and solution 3 acceptable. It would be good to know how much reallocation actually costs and if it even matters at all in the context of interacting with expensive IO.
I do agree implementing solution 1 would be a good idea. Having some good performance numbers would be great but I do suspect reducing allocations would be a win here. I would also like us to use stack buffers more, similar to . and only use new allocations when necessary. But that's perhaps another issue.
Reducing via stack buffers is a good idea, but I think it's out of scope for this issue. For now let's just reduce regular allocations, that should already give us some improvement! I'll try to see if I can implement this one. claim
Fixed by


Rustc's parser does not include a loop's label in its span. So the span associated to the expression will contain only cc


eg It's still an accurate characterization, but there's no other kind to contrast with.
We probably don't need it to say "Use with the module" either.


Testcase: : : Output: Should output, instead, the parse errors from . Probably misplacing the diagnostic emitter somehow, when creating the nested parser for the included source, and doesn't have an .
(I suspect this is an easy fix, but am not quite sure)


When I tested 1.40.0-beta.5 on , never completed on . When I run that test on arm directly, I get: The same happens when I use official builds of Rust 1.40-beta and 1.41-nightly, so it's not just a problem with Fedora's build of rustc or LLVM. This test didn't exist before , but running 1.39 on the current test just fails even earlier, as expected, "entered unreachable code: catch_unwind should not have caught foreign exception." I tried compiling the C++ part with GCC 9.2.1 and Clang 9.0.0, both with the same result. That's using libstdc++ either way though, because we don't have LLVM's libc++ available. cc
cc
PS: while I initially saw this on Fedora rawhide, my followup testing has been on stable Fedora 31.
That is very strange. And this behavior only occurs on ARM? I'm tempted to say that this is a bug in GCC's unwinder (in libgcc). Can you try this C++-only code to see if it has the same issue? a.cpp b.cpp This should print the message once and then fail with an uncaught exception.
Yes, the other arches completed and passed that test. Needs for , but then it works:
I tried stable 1.39 again commenting out the call to , then gets stuck in the same "caught foreign exception in catch" loop on the C++ side. In fact, this happens on every compiler I tried back to 1.13, which is the earliest I could get working at all! So at least it's not a new problem. Maybe we're generating bad unwind data, or maybe my libgcc has a bug in handling foreign exceptions, I don't know...
I think this might be a bug in the way the personality routine in libstdc++ (libsupc++ actually) handles foreign exceptions on ARM. Can you try using libc++ instead of libstdc++? Just change the linker args for rustc from to .
Oh, I found that Fedora does have libc++ packaged, and . But when I tried to use it simply as you indicate, foreign exceptions don't seem to be caught at all, in either direction.


I see the binary still gets linked implicitly though, I think because adds it to std. I'll try to get a full build of rustc with just libc++ instead.
It's fine to link to , since that contains the libunwind implementation. The actual C++ personality functions are in libstd++/libc++abi. Can you post the test output with libc++?
Maybe this is obvious, but I have to compile the C++ part with clang++, not g++, or it gets "undefined reference to ". I wasn't sure whether to also use , but either way the C++ exception is not caught by Rust: So I commented out again to just try :
you may need to explicitly link libcxxabi depending on how libcxx was built. That should fix undefined reference error.
I did use -- do you mean more than that? If anyone else is interested in arm-linux, it would be great to get more hands on this, because that target is not a high priority for me. I will probably disable this test for arm in Fedora in the meantime.
I managed to reproduce this on Arch Linux with , so it's definitely not a Fedora-only issue.
no, that should be fine. Guess passing to the Clang (supported since 9.0.0) doesn't help either?
The link error was only when using g++ to compile That much was ok with clang++. I just tried adding to the clang command too, but got "argument unused during compilation".
I'm hitting this on Debian too. Running by itself does result in infinite-loop printing however the rust test suite is actually running . Directly running this however exits immediately, so I don't know why the test is hanging. I'll see if I can grab the environment from next time.
Ah nvmd, I just had to wrap the thing in single-quotes to reproduce the loop, the output of "pstree" is misleading.
Since this test is new in 1.40 I'll just for the time being in Debian.
Should be fixed by


<!-- 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 tried this code: I expected to see this happen: ! Instead, this happened: ! This is issue from First screenshot is of and second is of
Probably , it shouldn't have affected glob re-exports but maybe did (cc
Taking a look.
Same issue with a simple reexport:
That's what was meant to do, it wasn't meant to affect globs though.
I think there is another issue with how it's handled because nothing is listed on the item itself too: !
Ok so it's the expected output for a non-glob reexport. I wrote the fix for glob reexports, just need to add tests.
Latest nightly fixed the issue for but it didn't fix the issue for . In latest nightly below example doesn't work its last working version was also .
Noted. Sending a fix for it as well. :)
Fixed in


This appears to now be fixed.
Neat! Just needs a test if there isn't one already.
There's , but I'm not sure if that qualifies as testing this in particular. If not, I can add one.
Marking as E-needstest. I don't think the test I linked previously really fits this case.


When I do , it says: Strangely, when I do , it uses the correct name: No idea how it is even possible for this tool to have two different names inside bootstrap...
I think this is just because cargo-miri's tool check step is generated through a macro this macro generates the check message via there's a in there too. The build step has a different name because that macro explicitly asks for a display name
If I make the macro use a display name,
Ah, I didn't realize those two steps were defined entirely independently.
Anyway, should make this more consistent.


should always return . But it doesn't if you enable the lvi-cfi feature. The miscompilation only happens with opt-level=0. Compare: Here's a slightly reduced LLVM IR: Difference in output when adjusting the lvi-cfi feature attribute on : . I can't really see any obvious culprits. I want to file an LLVM bug as well but I don't have an account. cc
I think the Rust calling convention may be using whereas LVI-CFI assumes it's unused?
Actually you can see the issue in the assembly diff I posted, lines 45-51.
I've filed an LLVM bug now based on this reduced example:


Do you have a testcase that reproduces this problem? Also, what version of rustc are you using?
I'm sorry late for your comment. $ rustc this is bad my code. : : rustc 0.6 ( 2013-01-20 20:35:24 -0800)
From my cursory glance, multibyte characters (Hangul in this case) seem to cause this bug.
Not critical for 0.6; removing milestone
Seems to be fixed. Checking in a test case.
Done pending
Test case in , closing


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.


There are bad (404) links in search results with nightly rustdoc. E.g. go to and then click the result. This leads to which does not exist. Cc
Actually, this issue seems to exist even on stable -- somehow it went unnoticed for quite a while, it seems.
I think it's because we are badly handling a reexport/type alias.
I think this is a duplicate of


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 .


This code () Produces ICE on any channel
This is the same issue as , attributes on expressions are not converted into HIR properly.
I checked on latest nightly - isn't produced anymore while this one still throws ICE.
could you reopen this issue?
triage: P-high. Removing nomination.
Reduced somewhat:


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


Found as a byproduct of work on backtrace: Compiles on stable 1.35.0.
triage: Looks like matthewjasper is on top of this. Marking P-high just so I don't have to think about it further right now. Removing nomination tag.


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 ).


<!-- ICE: 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.


Warning:
By the way, the warning goes away if you explicitly specify the trait who's static method you are calling, like so:


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!


Repro steps: create a new cargo binary with . Replace with the following code. Then run . Hope this is helpful! I've tried to minimize the code as much as possible. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The same issue happens in the latest nightly as well.
This bisects to nightly-2021-06-25. Commit range: It only reproduces with , not , which means bisecting to the old nightly needs in In that range, looks the most relevant because it is the only thing introducing edition-specific behavior, and it's dealing with closure capture and the presence of a closure appears necessary in the minimal repro. would you be interested in taking a look?
For comparison, the same code with doesn't emit a compiler error and has a bit more info:
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
In both and , function returns value every time but somehow in value unwraps into error, even though it's This is the returned value:
Triage: This is no longer ICE with the latest nightly, since (presumably ). Marked as .


Currently there are no landing pads generated for resource destructors so they are leaky when they fail. We don't have the same tricky situation that C++ has with throwing destructors but I haven't thought through how it should work yet. Edit: This issue has changed into what to do after a dtor fails during unwinding. The previous issue of dtor failure not working at all has been resolved.
There's a failing test in run-fail/unwind-resource-
And another in run-fail/unwind-resource-
The language reference is actually quite explicit about this: "A task may transition to the failing state at any time, due to an un-trapped signal or the evaluation of a fail expression. Once failing, a task unwinds its stack and transitions to the dead state. Unwinding the stack of a task is done by the task itself, on its own control stack. If a value with a destructor is freed during unwinding, the code for the destructor is run, also on the task's control stack. Running the destructor code causes a temporary transition to a running state, and allows the destructor code to cause any subsequent state transitions. The original task of unwinding and failing thereby may suspend temporarily, and may involve (recursive) unwinding of the stack of a failed destructor. Nonetheless, the outermost unwinding activity will continue until the stack is unwound and the task transitions to the dead state. There is no way to “recover” from task failure. Once a task has temporarily suspended its unwinding in the failing state, failure occurring from within this destructor results in hard failure. The unwinding procedure of hard failure frees resources but does not execute destructors. The original (soft) failure is still resumed at the point where it was temporarily suspended. "
Yeah. The hard/soft thing has never been implemented, as far as I know, but I think it's the best we can do: retain correctness of our memory model and try to retain correctness of user code, but not at the cost of infinite-recursion. If their dtor itself fails, just unwind that sub-failure w/o the opportunity for sub-sub-failures.
It would be good to revise the title of this bug to reflect what the task is.


(From the comments thus far, it sounds like the task is to implement the hard/sort failure unwindin protocol; but it might also be useful to clean up the docs here.)
Not critical for 0.6; de-milestoning
confirmed again; current code that can crash is as follows: If my idea for an effect system goes through, we might make this sound again by simply requiring no failure in destructors, e.g. .
nominating for well-defined milestone
there is language about this in the manual already in the task section, so I think it's well defined already. just not implemented. feature completeness issue.
accepted for feature-complete milestone
Triage: the updated version of example still crashes:
0 backcompat
This not only applies to destructors failing while failing, but this appears to also apply to linked failure as well. A program may only contain one statement, but it may still leak due to linked failure. An example of this would be: The destructor for never runs in this program because the call to invokes scheduler business which will realize that it needs to fail due to linked failure. It seems odd to me that if a task only contains one source of failure then we can still leak. This specific use case may not entirely fall under this issue, but it seems fairly serious.
The scheduler does have logic for not failing from linked failure when a task is already failing. So if, for example, the sleeping destructor here were to happen during unwinding, I think it should be fine. But if it happens normally you could still get failure.
I've updated the title to reflect what we're currently talking about. My understanding is that it is just impossible to throw from a landing pad because it will potentially corrupt the unwinder and our three options are: abort - this is what C++ does resume unwinding without completing the landing pad - this is what Ada does and we haven't discussed this option abort the task without completing unwinding - this is "hard" failure we've talked about The "hard" failure is made more difficult by tasks that are not simply green threads. For example, we have use cases where we want to run in a 'task context', on the current thread, and then be told whether the task succeeded or failed, all on the same thread. There's no way in that scenario to just terminate the task cleanly.


My current opinion is that, for 1.0 we should take the most conservative approach and abort. For future versions we should consider trying to do what Ada does and skip a single landing pad, but still proceed to catch the exception.
I agree with double-abort for 1.0. Thinking about the other two schemes in terms of how RWARCs (or whatever they're called these days) behave, aborting just a single task strikes me as risky in terms of unexpected behaviour befalling the user. If a double-failure occurs inside an access to a RWARC, it won't be automatically unlocked during unwinding, and other contending tasks will block forever. I think that resuming the unwinding and skipping the one landing pad still makes sense, though. If double-failure occurs in a user-provided destructor (or in the destructor of some buggy library), skipping the rest of the destructor can only "surprise" other code directly associated with the faulty destructor.
I agree too.


This is the correct output. Notice that one of the errors has a column of whitespace between the line number and the pipes, the next does not. Commit range:
Mentioning who made changes in librustc_errors. Could this be from ?
It looks like this can cause the wrong line number to be printed. :( If you bump the problematic line down to line 100, it prints as 10:
It seems like it might be.
Indeed. Upon closer inspection I've found out that actually changes the semantics of method: after applying this commit, if is not empty, then of them is not compared with , although could actually be greater. The correct code should rather look like this: Although it might be not the bug responsible for this issue, it definetely should be fixed. I'll make a PR with fix ASAP. EDIT:
Subtle. That seems about right.


Perhaps there's a minimum amount of debug info we can output by default without breaking things. This is alarming to newcomers.
I am 99% confident this comes straight from dsymutil.
Possibly related to
non-critical for 0.6, de-milestoning
+1 to fix this or provide temporary "fix"
As a new user curious about the language, this definitely made me think I'd done something wrong while building. This issue is also not a top result in Google if you search for the full error message and I haven't seen anywhere else that the issue is detailed. While this is totally understandable in a pre 1.0 release, it would be really nice to have a note that it's expected in the README and/or printed to the console at the end of the build output.
+1 30 seconds into playing with rust, initial impression: 0.6 is still not ready for anything more than casual experimentation. If that's the message you intend to send, well done!
+1 Occurs when building rust, and when compiling .rs files. I was almost certain my build had failed since the last ~6 lines were these warnings (while everything was fine). I also get this warning every time I compile any .rs file.
Nominating, production ready.
accepted for production-ready milestone
Thanks! I know it's a small thing, but I certainly appreciate it :)
I'd be curious what happens if we stop running dsymutil for non-debug builds. In particular, does the gdb experience suffer at all when debugging the resulting binary?
I am writing a rustpkg script for to fix cadencemarseille/rust-pcre and this is tripping me up because part of the script looks at output, which includes this warning in the data. For now I think I'll just use the last line of output, but it would be great to have this issue fixed.
I'm still getting this in Homebrew Rust on Mavericks. Trace: System: When Homebrew gets Rust 0.9 for Mavericks, will this be fixed?
I get this all the time still.
That's probably because we build servo with debug symbols, hence we run dsymutil. I would expect will have a better experience.
The job failed! Check out the build log: <details<summary<iClick to see the possible cause of the failure (guessed by this bot)</i</summary</details


This page isn’t working is currently unable to handle this request. HTTP ERROR 503
The bot got moved at some point; try Are there some docs that need to be updated?
Or how about made 302 redirect to the new target url?
Are there some docs that need to be updated? There are few references to the old address in the rust repo, including (all can be found by searching "buildbot").
Fixed the broken link in so I'm going to remove the issue tag here. It would be nice if there was a or something that was a GitHub Pages site that had an for and whatever else relevant resources for maintaining the queue. It'd be easy to change if the homu link changes again in the future.
I on IRC how to do this awhile ago, and I believe they're still basically applicable today. If anyone would like to help implement this and still has questions please just let me know!


The full repo is here: : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
For what it's worth, I can reproduce this issue with version 1.63.0, but it doesn't happen with 1.64.0 nor with the latest stable version 1.66.0.
The ICE disappeared in nightly-2022-07-01, which contains the following merges: [x] : ICEs [x] : ICEs [x] : ICEs [x] : ICEs [ ] [x] : ICEs
Here is it minified, and standalone-ed:
Triage: This has been fixed on the latest nightly, as reported, and needs a test to close.
claim


This test program should exit quietly, but with , it instead fails the assertion: I also tested a really old 32-bit compiler, and it also failed: This test case is reduced from .
Probably a dup of (and )
Perhaps it's a dup. The other two issues are broken with and without optimizations, though. This issue only fails with optimizations.
Also: the expression in this issue doesn't actually require any overlap of the match patterns. (I'll update the test case.)
The bug also happens without a expression:
Good point. Also, this only happens with opt-level=2 (not 0 or 3).
cc Further refinement of the test case: Changing from to a large enough value avoids the bug. Apparently, the value needs to be large enough that, when rounded to the next highest power-of-two-minus-one, it is at least as large as . I think this is an LLVM bug. It involves the metadata. It's as if the compiler is reusing the range information from the check to elide the check (which is missing from the x64 assembly). Relevant unoptimized LLVM IR: isn't used in the test program. When I change its value, the only difference I notice in the unoptimized LLVM IR is in the range metadata (i.e. ).
Thanks Ryan! Indeed LLVM replaces the load with another disregarding the range information.
Patch is at
Patch landed upstream.
Using yesterday's nightly, fails on at this single test. The problem seems to be local llvm 3.6 is still allowed by the build system.


According to my CI this started 2020-04-16 (https://travis-) - : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
reports a regression in (PR ), cc
Assigning as and removing .
assign
Oh dear, I was hoping crater will find all such issues (this is ). I guess nobody in the wild is pattern-matching tuples with non-literal-length arrays. I can repro by adding this line () to the test (and the PR fixing this should IMO add the line to ): The fix is likely trivial: add another normalization, like in Presumably, for field accesses, this time (weird that doesn't trigger the bug). <hr/I've brought it up before w/ (but I don't know if I've seen a response), that the lack of normalization for array lengths in typeck is pushing complexity to the rest of the compiler and maybe we should do it in typeck. But then again, Lazy Normalization Is Coming, so maybe there's no point.
I believe I responded in the PR where you already asked me about that. I'm fine reintroducing a normalization phase


I am learning rust and reading the book for the first time The section mentions a "Next Project" at the very end We can add a link to that project ?
It's referring to the next project showed in the book (so next section if I remember well). If confirms, this issue can be closed.
Actually, this sentence is vestigial from when we had the Dining Philosophers chapter. I would actually prefer to remove this sentence. Want to submit another PR? :D
absolutely :-) on it
was interested in looking at the old . pasted here for future people was removed in
sent PR


There is no such thing as boxsyntax anymore :D <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
does the same.
It probably makes sense to search across the repository (including submodules) any references to this removed feature and remove them
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 tried this code: This currently fails, even though no symlinks are involved. This is because on Unix are currently compared on the totality of their contained unix , which are bitflags of the form (in octal) where is a Unix permission mode and the actual file type. As of now, depending on how the is built, may be either (from ) or set to the actual file permission mode (if built from ). (This bug was co-investigated with <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
label: +T-libs-api + Libs-Small
Error: Parsing relabel command in failed: ...'libs-api +' ' Libs-Smal'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
label: +T-libs-api +Libs-Small
Error: Label Libs-Small can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
label: +T-libs-api


() Errors: Backtrace: modify labels: +I-hang +T-compiler +C-bug +A-lifetimes
somewhat minimized: To replicate this I needed: async two other arguments by ref at least one arg must not be bound to , compiles quickly the problematic argument must be contain an indirection: compiles fine. and also freeze. and a trait object containing at least one non marker trait explicitly bound to . and are both ok
repro is a regression in 1.43. It compiles immediately with 1.39 through 1.42.
I am currently bisecting this using
regression in modify labels: -E-needs-bisection
FYI who had context on .


rustc 1.12.0-nightly ( 2016-07-10) Changing the order of bounds in the associated type declaration changes which causes a spurious "mismatched types" error. Using UFCS works around the issue: The same issue exists with bounds like to compare with itself as well as another type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cf.
Looks like this is caused by on the set of bounds from the trait, but that is just find the first one (in the order they are internally stored), this needs to filter and produce a vector of bounds or something similar. cc
Update: using filter and then calling on all matching bounds does not fix this issue.
I believe your problem is . Right now it works fine because the above would trigger for vs or vs . However, it's incorrect with your changes as is dropped in favor of even if and are not equal. The correct form would be more like this:
I guess that you didn't just call , but are also packaging up the specific bound that was matched? Anyway, not having seen the full diff, the general direction of these changes make sense to me.
Related:
triage: P-medium
Triage: :
This is fixed on current master. Should be closed.
I would like to work on this issue if its still relevant?
As mentioned the original code now compiles: Closing as there doesn’t seem to be anything left to do here.
do we have any regression test? I couldn't see any.
Oh good point. Sorry I missed the label. Yes, feel free to work on adding a regression test!
claim


This is clearly ridiculous, but rustc is perfectly happy with it. Regression from 1.9.
prints . Using the constant in any other way, e.g. errors out:
cc is that fallout from your new const eval?
I haven't removed anything, not that I can think of, to cause this.
Then it's very likely fallout from (skipping double negations)
The remaining error in that testcase feels wrong. should, IMO, be - the literal is in range, but the negation overflows.
Actually I think it should be valid code, but yield , at least that's what the original literal out of range lints do
But overflows when negating, which is an error. Why should it be different than ?
I have no particular opinion on this. But the lint has code handling double negations: (it's treating double negations as if they weren't there at all)
The double negation is not the issue here. The value of evaluates to , as expected. But consider the following code: This will also compile just fine and print . It goes wrong in the cast . Rust doesn't check if cast overflows, so the value becomes .  can be changed to disallow casts that fail. (I'd be happy to implement this myself.) Or we can accept that these casts are can overflow silently.
I believe the issue is that --128 (aka 128) is an intermediate result of the computation that is out of bounds for the i8. EDIT: The issue is about the fact that the compiler doesn't complain.
jup, that was a misunderstanding of some code on my part + the issue that processing HIR works the wrong way around (you start with the outer most expression). Reverting should do the job
I thought that it was intended that would succesfully evaluate to . (That rustc knows that it's overflowing, but is smart to know that double negation will fix it in the end.) Pretend I said nothing.


This file is only and : , but we should add the other float types to this test. The change should wait for since that changes some of these semantics (this PR is almost merged). There are probably a handful of tests that only check and but could use updates with the new types. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Okay will do that
FYI you can comment to assign yourself an issue
claim


Testcase: I was mostly fooling around trying to see if there was any way I could get rustc to believe that it would always know whether Bears<Twas Drop regardless of T; for the test case, I changed it to Clone and got rid of actually setting the constant to true in the default case, as well as some unsafe keywords, to avoid muddying the waters with Drop's semantics. Note that the array trick for turning a constant into a compile time error comes from , so it's not as contrived as it initially appears. Stacktrace:
The test case overflows on ` <details</details
The code doesn't produce ICE anymore (tested on ), instead, the following error is produced: ()
this no longer crashes , marking as needs-test modify labels: E-needs-test


In the 2017-12-14 Nightly I've seen a significant (almost 20%) compilation-time increase when I use on my code. And the successive day (2017-12-15) the compilation got a bit slower still and the run-time of the binary also got about 8% slower. The successive days the situation kept going slightly worse. Extracting parts of my code to show compiler/code performance is not easy, so I've composed this benchmark function (that solves an Euler problem. If this code isn't enough I will write other similar benchmarks): <details<summarySource code</summary</detailsCompiled with: host: x86_64-pc-windows-gnu Runtime: 2017-12-13: 0.30 seconds 2017-12-20: 0.53 seconds Asm from the the 2017-12-13 compiler: Asm from the the 2017-12-20 compiler:
Could someone try to reproduce and bisect this?
cc I think
We shouldn't have such big asm differences between successive nightlies, and I don't see anything suspicious in the middle, so it would be good to try and nail down the commit that made the difference.
I see a regression with this code (note: this is distinct from ). the bad code accesses the stack pointer (%rsp) You have a fast network connection and know how to use . Could you please do so? You should grep for to tell if the code is bad - the bad code includes the following line:
I bisected original example, just testing the speed of the executable created by a stage 1 and came upon (PR ) as the culprit: the runtime on my machine is around 0.3 seconds before that commit and around 0.7 seconds after. latest example also has a clear difference. The code before that commit (just disassembling the ): And after:
That's unfortunate. cc
cc
Thanks We're looking into it
just testing the speed of the executable I am not sure if they share the same cause, first a significant compiler performance decrease using --emit=metadata , then the successive Nightly the decrease of the produced binary performance.
They should not. However, quite a few big commits landed in the Dec 14 nightly.


If you could provide an example that exhibits the slowdown with , that would allow us to fix it (is the Dec 13 nightly faster than the Dec 14 nightly which has the same speed, but worse runtime performance, than the Dec 15 nightly?)
The last nightly (2017-12-21) has fixed all three problems. Despite some attempts I failed finding a small amount of code that shows a significant compilation slowdown from 2017-12-14 to 2017-12-20, perhaps it's a more diffuse problem that emerges from compiling my whole big amount of code. I am sorry. I don't fully understand your question, but I try to answer creating a table with some data for some of the last Nightlies: Rustc version --emit=metadata Opt build Binary size Run-time 1.24.0-nightly 2017-12-11 4.32 49.78 12.93 1.24.0-nightly 2017-12-12 4.31 48.50 12.84 1.24.0-nightly 2017-12-13 5.15 50.69 12.86 1.24.0-nightly 2017-12-15 5.33 52.98 14.04 1.24.0-nightly 2017-12-17 5.44 53.31 14.03 1.24.0-nightly 2017-12-20 5.47 54.49 14.14 1.24.0-nightly 2017-12-21 4.28 48.82 12.96 The --emit=metadata is a check time. The Opt build is the compilation time for a well optimized build. The binary size is stripped and in bytes. The times are all in seconds.
EDIT: told me about , so the range is .... EDIT2: at a quick glance, none of those changes should affect binary size or run time. How many times have you run each of these? How much do they vary?


They should be: rustc 1.24.0-nightly ( 2017-12-20) binary: rustc commit-hash: commit-date: 2017-12-20 host: x8664-pc-windows-gnu release: 1.24.0-nightly LLVM version: 4.0 rustc 1.24.0-nightly ( 2017-12-21) binary: rustc commit-hash: commit-date: 2017-12-21 host: x8664-pc-windows-gnu release: 1.24.0-nightly LLVM version: 4.0 Mixing up things seems quite easy here.
Ah, that's why I asked, so the range is .... Still not seeing anything clearly relevant, but maybe someone else from does?
The --emit=metadata times are computed as the minimum of four tries. Their variance is very small (on the order of +-0.05) so I think they are reliable. The binary run-time is the minimum of 5 runs, their variance is higher perhaps because they do some I/O, despite using a SSD, about +-0.12. The compilation is slow so there I've done only one time, so those values are the less reliable, but differences above 1.5 seconds should be reliable.
For the compilation time issue, maybe there was a bug in NLL that made it active without it being enabled. For the run-time issue, we need to actually investigate this.
As in, investigate the cause of the run-time fluctuations and how it unregressed?
This is my good old friend the torpedo. LLVM optimizes into this: This is basically equivalent to this pseudo-Rust code After the "non-constant-address" write is generated, LLVM is sunk - LLVM has no way of getting rid of the non constant address, and no way of optimizing accesses to the target with that non-constant address.
Upstream LLVM (that's the yet-to-be-released LLVM 6) has this patch, which avoids the SimplifyCfg sink problem by not running sinking before inlining I have confirmed that - e.g. this code is optimized correctly with the new Until then, I think representing small enums using a struct (rather than an array) should work around this problem.


With the 2017-12-22 Nightly all the problems are back: Rustc version --emit=metadata Opt build Binary size Run-time 1.24.0-nightly 2017-12-22 5.36 53.57 13.96
Coud you open a PR that turns small unions into LLVM structs (rather than arrays)? That should fix the problem.
The binaries generated by the last Nightly (1.24.0-nightly 2017-12-25) is further few percents slower (perhaps because of thinLTO?), the compilation times can't be compared now.
Is there more stable measure besides compile time / run time? They can be affected too easily by the environment especially when the run time is expected to take less than 1 second. The generated assembly size seems to be a good measure.
Please re-test next nightly and reopen if not fixed.
The run-time of the binary is now OK. The compilation time with --emit=metadata is still quite large.
Can you open a separate one for compilation times? Seems to be a separate issue.
, I've tried here:


I was looking at the generated asm for to see what happens to the array, and was surprised to see a large function with 5(!) call sites for . The generated code doesn't seem to vary with the number of elements in the array. That got me to compare with the functionally equivalent code: which doesn't yield the same assembly at all. The first difference being that the latter doesn't even store the array (only the strs) while the former does. That got me even further in comparing with equivalent loops, up to the extreme (and stupid): vs. The latter generates the simplest code possible: The former not so much:
Documenting my thinking in the hopes that it will be useful, or at least that someone will correct me via Campbell's Law. We know that the ASM outputs are different, so let's go back a few steps until we can find where in the toolchain we want to add our improvement. I compiled this on 1.19 with , but the important thing to note is that while iterany is quite bloated, it looks like the for loop has already been optimized: So is just as trivial in LLVM bytecode as it is in assembler - whatever optimizations we needed to do have already happened. We need to go back farther. . Notice that the tables have turned! is more concise than , so the code we need to add should change the MIR output. Note that . So the problem here seems to be that we aren't inlining before we generate LLVM bytecode. But that answer doesn't satisfy me either, because neither the nor the has any calls to , and in fact . So... one of these things is happening: 're failing to inline , and we haven't noticed because LLVM's been inlining this code for us. LLVM doesn't have as much knowledge as we do, so it can't do as good a job as we theoretically could. 've been looking at unoptimized MIR this whole time. This hypothesis seems to be borne out by the fact that when I rerun rustc without optimizations, I get exactly the same MIR output. But , and ? It's possible that both of these hypotheses are correct; maybe this is unoptimized MIR, because the MIR optimizations are doing absolutely nothing to this file!


I'm still cloning rustc, but once I do I'll comment out the MIR optimizations and see where that gets us.
Well, I can oblige that in one aspect :) You put far too much hope into MIR optimizations. They do very little right now—inlining, for example, isn't even enabled by default (only with ). Even in the future, when all the MIR optimizations we've ever wanted are implemented, they will only cover a small subset of what LLVM does (there's no point in duplicating all the work that went into LLVM, and that would be impractical anyway). This code looks sufficiently messy that I don't expect MIR optimizations to ever fully optimize it away. For example, that would probably require loop unrolling, which hasn't ever been proposed AFAIK (and if it was, I'd be skeptical of it). In any case, the more interesting question is why LLVM can't optimize the iterator version as well as the alternative. Whatever goes awry in optimizing this, it happens in one of LLVM's many passes.
The LLVM IR you posted is very weird. It has multiple branches on constants, and presumably dead code consequently. There's also several branches on values?!? These should all have been cleaned up. After running it through again, I get this IR (names are all messed up cause I did it on , which insists on applying C++ name demangling): <details</detailsThat's... less code, but still very stupid. Why are the adjacent loads and stores not folded away?! A third pass (just at this point) gets rid of them, constant folds the rest, and winds up with . Looks like a nasty phase ordering issue. But what about this IR confuses LLVM so much?
Neat discovery. Should we move this discussion to LLVM's bug tracker and close this task, then?
Not necessarily, no. In the past people have tweaked the definitions of iterator methods to help the optimizer. rustc might also be able to help by changing the pass pipeline or by generating better/different IR in the first place.
This did optimize out in LLVM 3.9, and was broken by LLVM 4.0.


In more detail, LLVM 3.9 generates the following small code for ( metadata stripped - it doesn't matter, with this function substituted in both 3.9 and 4.0 manage to optimize everything out): While LLVM 4.0 manages to screw up and generate this monstrosity: I think the somehow prevents SROA.
Going closer to the root: LLVM 3.9 optimizes the closure in to this: While LLVM 4.0 for some reason generates this:
caused by
The initial nonequivalence in the filing of the bug report is due to the slice iterator's explicit manual unrolling by 4 in its implementation of any. That might seem bad but as soon as llvm learns to loop optimize a loop with two exits (either the element was found or the iterator reached the end), the explicit unrolling can be removed.
is the PR that fixed this intended to be a permanent solution, or is it just a workaround? IOW, should we open a new bug to track reevaluating this fix when LLVM is resolved?
Hmmm, mentioned this bug, but you're right, this is older so me "fixing it" is probably more coincidental than anything else.
That LLVM bug is now tracked at and appears to have had no motion on it in the past 5 years. Assembly in the initial comparison cases remains identical per No other changes, as far as I can tell.
This was nominally resolved on our end, but was left open in the possibility that the LLVM issue was going to be resolved, so as to remove the "temporary" workaround. However, if we wish to track LLVM-side bugs that are not currently an impact on us, but may allow upgrades later, then I believe we may wish to consider tracking them in another form than an issue on the GH tracker, as they are "not an issue", so to speak. Alternatively, if we want to track them on this tracker, we may wish to track them in a more organized fashion (e.g. a metabug). I am going to close this issue. Do feel free to reopen this if it regresses again, or it becomes otherwise currently actionable, or if there is a particular reason we must have an open issue on our end to track this LLVM issue for potential improvements as opposed to any of the other currently-open LLVM issues we could be potentially waiting on in order to make an improvement.


The LLVM issue has long since been fixed, so it's possible that the workaround may be removed.
I think any workarounds here are long gone, since moved to internal iteration way back in


This ensures that someone looking at the documentation who searches for the word "length" to find the method which returns the length of the method will be able to find the method, and also explains the origin of the name if someone is unaware. I bring this up because one of my coworkers came to me asking for the name of the method, because they were having trouble finding it in the documentation.
The problem with this is that it's generally bad to include this in the summary, as it's just repeating what's already been said. So I didn't do this on purpose. I'm not sure what exact text rustdoc searches though.... i'd be against putting this in the summary, but for putting it in the longer description
We seem to be very inconsistent about what summaries to use for methods: Some say "length" and some say "number of elements". Perhaps changing them all to say something like "Returns the number of elements in / length of the slice." would help here.
It doesn't need to be in the summary(?), it can be in the body of the doc. already finds and and so on, so the focus is simply in Ctrl+F search inside the doc page itself (if I understand correctly?).


This is unfortunate because: gives the impression that documentation fixes should not be submitted here, or are not welcome. prevents you from gathering commonly requested information (link to docs, rust version number, suggested fixes) in an automatic fashion. prevents automatic labelling for documentation-relevant issues. To fix this, . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label A-meta
claim


Run with this in : and inspect . There is an item for the of the blanket impl  and it's default value is . There is an item but the default value is missing. It looks like this: When using instead of the information about the default value is present. It looks like this: This change, which in practice is a regression, is caused by But we can't revert it of course because that will result in ICEs which is even worse. So we need some kind of follow-up fix. labels +A-rustdoc-json +T-rustdoc +C-bug +requires-nightly
It seems like you already suggested a fix. Want to open a PR for it?
Yep I will do that as soon as I get time. Probably today.
It's not in a hurry. Don't hesitate to ask if you need help.


Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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! cc the PR reviewer, and nominating for compiler team prioritization.
This test is failing:
might give a hint what needs to be updated. I haven't gotten a chance to look closely yet.
Yeah, we'll need to emulate that new static thing by Unfortunately I don't entirely understand the static magic that goes on there... there's just a fn ptr stored in a particular section and somehow that is enough?!?
Yes, all platforms have sections that they treat as an array of pointers, filling the entire section, which makes it easy to append more entries, as linkers will happily concatenate sections with the same name. This is how C++ global constructors are implemented everywhere. So I guess there's two levels to this: miri should collect the platform-specific global ctors/dtors (on Linux I think there's also init/fini which work similarly) and execute them before C main (and after, in the case of dtors) when is , the ctors (or just the init flavor?) can also take 1, 2 or 3 arguments, not only 0 arguments (I believe this is also how C main technically works)
Okay. This is basically I hoped we'd never have to do this... For dtors, we already run TLS dtors, but those are entirely separate (we hook the pthread calls where dtors are set, and then run those functions later). There's no way those can be unified to one mechanism, is there? Also, this begs the question in which order stuff is called before/after main.
C++ asks itself the same question and I personally haven't heard of there being an answer. The safe thing to do is to make sure any order is safe (in Rust you have to initialize global state before any runtime initialization, so it's safer than C++ where before the constructor runs, the fields are uninitialized). The implementations just go through the sections in order, so the unknown quantity is what order the linker concatenates all of these sections.


In miri you don't have the linker to think about, but you do need a mechanisms to access all statics from all crates.
Wait, why can't libstd initialize the args from the start lang item as well? Surely there's an inexpensive way to do so?
That's what I did originally, but said not to.
Reverting should fix this.
We could either adjust the 's to no use the new method when is set, or we could implement those initializers. Seems like we'll want them eventually anyway... What would be the best way to do that?
In the short term, excluding from the new mechanism seems like a reasonable solution to unbreak miri. That depends on two factors: what order functions get placed into the sections, and what order they get called. The default linker scripts will collect all sections in sorted order, followed by the section itself, into a single section. Likewise for and . The sort order here uses the linker's , which takes a numeric section suffix as a numeric priority, and sorts sections with non-numeric suffixes asciibetically. (There are also a couple of special cases to make sure that glibc can guarantee its own functions run first/last in a couple of those. And there are some very careful special cases to handle the old , , , and sections, which get translated into corresponding , , , and sections respectively in the final binary to preserve the behavior of those sections, keeping in mind that ctors sections get run in reverse order and the dtors sections get run in forwards order. translates the priority in numbered ctors and dtors sections by subtracting it from .) When loading a program or library, glibc calls the function pointers in in order, then the (single) function (which executes the contents of the section), then the function pointers in in order. At shutdown, glibc calls the function pointers in in reverse order, then the (single) function (which executes the contents of the section). Does that help?
It is a great reference, thanks! So far I have no idea how to wire up all these sections in Miri, but I guess we'll see about that. ;) On a separate note, also broke Miri by removing the getter from . I am not sure yet if there is a replacement that we can use instead.


Leaving that here just so that I hopefully can find it later.
I don't see any way to actually do that.
I would prefer to avoid duplicate initialization of arguments. I'd like to make Rust executables smaller, not larger.
I agree, I would accept this change.
I opened a PR for that:
Done. I set it to close this issue since we already have to track the more elaborate approach.
Well, actually closing the issue will require also bumping the submodule to include
I don't understand, this would only be a few bytes with ? To unbreak miri it's probably fine but I'm increasingly worried about , as it allows divergence to exist in ways which are not controlled within miri itself.
I was talking about a user of these facilities, not miri implementation. To expand a bit (although it's kind of offtopic): Rust forces you to mutate a that started out with a constant value (e.g. ), which means nothing else would observe an uninitialized value, just the initial constant value, if it happened to ran before the runtime initialization (which would e.g. replace the with a ). This makes Rust + safer in general than C++ with global constructors.
Ack.
Aand now we also need to wait for to land. That's the third independent Miri-breaking PR in 24h, impressive. ;)


Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls 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! cc the PR reviewer, and -- nominating for prioritization.
Upstream fix has landed:


<!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsAdding an suffix fixes the issue: The error first appears with the toolchain. It works fine with .
The offset intrinsic does not support doing this, it requires isize or usize. ICEs using intrinsics wrongly are expected and not a bug. Thanks for the report anyways.
Shouldn't a occur for the argument?
There is nothing to be coerced to, since the intrinsics accept any type on the type level.
Is this specific to the intrinsic? I tried a couple of other intrinsics, and the compiler complained about mismatched types: : : Doing the same for results in an ICE, e.g.:
the intrinsic is generic, that's why it passes type checking
It's only generic in the first parameter. And has the exact same signature, but the issue doesn't occur for it.
Hi what is the motivation to keep this check as an ICE instead of a user friendly error since the error arises from misusage of the API?
Giving better errors for intrinsics and other internal-only features increases maintenance burden, so decided to not support it. Invalid usage of intrinsics may lead to ICEs (since intrinsics should not be used - I see for your case here it makes sense to use them in the tests, but I think you can live with ICEs). I guess it's not ideal that the ICE message says to report it - but fixing that is hard.


The Any trait is not in release condition at all, considering that is still uses slow virtual calls that could be replaced with an associated static in the near future but stabilizing with would mean that it could not be removed. Normally, this isn't an issue, but since Any is almost exclusively used through trait objects this blocks possible optimizations to layout that could allow to be represented as instead of containing a full vtable.
It would need to be , where the is the destructor (btw).


From : It's easy, according to implement my own ` implementation for free. In retrospect it makes sense, but it was not obvious to me at all just from reading the docs. It is not mentioned in , or the docs for . And as the link in my post suggests, trying to work my way around the ownership of the APIs led me quite far afield. Admittedly it's not the most common case, but I think it would save others time if the standard library at least mentioned this somewhere. EDIT: fixed forum link which changed its name when I marked it solved.
A section about "you should consider overloading these things" definitely sounds good. should also be on that list. (In the future or in nightly is in that list too, .)
Your forum link is broken.
The docs do say However, I do like 's suggestion, about talking about which methods you may want to override.
Such hints should be non-normative though to allow the implementations, especially specializations, to use different approaches in the future.
Agreed, I was picturing more which methods to consider overloading, not specifically which things use them. (Or, contrapositively, which things there's usually no reason to overload, like , because the default implementation is generally as good as it gets because it's a trivial wrapper.)
So basically this issue is about adding some documentation on which methods you might want to override right? Which methods do you think are best to mention? Or did I misinterpret the discussion?
That's correctly, probably under or near For now my inclination would be to mention and -- once stable it should be instead, but IIRC we don't mention unstable in the broader docs until it stabilizes.
What about adding this line of text at the end of the "Implementing Iterator" section? which call internally. However, it is also possible to write a custom implementation of methods such as and if an iterator is able to compute them more efficiently without calling . Feel free to adjust the text or make something up yourself :) If you agree I will create a PR for this.
I think it would also be nice to add something to the documentation. How about this? Rather than overriding this method directly, instead override the method.
in case it wasn't clear or you are not watching your GitHub notifications, I approve of both your and suggestions. I look forward to the PR!


Sorry for the late reply! I apparently don't get notifications for thumbs ups and the like! I will hopefully be able to create a PR somewhere this midday.


<!-- 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. --I don't have a minimal example yet, but here's . Sample: The ICE happens on the and macros, which are both from the crate. <!-- 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. --This began with commit . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
FYI, I think that link is only accessible to Googlers: !
Sorry, .
Minimized: Caused by
When we run on the AST, we create a definition for the desugared closure body inside an : As a result, the entry for our macro call will have the of the desugared closure. However, this desugared closure does not actually exist in the AST (it is created during lowering), so we will never check for lints with its when we emit buffered early lints.
Nightly has been broken for 3 days, if there's disagreement on how to fix the issue, can we revert while the fix is being worked on?
This will be fixed by PR
I'm still hitting this bug with the latest nightly.


The following function can drop any object arbitrary number of times, using only safe code: Probably bad :) Found while researching
Nominating for P-high
cc
Too bad this doesn't just cancel out the Leakocalypse :stuckouttongue:
(well, any object that implements . But yes, I see the point being made here.)
look, no required. I guess it doesn't work for types that are already unsized.
to be clear, I am looking at this now as well. :)
I guess is related.
I hope it is unrelated. In particular I wrote this on that ticket:
Yeah, it's unrelated. The call happens for , which does need drop.


From: src/test/compile- Error E0124 needs a spanlabel and a spannote replaced with a span_label, updating it from: To:
Error message updated in .


Looking at without prior knowledge of Windows system call semantics, I see an infinite loop if the syscall were to fill up the buffer exactly: when k == n on line 195, the loop will be rerun with no changes, which should result in the exact same outcome if the syscall is idempotent. Even if Windows guarantees in some way that this cannot happen, would it not be clearer to handle this case in an obvious fashion?
Here's one of the docs on how usually works in Win32: Note the difference in lengths between success and failure. So there's two potential cases where : Success: If the buffer size (with NULL) were to be equal to the successfully copied size (without NULL) then the buffer would be too small to hold the full string (NULL included). So this can't happen. Failure: If the buffer size (with NULL) were to be equal to the buffer size needed (with NULL) then the string would have been successfully copied into the buffer. So this can't happen. So Windows does indeed guarantee this can't happen.
OTOH on some versions returns the size written including the NUL terminator, so for that function the infinite loop could happen, right? The doubling logic that checks for the insufficient buffer error code must be there for some other function that I have not yet found, it would be great to have a comment as to where this behavior is needed.
As far as I know Rust only ever uses the Unicode version of functions (they end in ) and never the "ANSI" ones (they end in ). The functions are more consistent across Windows versions. I'm not at all against adding a comment (and returning an error?) in this case but it's not something that should ever happen with the kinds of APIs Rust uses.
Come to think of it pretty much implies using the functions. It uses a buffer, where as the functions use a buffer. Using this function with the functions would be very broken.
Still, it would be more robust to change the into , so treat this presumed impossible case as success (absent other evidence) rather than looping.
My issue with assuming success is that we can't know what a hypothetical Win32 function is doing in this case. For example, it may have truncated the output or it may even be returning an error code, not a size. We can only guess. Best case is we guess right and it works.


Worse case is we guess wrong and it causes a bug that only becomes apparent later on, making the source of the bug hard to track down. Having given more thought to this, I'm leaning towards using . That would clearly document that the case is thought impossible, while also causing a panic if the function is misused. It might also be good to clearly document the expected return for the function being passed in. E.g.: On success returns the size of the copied string excluding the terminating null. On error returns zero unless the last-error code is set to . If the last-error code is returns the buffer size required, including space for a terminating null.
Yes, that sounds like a good improvement! Since this Win32 behavior is not generically documented, it might also be good to note the exact syscalls that this function has been tested with. I should probably mention that I don’t have a Windows system to develop or test this on, I was merely perusing the code out of curiosity — otherwise I’d volunteer a PR.


upstream/master:
Does that build include the fix in
Yes, include. 6:45 "Huon Wilson" notifications
Thanks for confirming. cc
Reproduced on revision . Note that I'm using win 8.1 with non-english locale which probably causes issues. Quick investigation: then convert the code into string. It seems that failed with .
So the issue is broken into two parts: 1. why rustdoc failed and called ? 2. why failed?


When compiling a personal project, I got an error that the compiler panicked and entered unreachable code. I've dumped the output: And I committed my code which caused the bug here: It might be because I had only written half of an anonymous function at at line 92. This is not that urgent as I only saw it with half-written code, but since the compiler suggested I file a bug I did. :
Good call! Reducing it to is enough to trigger the ICE. <details<summarybacktrace </summary
modify labels: I-ICE T-compiler C-bug A-frontend
I've traced the problem down to this call:
triage: P-high, removing nomination label.


[][zip] says: However, it is not always true; it actually returns after when the source iterator is not fused. [Playground] [zip]: [Playground]:


has made it impossible to import some structures in when implementing dataflow analyses in external tools. When implementing for a custom dataflow problem, we can no longer import the or direction. is the source code of such an implementation. is needed to set the type of the trait. Previously, it under the export, but for now it is . The default implementation of the , so I can simply use the default value as a workaround. However, if I need to write a backward analysis, I must rewrite some parts of the framework in our source code because they cannot be imported. There are other tools in the ecosystem that use that API, e.g.: These changes will make problems if they decide to update to the recent toolchain. Could you please take a look at this matter? Are these changes intentional? Could we make some of the exports public again? cc
Feel free to send in a PR to make it public again. Please add a comment on the items saying they're used by external tools.
I will double-check which of the removed imports might be beneficial for external tools and will send a PR if there are no objections.


This is a tracking issue for reverting the change introduced in which disabled the toolstate check for the edition-guide. It is currently blocked on which is causing a test failure in the edition-guide. I will reinstate the check as soon as that issue is fixed. has requested the labels t-release and I-nominated.
Tags are so that we don't forget this, we should keep it nominated until it's fixed.
The check was reinstated in PR
I think you have the wrong issue? There were two things (rls and edition guide). The PR you noted just reverted the RLS change. The edition-guide was separate (and done in a different way). It's still blocked on .
, that's what happen when I read just half of the title :sweat_smile:
triage: P-high. Assigning to self. Will likewise triage . Removing nominated tag.
actually I'll leave nominated tag, since this is for a team other than T-compiler so I don't want to mess with their tags.


(allowing specifying code models was to rustc in ) I want to build a large code model binary. But (correct me if I'm wrong) I believe this requires all code to be generated with a large code model (otherwise we could end up with rip relative addressing in the stdlib, which defeats the point). So I tried the obvious (controlling it with ) and got the following build log: Brief explanation of the three parts: command is run tail end of the stage1 stdlib and rustc itself being built by stage0 tail end of the stage1 stdlib and rustc itself being copied out of the stage0 build directory and into the stage1 directory, then the new stage1 rustc attempting to build the first part of the stage2 stdlib (libcore) segfaulting In fact, this stage1 rustc segfaults when not doing much: Reducing the command line used to build rustc: GDB gives the backtrace as I've dumped a bunch of info in the hope that someone might be able to lend a hand, but I can find little discussion of this feature (code models) so they may not be well-tested? I plan to investigate myself, but wanted a) to see if anyone has any pointers and b) make this a searchable issue. As a datapoint, note that redox uses a .json target specification and with , which obviously works fine. Altering the configure+make command I used to use the kernel model rather than large also worked fine. So it looks like the issue is with memory model large.
Compiling statically (with glibc, as described at ) makes it not segfault, which is interesting. Doing --enable-debug in configure also makes it not segfault. I starting to suspect the issue is in llvm (I don't think anything in the rust compiler itself generates asm?) and rust tickles the bug somehow.
Recompiling just the libstd crate without optimisations makes it work. It appears that start , which attempts to calls . calls on linux. By inspection of the parameters passed to in the linux implementation of with gdb, the parameter is an invalid pointer (checked by inspecting by ). In theory should be in steps 2 and 3, though the functions look like they've all been inlined.


Managed to tear down std to get this test case: (it seems that since I originally reported this issue, the nightlies now have llvm assertions enabled)
Abort seems to be coming from TwoAddressInstructionPass. Backtrace (from gdb) at the point of abort is: <details<summaryClick to expand backtrace</summary<p</p</details
The rust code two comments up () when compiled with will produce . Inspecting with llvm-dis: If you now try and compile this with you will hit the assertion (assuming your llvm has assertions enabled): It works fine on the latest LLVM head. Turns out the fix was merged december 7th - is the bug, is the fix.
Looking at the llvm 4 release branch on the llvm-mirror github, this will be fixed when rust upgrades -
I backported the referenced patch, built a debug rust with it (i.e. debug-rust-large-fixed) and then built a release mode rust also with the backported patch and debug-rust-large-fixed (which took forever) and successfully ended up with a release-rust-large-fixed which can build itself.
Presumably fixed by LLVM backport -- doesn't reproduce today. I'm marking as E-needstest since it seems like something we should track in tests.
fwiw this is tricky to do a test for unless we want to do yet another rustc build in CI. I'm going to be rebasing our Rust fork 'shortly' and was planning to just close this issue once that's done and I've verified everything is working.
Oh... do we need to rebuild rustc for it? I was under the impression that just was enough to test. That's all I did...
Urgh yes. Sorry, this issue has a lot of history for me and I'd forgotten parts of it. Running the testcase above is indeed a valid test of the issue :)
Triage: apparently a test, but it was removed before it was merged.


The logging section of the 0.6 docs ( ) doesn't specify how you log messages. This link is broken: It is not broken in the 0.5 docs, but I believe the API has changed.


<!-- 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 tried this code: I expected to see this happen: code compiles in a reasonable amount of times or the slice gets elided entirely. Instead, this happened: code takes multiple minutes to compile/gets killed by the playground. <!-- 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. --: Also tested on playground stable and nightly.
The code compiled in about 6 seconds in Rust 1.29 and 1.30 : . Before that it had capacity error. After that it exceeded 15 seconds limit of godbolt. This is a but I cannot tag it.
It looks like this also works correctly on 1.31 stable as well:
Decided on as in the prioritization working group procedure.
Cc
Fixed in .


<!-- 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. --code from <!-- 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
I think this is the code crashing: Assigning P-low by the same rationale as , but I expect this to be much easier to fix than , , or
No longer crashing: `


With extra verbose flag (), one would see a lots of warnings about check-cfg when building -Zbuild-std. But it doesn't need to be that way. Can we doodfooding check-cfg flag to and to resolve them? Step to reproduce: I expected to see this happen: No warnings about " unexpected " Some are: label +F-check-cfg +-Zbuild-std cc


I found an error message that seems a bit off to me. The code: Clearly it should fail to compile, and it does. But the error message is: I would expect something like "a module name has already been imported", instead. Is it accurate to call it a type?