The docs currently claim that the minimum Linux kernel version for is 2.6.18 (released September 20th, 2006). This is because RHEL 5 used that kernel version. However, RHEL 5 entered ELS on March 31, 2017. Should we continue to support RHEL 5 for , or should we increase the minimum Linux Kernel version to 2.6.27 (2nd LTS) or 2.6.32 (RHEL 6, 3rd LTS)? . Even bumping the min-version to 2.6.27 would allow us to remove most of the Linux-specific hacks in . Example: .
Given that RHEL is the only reason we keep comically old kernel versions around, I would propose that Rust only support RHEL until Maintenance Support ends. This is (essentially) what we already did for RHEL 4. Rust never supported RHEL 4, and back when RHEL 5 still had maintenance support. It would be nice to get someone from Red Hat or a RHEL customer to comment. This policy would allow us to increment the minimum kernel from 2.6.18 to 2.6.32 (and remove a lot of Linux-specific hacks). Note that RHEL has a weird (and very long) support system for RHEL 4, 5, and 6 (sources: and ). It has 5 major steps: Full Support Normal support of the OS Maintenance Support 1 Bug/Security fixes Limited hardware refresh Maintenance Support 2 Bug/Security fixes The end of this phase is considered "Product retirement" Extended Life Cycle Support (ELS) Additional paid product from Red Hat Gives updates for a longer period of time No additional releases/images Extended Life Phase (ELP) No more updates Limited Technical Support End date not given by Red Hat Current status of RHEL versions: RHEL 4 Not supported by Rust Currently in ELP (no end date specified) ELS ended March 31, 2017 RHEL 5 Supported by Rust Currently in ELS Maintenance Support ended March 31, 2017 ELS ends November 30, 2020 RHEL 6 Supported by Rust Currently in Maintenance Support 2 Maintenance Support ends November 30, 2020
cc which I think they could be related.
It also may be worth to drop support of Windows XP and Vista (especially considering that panics are broken on XP since June 2016, see: ). Previously it was discussed . cc
Besides , which other things would we be able to clean up?
Good question! There are 6 workarounds in for older Linux versions (that I could find). Increasing the minimum version to 2.6.32 (aka 3rd Kernel LTS, aka RHEL 6) would fix 5 of them. Code links are inline: (mentioned above, in 2.6.23) ( in 2.6.24, there is also the mention of a bug occuring on "some linux kernel at some point") to atomically set the flag on the pipe fds ( in 2.6.27) ( in 2.6.27) to permit use of ( in 2.6.28) ( in 4.5, not fixed by this proposal) As you can see, the workarounds fixed by this proposal all have a similar flavor.
I am Red Hat's maintainer for Rust on RHEL -- thanks for the cc. I try to keep an eye on new issues, but this one slipped past me. Red Hat only ships the Rust toolchain to customers for RHEL 7 and RHEL 8. If our customers would like to use Rust on older RHEL, they can do so via , and we'll support them in the same way we would for any other third-party software. Internally we do also build and use on RHEL 6, mostly because it's needed to ship Firefox updates. This is where it gets a little hairy, because each RHEL N is bootstrapped on RHEL N-1 and often kept that way -- meaning a lot of our RHEL 6 builders are still running on a RHEL 5 kernel. I would have to apply local workarounds if upstream Rust loses the ability to run on 2.6.18 kernels. We prefer to keep fixes upstream as much as possible, both for open sharing and to avoid bitrot. Is there much of a benefit to removing the current workarounds? I agree all of that code is annoying and cumbersome, but it's already written, and as far as I know it hasn't been a maintenance burden. Do you see otherwise? If there are any known issues with such Linux compatibility code, I am definitely willing to take assignment for fixing them.
(Not a Rust maintainer, but I'm a Rust user and maintain a lot of other OSS software so I have well-developed feelings around supporting Very Old Software :-)) Do you have any sense of on what timeline Rust would be able to drop support for 2.6.18 kernels without causing you pain? In general I don't think people mind supporting configurations that have users and are painful to work around, but needing to support them for forever is a bitter pill to swallow! Particularly as they get harder and harder to test over time (already I have no idea how to test on really old kernels besides building it myself). So if there was an estimate "we'd like to be able to support this until Q2 2020", even if it's not set in stone, I think that would be very helpful!
The other benefit would be that Rust wouldn't have to use CentOS 5 for CI, which means we don't have to patch LLVM (and Emscripten LLVM) to compile on those systems. Of course that's also fairly limited in scope.
As soon as we stop shipping Firefox and Thunderbird updates on RHEL 6, I won't need Rust there anymore. AFAIK this does correspond to the end of Maintenance Support, November 30, 2020. Then I'll be on to RHEL 7 builders as my minimum, probably still with some RHEL 6 2.6.32 kernels involved. It should be fine for me if we update CI to CentOS 6. This is mostly concerned with how the release binaries are linked to GLIBC symbol versions, which is all in userspace. It's a broader community question whether any other Rust users still care about running on RHEL or CentOS 5. (Small caveat - glibc support for a symbol can still return , .)
I noticed that Red Hat also has Extended Life Cycle Support (ELS) for RHEL 6 until June 30, 2024. Will you need RHEL 5 to work during this time? I don't know how ELS works with Firefox updates. Also, is there any reason RHEL 4 support wasn't an issue prior to March 31, 2017 (while RHEL 5 was still normally supported)? This issue came up for me when dealing with opening files in , see for more info. No single RHEL 5 issue is that bad, it's mainly just the sum of a bunch of tiny issues.
I'm not on that team, but AFAIK we don't ship Firefox updates for ELS. The last build I see for RHEL 5 was . Maybe there could be an exception for a severe security issue, but I really doubt we'd rebase to newer Firefox for that, which means Rust requirements won't change. New Firefox ESR versions do require a newer Rust toolchain too, which is generally why we have to keep up. Otherwise we could just freeze some older compat rustc while upstream moves on. Rust wasn't required until Firefox 52.
that makes perfect sense to me, thanks for clarifying. So the proposed policy would be: Support RHEL until RHEL is retired (i.e. ends normal support). This would mean: Supporting RHEL 5 (v2.6.18) until November 30, 2020 Supporting RHEL 6 (v2.6.32) until June 30, 2024 Supporting RHEL 7 (v3.10) until May, 2029 This is a much longer support tail than any other Linux distros (that I know of), so it would also be the effective minimum kernel version of , , and their dependencies. How does that sound to people? EDIT: The alternative to this would be Support RHEL until it is retired, taking the table above and incrementing the RHEL versions by 1. It would also mean being able to drop RHEL 5 support now.
Sure, that's ideal for me. :smile: As mentioned, is just needed for kernel support, as far as I'm concerned. Userspace concerns like GLIBC symbol versions can stick to currently supported for my needs.
Red Hat should backport the features we need (CLOEXEC and getrandom, in particular) to whatever kernels that it wants Rust to support. I don't know any good reason why they don't do so, other than it's cheaper to convince the whole world to keep supporting older kernel versions than it is to do the backports. We should change that dynamic.
The alternative to this would be Support RHEL N until it is retired I think we should not officially support retired OS versions (well, maybe with some grace period), so I prefer this option. Supporting 14 year old kernels seems a bit too much to me. each RHEL N is bootstrapped on RHEL N-1 and often kept that way -- meaning a lot of our RHEL 6 builders are still running on a RHEL 5 kernel Is it possible to apply kernel patches to those builders to add support for functionality like CLOEXEC? Or build Firefox separately on RHEL 6?
I think it won't be fruitful for us to debate the merits of stable enterprise kernels, but no, this is not a possibility. An alternative take is "Red Hat should be responsible for the work in Rust to maintain the support they want" -- here I am, ready and willing. I definitely can't change those kernels. The ones that are stuck on N-1 are precisely to avoid rocking the boat, and backporting features is a big change. Some of our arches do eventually update the builders to their matching N kernel, but some don't, and I don't know all the reasons. If the workarounds are removed, then I will have to reapply them in our own builds. This assumes I keep using only our own binaries -- if I ever have to re-bootstrap from upstream binaries for stage0, I would also have to use some interception (like ) to hack in the workarounds. This is all possible, but much worse than the status quo of maintaining support here.
I think this sounds reasonable. We aren't going to be able to update these kernels, it's just a question of when we would drop support for these OSes. Especially given that we wont need RHEL 5 CI support, I think that leaving things as they are is fine. I opened this issue to verify two things: 1) That we weren't intending on supporting RHEL 5 "forever", and had a clear date when to drop support. 2) That someone from Red Hat actively cared about supporting these older kernels. It looks like both these things are true. We should remove RHEL 5 workarounds after November 30, 2020. This issue can be postponed until then. EDIT: For our use case in , we were able to add compatibility for RHEL 5 .
See for a recent case where supporting such ancient kernels required extra manual work ( to the 2 lines mentioned by above). I am not sure how often that comes up, but probably the hardest part is to even notice that it happens -- and even then those codepaths will likely linger untested.
Yes, but this will still be true in general. If the CI kernel is newer than whatever kernel baseline we choose, it will be possible for newer syscalls to pass undetected. I don't know if we have any control over that -- can we choose a particular VM image? So that leaves us with a stated policy of support. The more that developers are aware of such issues, the better, but I'm the one most likely to notice when my build actually fails. If I come back with a fix, I at least need the project to be receptive. I haven't been in the habit of building nightly on our RHEL6 builders, but maybe I should! Catching this early is better for everyone involved...
That seems reasonable. How quick is the Rust related bootstrapping? Could it be run automatically (or more frequently)? This is an interesting point. If I hadn't made that change, would have kept working on RHEL 5, it just would have leaked an FD. I'm not sure how we would even test for this sort of thing. This isn't a RHEL 5 specific concern, I just don't know how Rust tests these types of resource leak issues in general.
About 2 hours. Automation is harder, since I believe our build system needs my credentials, but I'll look into what is possible here. Yeah, that's a lot more subtle than an !


Found with the help of .
There's two slicing operations in . I'm trying to figure out how a non-boundary index could be appearing in there... maybe is calling with a span that begins at index 10? (where does this come from? ?) Building a debug compiler to check those log statements... Edit: Building the debug compiler was a bust. Embarassingly, things seem to have changed and I don't know how to get those debug macros to fire in the current compiler.
do you mean you were using and not seeing debug output? If so, that is because the environment variable name under was changed to . (I make this mistake pretty much every day due to muscle memory.) As an example, here is the tail of my log output:
triage: P-medium. Removing nomination.
This was broken between 1.15 and 1.16, but those are so old and the nature of the ICE itself has changed from 1.28 to 1.29, so I do not think bisection would be worthwhile.
<details<summaryOfftopic</summary : Thanks. Unfortunately, I did guess the name of after didn't work, and all it showed me was this: I set in my before building, and didn't see anything else in there. (I recall that and used to be but it is no longer, so I did not enable it.) </details
Okay, I did the following evil, evil thing: <details<summaryPure evil, do not open</summary</detailsAnd acquired the following backtrace of when the span was first constructed: It also gets constructed a second time: <details<summarySecond backtrace</summary(the region of the backtrace that differs between the two is items 22-29 in the first one, or 22-25 in the second) </detailsSome interesting spots from here: This is clearly where the value of 10 is created: calls this if there are no remaining tokens and it still hasn't seen the closing delimiter (it seems to have as an unstated precondition that the closing delimiter must exist). Here's the innermost bit that's specific to parsing. Doesn't look that odd...
I’m not familiar with I tend to list (comma separated) module paths in my own use of RUSTCLOG; did you try that? You can see an example in the transcript I gave in my comment above
Oh. (I'm so used to prompts I didn't notice you included the command!). Yeah, that was the issue.
Same ICE occurs with: Which returns:
could you post a base64-encoded version of your ? When I copy/paste what you've posted above, I don't see a compiler crash, presumably because some non-ascii characters are getting lost.
My bad
Hm, the example from hasn't been fixed?
Seems so, on the current nightly:
I guess my fix would help. I'll get some time to test it out.
Confirmed that my fix fixed this issue, I also add this unit test in this PR:


The godbolt link: I think this snippet should just return : The generated asm with :
I think there are 2 issues: is not const fn is not const fn See this modified example:
I may misunderstand but in the C version, does clang require similar conditions to optimize code? modify labels: A-codegen A-const-eval
Those are preprocessor directives and are handled at compile time so their Rust equivalent would be:
states that macro:
Good point, those two are equal: I don't know enough about const and I could be totally wrong but I think in the first case expands to something like: It cannot make constant because is not yet complete.
Interesting, If I look at MIR output, I think rustc already have enough information: <details<summaryMIR</summary</details
Whether a function is marked at the source level has no effect on whether or not it can be optimized by LLVM. Even if was not , inlining and const propagation could conceivably reduce this to a constant.
Rust now generates the for the OP's code: I would guess that recent improvements to const propagation in the MIR are responsible for this (thanks but it might also have been a change in LLVM. This seems like a decent candidate for a codegen regression test, although an equivalent one might already exist.
It is better now. But are and instructions necessary?
I assume it is due to a difference in calling convention, but it does seem kind of silly. You'll need to ask someone more knowledgeable unfortunately.
A quick google leads me to believe that the is used to align the stack to a 16-byte boundary.
So does it: Looks like only regression tests are needed.
This version doesn't need any stack alignment:
I tried to leave this alone since I'm not very knowledgeable in this area, but curiosity got the better of me. The following might be incorrect, but it's my best guess. In the optimized LLVM IR for rust, a call to remains which has been optimized out in the C++ version. I believe stack alignment on x64 is required only prior to a instruction, so LLVM sees that a non-trivial call instruction exists in the IR from rust and that only has an 8-byte return pointer on the stack, meaning the stack would be misaligned for that . That's why it inserts the stack alignment code in the rust version only. At some point during translation to x86 assembly, the gets removed entirely (I have no idea how), resulting in a function that has a / to align the stack for a call but that doesn't actually call anything. Perhaps someone more familiar with the various LLVM passes could say more. BTW, a fairer C++ comparison is the following, but this gives the same results:
There's some discussion of this in . I was indeed wrong BTW :smile:.
This issue appears to be fixed on beta. Maybe we need a codegen test for it. Edit: It seems that the llvm-ir generated by rustc are the same between beta and stable. Only the optimized asm for x86 is different. Should I just write assembly codegen or just close this issue.
The issue seems to have re-appeared in master :(
Both & generates the following asm (with )


A clean rust project on the latest nightly rustc with just this : produces the following error on cargo check/build: <details</detailsThe error is most likely caused by the inability to deduce the value of the const generic parameter ; when it is made clear (with, say, ) the ICE no longer occurs. Thus the expected behavior is probably still a failure to build (just not an ICE).
EDIT: Apparently const-generics in array repeat positions isn't a thing yet, at all. I apologize for the not-even-currently-valid example. I get the same ICE for this code: <details</detailswhich does give the explicit type, so it's not (entirely) a deduction thing. Entire build log: <details</details
Could you check the ICE still appears? I cannot reproduce it with latest nightly on playground.
Although this isn't throwing an error on the playground, I get an assertion failure when adding a test: Let's leave this open until we have a test for it.


The following code () leads to an ICE: Broken since 1.32.0 up to the current nightly, earlier versions are not affected. <details<summaryBacktrace of the nightly build</summary</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
modify labels to +T-compiler, +A-diagnostics, +A-parser, +I-ICE
claim
you will need to change the line to bubble the error up: Once you've done that code change create a new test file in .


Reproduction code: If I re-export in the module, it works as expected, having enum in the type-namespace and variant in the value-namespace ().
Compiler team check-in: I'm marking this as P-medium for now as it is not classified as a regression, although it seems like a fairly major problem. appears to be on it, though.
Feel free to add the I-nominated label if you think it should be P-high
late last year. could you take a look at this to see if it is valid for the invariant being checked not to hold in this case? If I comment out the the output is reasonable:
I'll see what happens (that's why I self-assigned). The assert is there to catch the cases that resolve logic assumes to be impossible. It may work ok if the assert is removed, but it may also mean some deeper issues, this needs a more detailed look.
The above error message without the looks a lot like and .
but it may also mean some deeper issues was exactly the case here! Thank you for reporting. Fixed in


I'm getting an internal compiler error on the following program (found by ): I'm seeing the error on stable, beta, and nightly. As with , the error occurs on () but not on (). , the proposed fix for , does not fix this error. cc


This fails with: I believe this should compile because: non-async function with the same signature does compile; insignificant tweaks, like adding a wrapper struct, make it compile. Mentioning who fixed a similar error message in . Mentioning who touched this error message in and . rustc 1.38.0-nightly ( 2019-07-26) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Check-in from WG-async-await meeting: I agree this is a bug -- it doesn't necessarily block stabilization (no fwd compat risk) but would definitely be a good one to fix. Marking as blocking + unclear for the moment and will return to it.
I did a bit of investigation. The error results because we have an inference variable () that seems to have no constraints, but must be equal to one of the captured regions (e.g., ). I haven't 100% figured out where this variable comes from, I imagine it's related to though? In any case, the resolver basically winds up in a situation where it could pick any of the lifetimes but has no reason to prefer one over the other, and hence it reports an error.
OK, I think I see what's going on. It doesn't actually have much to do with the unused lifetime per se. What happens is this: The type of the generated result is something like -- i.e., it includes the types of the parameters, though with region variables in place of the known regions. Those types must be supertypes of the actual parameter types. We capture the argument of type -- per the subtyping rules, we create the type for the type of this captured value, with the requirement that -- as it happens, this is always true, so there is effectively no constraint on . We do impose the constraint that and must both be equal to one of the free regions -- in this case, or the anonymous lifetime of (which I'll call ). So thus the region solvers get in a state where must be equal to , , or -- but any one of them would be a reasonable choice. Removing the unused lifetime () makes this an easy choice -- it can pick , which is smaller than . (Per the "least choice" rules we usually use.) Removing the type and putting it into a struct () removes the lifetime variable altogether, as then we have , and there are no lifetime parameters involved. I'm not sure what I think is the best fix. It would be nice for the solver to pick , though it complicates the algorithm. You could certainly imagine a tweak that picks if the value is legal and otherwise looks for a least choice. That might indeed be superior to the current approach, though I'd want to think about the full implications -- in particular, when is used in places outside of the fn return type (e.g., in a statement), picking might lead to unnecessary borrow check errors. (The alternative would be to only look for when there is no least choice; that seems safer.) (Interestingly, at some point at least I thought that a polonius-like approach sidesteps a lot of the challenges here-- if we had confidence that we would transition that might ease some of my concerns.)
Now that I understand better what is happening, I don't feel this has to block stabilization -- in particular, I don't think that there is a forward compatibility risk from us improving the region inference algorithm. I don't think we would choose an algorithm that makes existing code illegal. =) As such, I'm going to mark this as Deferred.
Here's another example of the same problem that doesn't have an unused lifetime (AFAIKT): Removing any of the three arguments to the function allows it to compile.
I am also affected by this bug, where having both a reference and a box as parameters to a function causes the cryptic "hidden type for captures lifetime that does not appear in bounds" : () Is there a resolution in sight ?
is unused in that function - if you remove the it compiles.
Ok, let me change it to something closer to what I had in my original code: ()
I think I found another example of this: () This example more or less represents what I met in my code (when I tried to pass a structure with a type parameter to an async function with the default value for this type parameter being a trait object), but it can be simplified by removing the default parameter assignment and passing the argument to explicitly: () Curiously, if you replace with , the error goes away: () It is important to note that the function has two additional arguments. If you remove one or both of them, it starts compiling again: ()
's comment is a minimal reproduction of what I ran into. I had a function . If I remove two of the cache arguments it compiles. As soon as I add one back in it gives me the title error.
Hmm, it is probably worth revisiting this problem now that stabilization has happened.
Any word on this? I'm getting this error as well. Changing to fixes the issue. Only problem is that I actually want to move that vector in because I want to each call to .
No progress or major updates. The is still accurate as to the root cause, but I think we don't yet know the best fix.
this is going to become a problem now that is merged. It makes it impossible to implement for types with lifetimes, when the future that's returned is unnameable. consider
Here's another very simple example: Removing any of the 3 parameters makes the code compile. Alternatively, removing the static lifetime of (→ ) makes it compile as well.
Hi. I get the following error that matches what everyone is also getting:
I have the following case triggering this error message:
Got the error in the following: Removing helps. rustc 1.50.0-nightly ( 2020-12-09)
I know I am late to the game, but this issue still hunted us down with a Rust 1.48 compiler. The workaround is simple, but it pollutes all the callers with extra lifetime parameters. Basically, wherever saved us from introducing a lifetime parameter, we have to introduce it in s, s, everywhere. () If someone wants to workaround this issue without polluting the callers, they could use an async block inside a regular function: () Maybe if you treat special in the async function implementation, like in other parts of the language, that would cover most of the cases where this issue is hit.
Another short example based on reducing code from a discord question:
And 2 workarounds for the issue:
Found this after pulling my hair out for a few hours. At least I've got a workaround now, but I'd have to say this behavior is really unexpected. Of those two workarounds mentions only the first seems to be actually usable if you actually want to do something with those parameters: // Compiles async fn foo<'a(x: &'static str, y: &'a str, z: &'a str) { println!("{} {}", y, z); } // Doesn't compile: // error[E0759]: has an anonymous lifetime but it needs to satisfy a lifetime requirement fn bar(x: &'static str, y: &str, z: &str) -impl Future<Output=(){ async { println!("{} {}", y, z); } }
I'm going to remove the "async await triaged" label so that we take a second look at this. Maybe worth reprioritizing. I'll see if I can post some mentoring instructions.
Just hit this as well.
claim I'm claiming this to write some mentoring instructions
FWIW, in the meantime, and also to help solve the issue with manual capturing a potentially bigger invariant lifetime, I have published a helper proc-macro-attribute crate that automatically appends the necessary hacks:
Coming to this too, a little google drives me here. This thread is almost 2 years old, is there any solution or plan to fix this?
explicit lifetimes on references should fix the issue for you until compiler is smart enough to figure that out on its own
release-assignment I haven't had time to write up any mentoring instructions here, I'm afraid. :(
Big sad. I wish I was more into the compiler details. I love what async-await did to learnability for newbies and this issue hunts down them after getting their first successes.
I want to ensure that, is it because the readloop function might execute after the scope of self reference? If so, how can I explicitly set the lifetime of readloop is greater than the reference?
note that your code can be automatically fixed by the tool I mentioned in : ! A reliable fix that doesn't change the semantics of the function You can even query that attribute with the extra parameter fed to the attribute, and the eponymous Cargo feature, to get: <img width="681" alt="Screen Shot 2021-07-05 at 14 36 38" src="https://user-"For the specific case of usage, you can try changing the signature of the function to one using , that is, with the bound on the trait object explicitly spelled out: This leads to a simpler signature regarding / / TAIT unsugaring, and circumvents the issue of this thread. _ I'd like to experiment with unsugared's TAIT being automatically generic over all the lifetime parameters in scope of the return type. This is what achieves by using the hack for each and every such lifetime, and I've never encountered cases where this would be an error. If that approach seems fine to you, I can try to implement this new unsugaring on the compiler myself, although I may not be very fast since I'll need to experiment a bit to get acquainted with the related compiler internals
thanks, I will try that.
I just got bitten by this and I'm a beginner. 's workarround worked but a proper fix would be desirable.
are you saying you want to change how works for all cases? That would certainly be a breaking change, so I don't think we can do that. However, it would be good to talk about a better fix than the hack. One thing we talked about in the very beginning was having a syntax like to be very explicit about what things are captured and what are not. But that would, I think, require a lang-team proposal.
claim
When I thought about this I struggled to come up with an instance of this, so I'm genuinely curious about it. In other words: could annotating a function with / add lead to breakage somewhere along the way? If so, such an example could help us evaluate the different options at our disposal
OK, I've read up on this issue again. The basic diagnosis I had is correct. The fact that some of the lifetimes are unused isn't really especially relevant. For example, in the , the problem is simply that there are two lifetimes (from and ) along with the . This still gets us into the situation where the inferencer must pick between , , or . Let me run this through the compiler and take a look at the constraints. I also want to think about how polonius affects this.
I just read over . The reason that this "desugared" version works is because it introduces a new lifetime, , and this lifetime has a relationship to every other lifetime. So when we have to pick between , , and , we now also haev the choice of , which is strictly less than all of those choices. So we pick that. Now I realize that the reason that this whole situation is a non-issue in polonius is basically that the polonius representation permits lifetimes that are the intersection of a set of lifetimes. So you could infer the result to be , which is effectively the same as . But in the current implementation, we don't have anything like that.
I'm not sure if I understand exactly what you were proposing here, I thought at first that it meant: would be able to capture (because it would capture that lifetime). That would be a breaking change, but is that what you meant?
Fix in
, effectively defining it, for all intents and purposes, as the intersection lifetime! (which indeed meets the bounds) Ah yes, I see now how there are definitely two distinct issues at hand, here, and that my fix for one just happened to fix the other as a byproduct _ So, while your PR will fix the one, I'm personally still concerned about the case of the existential capturing both , and it's to tackle that one that I was suggesting that existentials were, internally, allowed to be generic over all the lifetime parameters in scope. That is, what I meant, or what I'm basically qualifying as a bug, is the fact that and don't have the same semantics, lifetime-wise (so, to clarify, I am definitely not talking about changing the rules for lifetime elision in function signatures): In the same fashion that stands for , and can thus not capture since it is -bound,then stands for and can thus not capture yadda yadda. And in the case, the is not needed, so it can be skipped if the implementation doesn't need it. But the key change I am suggesting is the definition of that existential. Currently, it would be defined as something like , and then unified. What I'm suggesting is that it be defined as , much like what adding a would achieve. This would be meaningful, for instance, in all the cases with a captured invariant lifetime which is not equal to the lower bound. Take , and . In that case, if instead of we had , the signature would work. But in the case, we have a , and such a type definition cannot be unified with the actual type of the implementor, , since there is no in scope of that definition. My observation is that I believe it cannot hurt to have too many lifetime parameters "in scope" / reachable for an existential's type definition. In that regard, the hack, be it manual or automated through the attribute, is just a way to test my theory: the attribute currently adds bounds for every lifetime it meets, without asking further questions, and that suffices to make the existential type definition be generic over all of them, and this whole thing has, empirically, solved the compilation problems without any problems on its own, thus allowing for and to remain quite interchangeable (lifetime-wise, barring obvious safety caveats).<sub<sup(Slight aside: I've noticed that this , so it's really just the lifetime parameters that it's being (overly) picky around, it seems)</sup</sub
Just hit this as well.
Encountered this today. Though the original error was this, which I couldn't reproduce it in playground. Removing any of the parameters the error is gone rustc 1.66.0-nightly ( 2022-10-01)


It took a colleague explaining to me that the return type of a function returning an impl Trait is unique across function definitions for me to understand the following error: This becomes more important for async/await because of the automatic translation of to : In the first case, can the error maybe call out that the opaque types are different due to how the compiler treats them? And for the second error, can this be called out in async-specific language. That error happens when you forget to call .
How about?: In the second case I think we should suggest that the s be moved into the branches tho this may be complicated to encode as a diagnostic. cc
Agreed, this is definitely a bit trickier. I'll defer to you on the best way to message this error.
In the first case, can the error maybe call out that the opaque types are different due to how the compiler treats them? Doesn't it already does so?
what is the correct nomenclature for a regular, non-opaque type that we could use here? With that we could say something like "consider materializing to an explicit type in both branches from the opaque type" and "for you can them on both branches to unify the types". This is rough wording, but gives an idea of what I'm thinking.
The antonym of opaque is transparent but I'm not sure that is situationally good to use here. ISTM you'd want to say something like "use an enum with variants for both cases" (at least that's the advice I'd give in person). I'd go for a non-actionable description as a first pass at this problem and consider an improvement later.
Are opaque types the same as anonymous types in C#/Java? If so I think 'anonymous' is clearer than opaque (pardon the pun!).
This is a real gotcha of rust and needs a great error message. We could show the definition sites of the opaque types so it's clear which type is expected in this position: Something like:
It doesn't matter where the resides in. Two uses will result in two distinct types from the POV of the type system. Only by naming an through a type alias can you refer to the same inferred type. Adding the qualification "in function signatures" does not enlighten. As for "anonymous", the closest equivalent Java's anonymous classes, which conjure new types, in Rust are closures. Also, with Java's anonymous classes you can recover the type identity at runtime using but you cannot name them. However, in Rust can be named (using a alias), they do not representationally create new types (although they do nominally), and they do not leak their type identities. Rather, is about hiding the underlying type (think of as a coercion that hides the type). The is most similar to Stanard ML's opaque matching (see section G.2 in the ) All in all, opacity is therefore the most appropriate description rather than anonymity.
I'll get used to :-) You're refering here to ? Most of the time when someone gets this error they're assuming they can do this but don't realise they need to make the two impl Traits be the same type. We could hint that there's an unstabilised feature that could help? But if they weren't trying to bind both impl Traits to be the same type, then given both types textually look the same it would be great if the error message could point out the difference between those two types. Currently the error says: As a nubie I need to see something different between the two types that I can get my teeth into. How about: Somehow it would be great to distinguish these two opaque types (or does the compiler at this point has no knowledge of where these two opaque types came from - only that they are not the same?).
Fwiw, we desire to keep jargon to minimum.
was removed from the language in in favor of just . We could hint towards that on nightly. Seems like a nice improvement.
Thanks Centril - hadn't seen that switch. If people are ok with adding line numbers to pinpoint the different impl Traits I'll have a go at rolling a PR?
With all the various improvements that we've done, is there more we could do? or shall we close this issue for now?


As seen in , when running the tests on Windows there are slightly different things in scope than when the tests are run normally. per
see also
Part of .
Closing, removed check-fast


Any crate that uses fails to compile with a link error saying Test case on outputs: or from a bigger project: Nightly / works totally fine.
Is this reproducible after ?
Yes, happens on a fresh project I made for testing () and after
is the full commit range, which notably includes an LLVM upgrade -- cc Could you check with if is fine and is broken for you?
I can confirm that works fine but is broken. Also, that's a nifty tool.
Okay, LLVM update is then definitely at fault, cc
With default settings I'm not reproducing this locally with on . Do you have any rustflags set in your cargo config or environment variable? What is the full output of ?
Here is the full failing output from <details</detailsIndeed, my are set to Testing again without does not error, and compiles/runs fine.
If it helps, I'm on AMD Zen v1, or , and it looks like was introduced in the LLVM upgrade.
Fails the same way on Linux (GNU and musl) and Windows GNU using on Ryzen 2700X platform so it probably affects all the OSes. <details<summaryDetails</summary</details modify labels: -E-needs-bisection -O-windows-msvc +O-linux +O-windows +A-LLVM
This seems like LLVM's auto-detection of what CPU is on the host or what the target features your native CPU has may be broken. The next step for this is to probably use a build of Clang to reproduce and then report this upstream to LLVM itself.
Er sorry I have a guess as to where this is but I do not have time to investigate this right now, so I'm going to unassign myself since I can't take care of this.
Minimised: IR: I cannot build Clang/LLVM from master right now so I'm attaching IR from my code above. I'll try to find time tomorrow or somewhere next week.
Confirming that produces a call instead of a under .
I believe the cause is that the znver feature spec is missing (the 16B variant is listed).
LLVM bug reported at


The idea behind was that it should only show a backtrace (of where a Miri error originates) when an error is actually shown to the user. And that worked fine when I implemented it. But since then, something changed in constprop, and now I get thousands of backtraces even for crates with no errors, making the env var basically unusable. That is a big problem for debugging of the Miri engine. Even shouldn't show so many errors, but that will be harder to do for constprop which runs the CTFE engine on broken and non-monomorphized MIR (causing tons of problems, not just this). AFAIK you did a bunch of const_prop changes over the last few weeks/months; likely some of what you did is the culprit here. Any ideas?
Well. Const prop tries to eval things and if it fails it doesn't prop. The reason why there are many errors now is that we are actually using the interpcx instead of reimplementing its logic
I'm not sure how to reduce your noise. Maybe we can disable the env var before const prop and reenable after?
only prints when  is explicitly called -- somehow constprop must be triggering that. If that was fixed, things would still be slow because so many backtraces are captured, but at least the result should be readable.
The really fancy solution, but probably too magic, would be to determine if we are running inside a const_prop query and let that alter the behavior. AFAIK rustc uses thread-local storage so this could actually be done, but it might not be how that TLS is supposed to be used.
my guess is that the printing originates here: calls , but that line does not always result in an error to be shown, right?


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 prioritization.
introduced an ICE (integer overflow) in the error emitting code, that Miri runs into.
will fix the issue on 's end, which should automatically fix this one.


rustc warns that the entire line is an unreachable expression however the code is clearly executed as can be see If the line was truly unreachable, there would be no panic... This bug appears on stable, beta and nightly
The is the unreachable part, so perhaps the error should be rephrased and pointed at that function call only
Hmm, so the span is wrong?
the order of execution is panic! and then everything else, so in some sense everything but the panic is unreachable. I'm not sure what a good span for that would be.
The method receiver is evaluated first, so the and calls still happen. The span can point just at the .
Ah, hm, I didn't expect that to be the case, but it makes sense. Then this seems relatively straightforward as to what the expected output is at least.
I feel like this should also add a note that the panic is called before everything else. It could also suggest but that seems more like a clippy lint.
Similar case: Maybe we can simply add a note that won't be called because evaluation of its arguments leaves the current code path. I agree that suggestion is indeed too specific and may be better suited to clippy. If this is acceptable, I would like to pick it up! As long as it's fine for me to progress more slowly than normal
GitHub wasn't clever enough to read that the PR said "might close" instead of "close." The PR seems to imply more work can be done on this.


Because is the 's default for application-level logging and should not affect the output of the tools.
eh, it's only recently we've shifted away from using it for tools -- but seems like the trend is definitely to do so. I've filed


I encountered this as well. What project are you trying to build? My theory is that it tries to run something like (in ?) and then fails to parse the output which is a mix of and ...
Way earlier, it runs it right at the start of a compilation to get the rustc version and enabled . Probably
Could someone use to narrow this down to a particular commit?
It looks to be caused by (I would assume it is in that rollup). It is now printing the time-passes information even for .
would you be up for a fix here?
I'll take a look on Monday. In the meantime, here's my best guess: I an extra entry to the output that prints the total time for the compilation. That extra line may not be indented at all, and it's possible this means it isn't ignored the same way as indented lines.
My theory about indentation was wrong. It was indeed a bad interaction between and , as others suggested, because they both print to . has a fix.


Hello, I ran into a problem using lifetime with async struct methods, here is the example: struct Foo<'a{ swag: &'a i32 } impl Foo<'{ async fn bar(&self) -i32 { 1337 } } The error is: '_ Everything is fine if I use explicit lifetime like . Version: 1.39 Nighly (2019-09-19 on playground)
This is happening because the desugaring of uses the lifetime. This is sort of unfortunate, but seems backwards compatible to fix, so I don't think we should block on this.
We decided to focus on this one in the WG meeting -- you still interested in working on it?
Yes, I'm still interested in working on this. I don't think that this should be too hard to fix though if someone else wants it.


If you have a of utf8 data there's three ways to get a : There doesn't appear to be any way to hand over the existing and have any necessary character changes into be done in place_. The type doesn't, for example, have a way to just do a lossy in-place conversion.
- I would like to implement this (I have no contributions yet in the project). May i please claim the request?
I think that normally the Libs team is given a chance to comment on the issue (it's only been 3 hours), but the worst that can happen is that they reject your PR. All I can say for sure is that I will not be implementing this particular patch myself.
Thanks for letting me know, I will wait until someone from the lib team will respond.
Seems like the right API here is actually , since I believe there is never a need to allocate more bytes. Unfortunately I guess we'd need two APIs for this to be perfect, one on String as well, since there's no safe way to get from running this function to a of the bytes, right? The only safe way would be to do which is guaranteed to succeed but is costly...
1) I don't want slice to slice. I definitely want owned to owned. I'm not sure why you'd think that slice to slice is somehow more correct. My goal is that whenever possible no additional allocations will immediately happen during the conversion (obviously this isn't always possible). 2) You definitely can have byte sequences where the lossy conversion into utf8 makes the sequence longer and thus could hit the capacity of the allocation and thus could trigger a reallocation. Trivial example: becomes , which is longer.
Hm, I had thought that the lossy conversion always replaced a single byte with a single byte, if that's not the case then the slice case is indeed not all that helpful probably. If this was true then the slice case would be good to have as a more general form, though.
So we want this signature: , right? That seems like it can be via a PR relatively easily.
That is one option. Another would be to add a method to so that you can consume that error into the lossy String. The value here is not having to start over on the utf8 parsing.
There was a post with possible designs on internals:
I hope gets soon :)
I prefer this approach for a couple of reasons. It signals whether or not the conversion was lossless. Whereas if we went with the signature , some pairs of inputs collide, like the pair and , or the pair and . Also, it will deter people from checking for the presence of to tell if something went wrong. This is a footgun I've seen in the wild. And even for users who "just want a string" and don't care about the error, you can still reasonably get that in single readable line:


Godbolt link: So I expect these two functions has the same assembly: But the result is not:
modify labels: -C-bug -I-slow T-compiler
Hey I tried solving this but wasn't really sure how to. I believe the implementation to the LLVM generation is right here. Hope someone can solve this!
Turn out I was wrong! The is working correctly (i.e. those two functions are not equivalent): I would add some doctests to show that and close this issue.


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


cc Code first. This code: , gives this set of error messages: The part that I'm most concerned about is: Before eRFC "if- and while-let-chains, take 2" (rust-lang/rfcs, , ), this code USED to result in this error message: The reason I know this is because , in the section where we're trying to explain the difference between statements and expressions. The error message I'm seeing now is muddying the waters by saying " expressions". Based on my reading of the eRFC, it's only supposed to change , but as kind of a side effect is now sort-of an expression? The don't clear it up for me, as they only describe , not plain s. What I expected is that even though the eRFC has been accepted and implemented, plain would still be considered a statement and the error message wouldn't talk about " expressions". If my expectation is valid, then the compiler error message is a bug. If my expectation is invalid, please let me know so that I can work on updating the book. Thanks! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Also notes in  if sync discussion is desired. So the new compiler error, introduced in , here is by design and tested in which has more notes. Specifically, the error here comes from HIR lowering. The idea is that is a syntactically valid expression in all cases (on nightly). The distinction between semantic and syntactic can be noticed via macros and conditional compilation. Semantically however, is only allowed in the cases that notes, namely the cases generated by the grammar : Eventually however, e.g. with a follow-up RFC, I would like to turn into a true semantic expression typed at such that e.g. becomes legal. So overall the goal is to "muddy the waters". The reference has not been updated because we only make updates to it once a feature becomes stable. With all that said, I'm open to tweaks to the error message (it's optimized for suggesting that e.g. is not legal). For example, we could have a different note for stable compilers or when the feature gate is not active. cc
I would be happy with a different error message for stable compilers that continued to call outside of a statement rather than an expression.
Should be easy to implement by tweaking the HIR lowering code just a tiny bit. Will try to do that sometime during the week but no firm promises. :)
if anyone wants to work-steal this from me then this would be a good first issue. You'll want to tweak  by keeping the current wording when holds and changing it to suggested wording (the old one) otherwise.
There's precedent for different messages depending on whether the current compiler is stable or not and whether there's a feature flag enabled or not. I don't think all three cases are needed here and just gate on the feature being enabled.
I'd go further to say that we should be doing what describes most of the time: unless a feature is enabled, and the old diagnostics were useful, don't spit out new "you tried to use this feature but it's unstable" diagnostics that aren't helpful.
I'll take a stab at it. First time contributor, so I might not know all the hurtles, but I'll take a swing at it.
assign
I'm not sure if this is a good idea, because is usually used to create variable bindings. But with expressions, the scope of these variables can get much more complicated. Example:
It's probably best to discuss that once an RFC is made but let's not do it here. :)
claim
I've got the change locally now with exactly what had mentioned in a previous message. The only thing I'm getting right now is that the compiler is highlighting the entire statement and not just the keyword like before. I'm looking for the method where I can get this. I'll put up a PR in a bit to show where I'm at along with some terminal output to demonstrate a bit better what I'm talking about if it doesn't make sense already.
Opened
Don't worry about the span, it is ok as it is in your pr.


The and targets force panic=abort. said : This looks related to , which points at these now-merged LLVM changes: It's possible that we do not need to force panic=abort anymore for arm64 Windows as a result. What's the best way to determine if this is still required?
Theoretically the way to fix this issue is: First Next, run the build Finally, run the tests If that all passes, then the change can land! The tests may be able to be skipped, and some tests may fail, so it may be possible to switch the defaults and we can fixup bugs later. I don't personally have hardware to test these changes on myself, though.
I occasionally have access to a Windows arm64 laptop, so I'll try and get a rustc build going on it at some point.


I tried to compile some massive project and the rust compiler unexpectedly panicked. Luckily, I have managed to replicate the error in a small, reproducible example (still panics on rust playground online, 11 lines of code): I expected a regular error without a panic, but the compiler simply halted. Output of RUSTBACKTRACE=1 rustc -o -C debuginfo=2: Output of :
Maximal reduction: This didn't ICE in 1.37.0 (checked with godbolt).
triage: P-medium (based on assumption that one will always see something like that error message, with its span, before the ICE). Assigning to self for now (but I welcome others who would like to work-steal it). Removing nomination label.
assigning to as well based on insight that this ICE may be arising from diagnostics.
I believe I have a fix. I'll post it after lunch. Edit: faster than I thought.


The following code was working in nightly-2019-09-05, but no longer works in nightly-2019-10-15. The workaround is not quite intuitive. () Errors: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm also running into this error using Tide and a DB Pool from Diesel I've managed to get a slightly simpler/different version of the above code - I'd expect this to work because I'd expect the to be finished before the starts (I guess it's similar to how pre-NLL we'd expect function calls in arguments to work but sometimes they wouldn't because existing borrows?) I've managed to track it down to happening somewhere between these - but I'm not sure how to go about figuring this out any further (I've never built the compiler, let alone actually debugged it) This successfully buildsThis fails
This was an intentional change to match the drop order in synchronous code:
This was an intentional change but these errors also look like they are caused by "overapproximation" of the set of captured values. We are working to improve that; separately, we are also working on improving the diagnostics here.
Assigning to myself as this is a case I'd hope to tackle in . It isn't currently handled by that PR, as the current diagnostic improvements only work when the error originates from an , not . claim
I found a similar problem: Is this the same bug?
Unassigning myself since has landed.
adds a compiler message to suggest a workaround for this problem. Is it not possible to make the compiler smarter and not borrow unnecessary variables across ?
rustc is not that smarter yet, we already have an issue tracking this , along with were trying to lint users with "shorten" workaround(might be lifted once the analysis is improved) in these two "common" cases.
It's a matter of having consistent language semantics for async and non-async code. The lang team discussed this and decided the drop order should be consistent (i.e. we shouldn't drop temporaries until the end of the statement, even if the statement contains ).


Reasons for: . According to , musl caused a program to run 9x slower. Musl is also known to be slower in certain configurations in C. This varies a lot with the use case and some might even see a performance increase with musl. docker containers using . It is possible to link glibc statically as demonstrated . From what I can tell, on the user facing side, this would be enable using as described in .
The reddit thread mentions libm. And another source of speedups might be the malloc implementation (glibc 2.26 introduced thread-local caches). One can already use custom global allocators, maybe it would make sense to link a custom libm too?
First blocker is the license. Glibc is licensed under LGPL, it has dynamic linking exception so one can freely link dynamically to it. Static linking doesn't fall under this exception. I'm not a lawyer but I think Rust would have to be licensed as (L)GPL to fit it. Another thing is glibc doesn't really support static linking, sure it works well for small software but bites you when you need more of it's features.
(Obviously not a lawyer but), I'm pretty sure that as long as the code it is linked against is (L)GPLed, it should work.
Also as long as the program it is linked against is licensed under a GPL compatible license, it is allowed. The MIT license, is compatible. All this information can be confirmed by looking at the above link. You can even link proprietary code against LGPL if you provide the object files.
because of we need special linking arguments because of the symbols. see also for and glibc uses for the nss modules.
The former should be doable. The latter is a tradeoff that people will need to understand if they statically link glibc, and it's something they already have to deal with if they use .
Implementation instructions: Add an entry for glibc-based targets you want to support to (Same as for musl, but -, because is undesirable ().) Perhaps libm or libpthread will need to be linked in the same way. Set to in target specifications for glibc-based targets you want to support (in ). Test that it actually works, this will require some building of libstd with cargo overridden libc dependency.
I'd be happy to submit the necessary changes, if you can outline what needs doing. () See the comment above.
Thanks!
I have this successfully working; just waiting on a release of the libc crate containing .


On 2019-10-24 we had a CI outage due to the ca-certificates msys2 package being broken. The hack implemented (:heart:) is to download an older, known good package beforehand and install it after msys2 updated its packages. Once is fixed we should revert the hack, but I think at this point it's worth investing in vendoring msys2 as a whole.
msys2 is using and other tools from archlinux distro. Arch Linux provides per-day official repositories snapshots. User can "pin" to a specific date. I think it is possible to reuse that mechanism to vendoring msys2 as a whole, by providing a mirror of a specific date's version. See here for more descriptions .
that would be nice but msys doesn't remove old packages from their repo so the mirror would be enormous. Search for in , only those packages take dozens of GiB. Also extracting it from archive would make CI a bit faster because you won't be modifying thousands of small files over and over. On Linux that is not a problem but working through cygwin emulation a bit struggles on this part.
No update on this, planning to discuss what to vendor at the all hands.
At the last infra meeting we decided a good step is to move towards using the pre-installed msys2 packages. In theory this is as simple as removing the msys2 installation step and pointing things at the right location on the images in CI.


Hi, I'm building a project and I'm using the nightly channel. I was testing it with several builds between 2019-09-20 and 2019-10-27, all with the same results – when targetting native, the compilation succeeds, when targetting WASM, we see ICE. Unfortunately, it was hard for me to minimize the example. Fortunately, the codebase is pretty small. Here is the exact commit: After downloading it you can run and it should succeed. But if you run (which is 1-line wrapper over ), we get: After commenting out this line, everything should compile OK (WASM target should compile as well): EDIT The backtrace from the compiler is not very helpful: However, there is some additional info:
That code is a mess! After an hour of digging through the code and removing half of it - the code that triggers the error is: I try to produce a MCVE out of it currently
Yes, the code is in a very work-in-progress state, so there are a lot of places which should be refactored or even removed, sorry for that. The line that I mentioned in my original post calls the function that you have pointed to. The function alone compiles well to WASM. It does not compile when used as follow:
Seems to be related to . Here's something small-ish: I may give it a shot later, but now I'm gonna head home :)
that is amazing! I've created yet shorter version (still, there may be things to simplify here):
modify labels: -O-wasm +F-typealiasimpl_trait
< 50 loc :tada:
thank you for tracking it down
could you please change the title of this issue to something different, e.g. "ICE with impl Fn alias"? It's not about WASM anymore ;)
Because a lot has changed, here's a summary: <details<summaryMCVE</summary</details<details<summaryBacktrace</summary</details
Relevant log output: <details</detailsIt looks like is getting normalied to (since the underlying type of is ) when we attempt to compute the layout of a type. However, the still contains , which will not match with the normalized version. I think the solution is to normalize the when we call on it.
triage: has PR. marking P-high, removing I-nominated.
It seems the ICE (with MCVE) has been fixed in latest nightly.
It has been fixed by , marked as E-needstest
Reopening due to


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 compiler team prioritization.


Hi there! This is the second time I've compiled code with Rust ever, and my first time filing a bug report, so I may need some guidance if the info here isn't quite enough to work with :). Learning about println! in Rust by Example, I incorrectly entered the below code. I looked at the documentation and realized I had made a mistake, but the compiler still panicked and recommended I open a bug report. I really believe in Rust and want to see this project succeed, hopefully this information is helpful! I tried this code: println!("Pi is roughly: {:.*}, 3, 3.") Expected to see this happen: "Pi is roughly 3.142" Instead, this happened: thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', note: run with environment variable to display a backtrace. error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.38.0 ( 2019-09-23) running on x8664-unknown-linux-gnu :rustc 1.38.0 ( 2019-09-23) binary: rustc commit-hash: commit-date: 2019-09-23 host: x8664-unknown-linux-gnu release: 1.38.0 LLVM version: 9.0 Backtrace: thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', stack backtrace: 0: backtrace::backtrace::libunwind::trace at 1: backtrace::backtrace::traceunsynchronized at 2: std::syscommon::backtrace::print at 3: std::syscommon::backtrace::print at 4: std::panicking::defaulthook::{{closure}} at 5: std::panicking::defaulthook at 6: rustc::util::common::panichook 7: std::panicking::rustpanicwithhook at 8: std::panicking::continuepanicfmt at 9: rustbeginunwind at 10: core::panicking::panicfmt at 11: core::panicking::panicboundscheck at 12: syntaxext::format::expandpreparsedformatargs 13: syntaxext::format::expandformatargsimpl 14: <F as syntax::ext::base::TTMacroExpander::expand 15: syntax::ext::expand::MacroExpander::expandfragment 16: syntax::ext::expand::MacroExpander::expandcrate 17: rustcinterface::passes::configureandexpandinner::{{closure}} 18: rustc::util::common::time 19: rustcinterface::passes::configureandexpandinner 20: rustcinterface::passes::configureandexpand::{{closure}} 21: rustcdatastructures::boxregion::PinnedGenerator<I,A,R::new 22: rustcinterface::passes::configureandexpand 23: rustcinterface::queries::Query<T::compute 24: rustcinterface::queries::<impl rustcinterface::interface::Compiler::expansion 25: rustcinterface::interface::runcompilerinexistingthreadpool 26: std::thread::local::LocalKey<T::with 27: syntax::withglobals note: Some details are omitted, run with for a verbose backtrace. query stack during panic: end of query stack
This code fails on nightly, beta, and stable. Here's a link to the minimal failing code:
The entirety of the println is a string: So it shouldn't compile,instead it should print this error:
I believe the error is caused in the following line: the correct code would be , but you have encountered a bug in the compiler's diagnostic machinery. The output you should have seen is


When trying to compile the following code, a panic occurs on :
Also happens on nightly
ICE reproduces all the way back to 1.36.0; before that, it still ICEs but in a different place.
Maximal reduction: ICE arises in: Blame: cc
I suspect this is a duplicate of . But the test case is slightly different so I'll leave it open for now
triage: P-medium (via analogy with priority on ), removing nomination label.
Triage: This is no longer ICE with the latest nightly:


It is linked to This is the tests we need to add (the list is non-exhaustive): [x] a UI test for each setting [x] click on element in the sidebar hidden by default to be sure it gets fully un-collapsed and scrolled to [x] make tests for each shortcut [x] make tests for source code navigation (through files in the first time should be enough) [ ] run all the previous tests in mobile mode
I think this issue can now be closed. For the mobile tests, I also think we them where it was necessary.


A MSVC x8664 bors job has failed on two unrelated PRs (, ) with the : In both cases, attempted to allocate several GB of memory while compiling the crate. One of these failures was in the job, and the other was in . This failure appears to be spurious: a previous version of passed the same job.
I wonder if we could get a backtrace or something from this allocation -- it seems... suspicious that we're only sometimes OOMing. It's also interesting to note that this is almost exactly 4 GB in a single allocation, which is surprising generally ( is not a big crate -- 300 lines or so, with comments etc).
On my PR it was a different (almost) power of two: edit In both cases, the size of the allocation is 8 bytes less than a power of two.
So I minimized this to: on a recent nightly gives: It looks like the compiler is trying to allocate enough space to store a value of the return type. As long as I use a large enough value it reproduces reliably and it isn't specific to Windows: . I bisected this to and I'm guessing (cc is the root cause.
Yes, that seems likely. I will take a look at this tonight.
should we put on hold while this is sorted out?
Yeah, let's do that just to be safe.
triage: P-high. Removing nomination label.


When using zipped iterators in a certain section of code, I hit an ICE. I've attached the project source -- sorry I could not produce a minimum example though I tried. Also, it's closed source, though I own it so can choose to provide the snapshot. Symptoms: Normally using zipped iterators doesn't cause an ICE, but in this case it is consistent (clean build, using , and ). Not zipping the iterators, and using prevents the ICE from occurring. This code fails to compile: This code compiles: Compilation error message: : 1.39 (stable): 1.40 (nightly): Backtrace: <details<summary1.39 stable</summary</details<details<summary1.40 nightly</summary</detailsInvestigation: Steps to reproduce: and run Relevant source file: Interestingly, using on the iterator on the ICE-ing code allows it to compile: Also interestingly, using the version within without also causes the ICE, so it's not the zipping that's causing it, but rather something to do with the being a reference rather than an owned value.
Seems to be an issue with Crash on stable, beta, nightly
regression from stable-to-stable 38.0 "worked"
A reduction would be good :)
I'm on it.
You want a MCVE? I give you a MCVE! modify labels: -E-needs-mcve +E-needs-bisection
Reduced:
regression between ...
cc
is the one to blame .
triage: P-high. Removing nomination label.


For example: This gives you a warning that should be snake case in the match arm. But at that point you don't really have much choice about it. Variable name warnings should be where the variable is named, and it isn't really named there. (Maybe there's some syntax like but who is going to bother with that?) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Please provide a working example without next time. It makes it easier to see what's going on here. Let's assume this one: You could instead write and have full control over the names of the binding and that's why the compiler is complaining. You are right in the way, that we should lint the original issue. I'm not sure how the the suggestion goes in terms of machine applicability and renaming of further instances of this variable. Let's see what the future will bring :)
Direct repro link: Current warning: Seems like a diagnostics fix to change the help to
We discussed this in the lang team meeting, and we agree with the proposal here. We shouldn't warn twice over the same field name; we should only warn about the definition, and not again when you match it. Note, in particular, that it seems like a relatively common pattern to disable these lints only in a module written by bindgen or otherwise written to match some external spec/API, but leave them enabled in the rest of your code. So, :+1: to not linting for field puns on field names that don't match the recommended style. (We should still lint when not punning, if you define a new local name that doesn't match the recommended style.)
Hi, I'd like to take this one. Just to make sure I'm understanding this right: We want to warn on identifier used to define the field name in the struct itself, and not on the match binding. Is that correct?
We definitely want to warn on the struct definition. My understanding is that we don't want to warn on the binding when you didn't actually write the binding ("for field puns"). So we don't warn on but would warn on (and definitely on ).
That makes a lot of sense. Thanks! claim
Right, exactly. I would suggest starting by writing some (failing) test cases for the desired behavior including warning output. I would be happy to review that step and confirm.
I've put up a PR with the failing test case. How's this look? Are there any other cases I should test?


One issue that came up in the discussion is that the type implements . This might have been introduced accidentally. probably does not matter at all, given that users will only observe a by reference. However has the impliciation that we will not be able to add non thread-safe methods to - e.g. in order to optimize thread-local wake-ups again. It might be interesting to see whether and support could be removed from the type. Unfortunately that is however a breaking change - even though it is not likely that any code currently uses out of the direct path. In a similar fashion it had been observed in the implementation of () that the type is also and . While it had been expected for - given that s are used to wake-up tasks from different threads, it might not have been for . One downside of s being is that it prevents optimizations. E.g. in linked ticket the original implementation contained an optimization that while a was not d (and thereby equipped with a different vtable) it could wake-up the local eventloop again by just setting a non-synchronized boolean flag in the current thread. However given that could be transferred to another thread, and called from there even within the context - this optmization is invalid. Here it would also be interesting if the requirement could be removed. I expect the amount of real-world usages to be in the same ballpark as sending across threads - hopefully 0. But it's again a breaking change cc , , ,
Even if this weren't a breaking change, I'd want to see some really good evidence these optimizations would matter for real world code before choosing to make these types non-. I don't think getting rid of an atomic update in is a compelling example. Basically, in my view the current API is intentional and correct.
was introduced to leave room for future unforeseen requirements, and being restricts its usefulness as such, which is unfortunate. I can see a case for since we have , but it's difficult to imagine a case where it makes sense to be accessing a single from multiple threads concurrently.
I have an example of where the current API is resulting in performance issues: I am trying to implement a combined Executor/Reactor around a winit event loop. To wake up the event loop from a different thread we have to post a message to the event loop which can be a non-trivial operation. But on the same thread, we know that we don't need to wake up the eventloop, so we can use much cheaper mechanisms like an atomic bool.
But that would be true if wakers were just also, which was an intentional part of the simplification from the previous design.
I think the point is that being precludes the otherwise noninvasive restoration of a more efficient through an additional method on .
I don't think it should be the judgement of the libs team (or any of us) to determine whether something is good enough and not needs to be further optimized for any use-case. Rusts goal as a language is to enable zero cost abstractions. This requires in my opinion to not be opinionated on any design choices which have a performance/footprint impact. I think some of the decisions that have been taken in the async/await world however are opinionated, and will have an impact on use-cases that currently are still better implemented with different mechanisms. I do not really want to elaborate on anything more particular, because I fear this would bring the discussion back to a arguing whether any X% performance degradation is still good enough. That is an OK decision to have for a software project whichs needs to decide whether Rusts async/await support is good enough for them, and whether they have to apply workarounds or not. But it's not a discussion which will move the issue here any more forward, because for yet another project the outcoming of the discussion might be different. PS: I do think it's okay and good if libraries like tokio or async-std are being more opinionated about what threading models they support, and they might sacrifice performance gains in rare usage scenarios for easy of use. But and language features are different, and we expect people to use them also for niche use-cases (e.g. there is certainly a lot of cool evaluation going on with the use of async/await in embedded contexts or kernels - where requirements might be very different than for a webserver based on tokio).
This is a trade off: Context is either Sync or it isn't, some users benefit from one choice (they can use references to Context as threadsafe) and some users benefit from the other choice (they can have nonthreadsafe constructs inside the Context construct). Ultimately the libs team has to decide one way or the other on these points in the API where there is a trade off between thread safety and not. However, this decision has already been made and it would be a breaking change to change it, so this discussion is moot.
Do you have an example where this is actually done within the ecosystem, or a use-case for it? As far as I can tell, this would require spawning a thread using something like and capturing the from within a ?
A common way a user could depend on a type being is to store it in an and send it across threads. This isn't very likely for Context but it is a very reasonable pattern for .
I think its a fair point that we didnt intentionally make context send and sync, and that this precludes adding more fields to context that are not send and sync, and that since context is just a buffer for future changes, it would probably have been better to make it non-threadsafe. But now its a breaking change. If crater showed no regressions and there's no known patterns it nullifies, I would be open to changing this about Context personally, but I am somewhat doubtful the libs team as a whole would approve making a breaking change to support hypothetical future extensions. If anyone on the thread wants to pursue a change to context (not waker), they should get crater results as the next step of the conversation.
There is no discussion about being or not - it obviously has to be. The question is purely about . And in order to do what you describe you have to store an and send it somewhere. Which is very doubtful to happen, due to the not very useful lifetime and due to already being an like thing internally. As mentioned, the most likely way to see this behavior is some scoped thread API being used inside - or people doing some very advanced synchronization against an IO driver running in another thread. For all those there are certainly better ways than to rely on being . E.g. to return a flag from the synchronized section and call from the original thread when done. Or to and send the if there is doubt whether it needs to be persisted somewhere else. And yes, the impact on is even bigger. It was meant as an extension point. But we can not add any functions to it which are not thread-safe. E.g. if we want to add methods which spawn another task on the same thread as the current executor thread, and which allows for spawning futures (like Tokios ) - we would have an issue.
Why would these be "certainly better" than just calling from the scoped threads?
To be a little more expansive: the scoped threadpool you're talking about could very well not be scoped inside a poll method - rather, the waker could be cloned once and then owned by one thread and referenced by many other scoped threads in some sort of threadpool construct for CPU bound tasks. This seems like a perfectly valid implementation which allows you to divide up the work among many threads without cloning the waker many times. This is potentially an optimization. I don't think this optimization is very important, but I don't think the optimizations allowed by making waker are very important either. The point is that there's a trade off between the optimizations allowed by assuming references to wakers can be shared across threads and the optimizations allowed by assuming they can't be, its not the case that one side is inherently the "zero cost" side.
We discussed this at the recent Libs meeting and felt that deferring to would make sense here.
Though I don't have the bandwidth to carry this, this definitely seems interesting. Seeing projects such as and closed-source initiatives lead me to believe that there may actually be a decent case to enable some form of -to avoid the synchronization overhead on single-threaded runtimes. I don't know if we should make this a priority, but at least we probably shouldn't close it just yet.
I think bringing back would be a nice additional improvement. But for the moment it would be nice to just fix the general sync-ness, which blocks all other fixes and improvements.
As the person who originally introduced , it was very much a conscious decision to get rid of it and to make and . This was called out explicitly .
The cited discussion in the RFC justifies making Send, and predates the decision to (re)introduce . Making doesn't defeat the objectives discussed there. In particular, it does not impact ergonomics for the common case at all.
This was recently closed, however the issue mentions both and . The recent change only affects . There is good reason that is , however after reading this issue I'm unsure that there are good reasons why is .
(NOT A CONTRIBUTION) Waker supports wakebyref, and so it is possible to pass to another thread and wake it from that thread. This functionality would not be possible without Waker being Sync. Supporting wakers that are either not Send or not Sync will best be done by adding new APIs to Context and a new LocalWaker type.
Forgive me the naive question, but how does a type work with ? As I understand, requires , as a concrete type not a trait, so this would also require a trait? At this point we have two completely incompatible async systems... Which is only useful if is not cheap to clone, and has the burden of another lifetime bound. It surprises me that the docs don't say anything about the intended cost of .
(NOT A CONTRIBUTION) Future::poll does not take Waker as an argument, Future::poll takes Context. Context could have the ability to set a LocalWaker, so that an executor could set this. Reactors which operate on the same thread as the future that polls them could migrate to using the LocalWaker argument instead of Waker. Here is a pre-RFC that someone wrote with a possible API: Commentary like this is both factually wrong and not helpful for the mood of the thread.


This works; let's consider adding a test for it since it's a bit of a special case. Reported to be working in by
do you mind if I add this? My laptop is no longer broken ^^ so I can actually get some work done without disappearing for a week at a time. I put this in a file called and ran , is that about the right approach?
It is, but I'd recommend using to make it go faster. Also use to just test that file. Also, I'd rename the test to not suggest ... something like .
I ran about an hour ago and that worked fine (although it took a while ^^). However, since then I updated nightly and I'm now getting compile errors when building stage 1: What am I doing wrong? Full error: (cross posted from https://rust-)


I'm trying to build my crate on nightly, and I'm getting a compiler panic. I bisected several nightly builds to try and narrow down when the problem started. The last known good nightly was , and the first failing was The panic also occurs in . The crates causing the panic are available here:
cc
triage: P-high, removing nomination label.
Minimal repro:
As some info, I've narrowed down the offending commit to –– most likely the changes in .


I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.


First discussed in issue As of Rust 1.39, casting a floating point number to an integer with is Undefined Behavior if the value is out of range. fixes this soundness hole by making “saturate” to the maximum or minimum value of the integer type (or zero for ), but has measurable negative performance impact in some benchmarks. There is some consensus in that thread for enabling saturation by default anyway, but provide an alternative for users who know through some other mean that their values are in range. PR adds that method to each of and . /// #![feature(floatapproxuncheckedto)] /// /// let value = 4.6f32; /// let rounded = unsafe { value.approxuncheckedto::<u16() }; /// asserteq!(rounded, 4); /// /// let value = -128.9f32; /// let rounded = unsafe { value.approxuncheckedto::<i8() }; /// assert_eq!(rounded, std::i8::MIN); /// The trait (tracking issue: ) has macro-generated s for all combinations of primitive integer and primitive floating point types:
We briefly discussed this in the lang team meeting today, and felt that stabilizing this would help unblock progress on making not unsound in the edge cases (i.e., where this function is UB). would you be up for proposing FCP merge here to stabilize the methods (but not the backing trait)?
I have some concerns regarding the naming of these methods. First of all, the general convention in all existing methods is to put at the end of the name. The only exception to this rule is . Secondly, I feel that is a poor description of what is happening. This is particularly concerning since this is an unsafe function. I propose that these methods be renamed to , which makes it absolutely clear what operation is being performed. Since the current lang team consensus is to make perform a saturating conversion by default, the name also serves as a contrast to the "default" way of casting a float to an integer.
I plan to post a PR soon with the renaming to , possibly including a stabilization with that (since we often rename and stabilize in one go I think and it seems unlikely that waiting would help).
Proposing to merge this with the name . fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Renaming sounds fine. I’d just like to point out that we may want multiple float-to-int conversion methods (with different semantics) in the future:
:bell: This is now entering its final comment period, as per the . :bell:
I've opened up a PR with the rename and stabilization:
In Rust we have arithmetic operations that are checked in debug builds and unchecked in release builds. I think I'd like a FP-int conversion that does the same. Is this a good idea?
This has been discussed at length in An important difference is that unchecked arithmetic can let overflow happen which could could logic bugs, but the uncheked float to int conversion can causes Undefined Behavior which should never happen in Rust without .
Even if we take "unchecked in release mode" to mean "some defined behavior" rather than UB, the trade-offs are very different: With integer overflow, the "unchecked" option is defined as two's complement wrap-around, which is practically free to implement (just omit the overflow checks). For float-int casts, there is no behavior that's consistent across platforms and requires no extra code to be executed. Integer arithmetic is pervasive in most/all applications, so overflow checks apply in a ton of places and their performance impact can be spread across the whole application, requiring a "bulk" switch. In contrast, conversions from floats to integers are much rarer and (as far as we know) if saturation does impact performance then it's due to individual conversions in hot loops. This makes it much more practical and appealing to decide checked vs unchecked on a case-by-case basis after profiling and manual inspection.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.


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.


(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.


Creating a stack closure which references an owned pointer and then transferring ownership of the owned box before invoking the stack closure results in a crash. For example, in Rust 0.6, this will compile and the resulting program will then crash with a SEGV
Does it still crash on the branch?
It dumps core for me, on incoming: Adding an xfailed test. We want this to fail compilation, I guess.
This bug could be fixed by the proposed solution in this post: (namely, bullet 1, not 2)
Dup of and more specifically .


This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.


Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///


The following program compiles, and prints :
As pointed out by on discord , this also works on stable:
Regression introduced in 1.40.0, specifically this line:
I have a fix in


Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
has landed, so a fix should be possible now. are you on this or should I try my luck?
T-compiler triage: P-medium, removing nomination tag.


Hello, I'm in the process of upgrading Rust to 1.41.0 on Alpine Linux and it appears that a TEXTREL has been introduced in 1.41.0: The full build log is located here if it's of interest:
This apparently breaks Android builds, since that forbids text relocations
+1 I am one of the unfortunate winner of a release-blocking CI build failure for Android now that we've upgraded to 1.41.0. We've disabled android-x86 builds for now :(
I a minimal repro to my repository here: , in the hope that it can help debugging this (and because I was curious to dig into this myself :-) ). You can clone the repo, then In the container you can run . I bisected it using rustup and nightly releases, 2012-12-09 is good, 2019-12-10 is bad: When using nightly-2019-12-10:
Conveniently, no rollups! Auto merge of - tmandry:bump-compiler-builtins, r=alexcrichton Auto merge of - mark-i-m:fix-rustc-guide-2, r=ehuss Auto merge of - lqd:placeholder_loans, r=matthewjasper Auto merge of - estebank:issue-, r=eddyb Auto merge of - cjgillot:corrida, r=Mark-Simulacrum Auto merge of - GuillaumeGomez:move-clean-types, r=kinnison I would personally suspect . Can you try checking this via Specifically, comparing and ?
While rustup-toolchain-install-master compiles ( ): I see that upgrades compiler-builtins. I had a look at the commits in compiler-builtins which touch , and I think we can likely narrow it down to At this point I'm too much out of my depth, this needs people more knowledgeable than me . I hope I could help debugging this, and will continue watching the issue as I'm learning a great deal just by investigating this. Besides the actual fix, there are two additional things I'd love to understand: 1) why doesn't detect this? It looks like the obj file is not marked in any way has having a TEXTREL, but maybe the inline asm from that commit defines rustprobestack in such a way that relocating it needs touching the .text section (wild guess) 2) how would we go at testing this? Where in the rust project would I add a test for this? And given that scanelf can't detect this, maybe a good way to "integration test" this would be to build a minimal rust static lib, and try to link it into a shared object with like I'm doing in the repro code. Do I understand correctly that "all code produced by rustc should be relocatable" is a guaranteed property (thus worth testing), or am I completely mistaken?
Meanwhile, I can confirm that we got the right commit ():
triage: P-high. Assigning to self. Leaving nominated because I'd like to discuss this at today's meeting.
cc who did the rollup of compiler-builtins, do we know which of the following PRs may have caused the problem rust-lang/compiler-builtins (seems pretty clearly ok) rust-lang/compiler-builtins (remapping ? seems ok) rust-lang/compiler-builtins (modernize test crate, seems ok) rust-lang/compiler-builtins (atomic intrinsics? seems ok) rust-lang/compiler-builtins (atomic intrinsics? seems ok) rust-lang/compiler-builtins (gitmodules? probably ok) rust-lang/compiler-builtins (bcmp? seems ok) rust-lang/compiler-builtins (eliminate __fltused on uefi targets?) rust-lang/compiler-builtins (FFI unsafe warnings for i128/u128) rust-lang/compiler-builtins rust-lang/compiler-builtins hypothesizes , do you know that this could be the cause,
It could be. Likely the difference is in the attributes of the probestack function (before that change it was a rust function, afterward it was defined in raw assembly). could you try adding the line around ? If that fixes it, it may break it in other environments (e.g. when generating code for a shared vs static library). We'd probably need to thread some new cfg flags through, but I'm not sure if that's actually possible. The other way is going back to defining the assembly in a naked function, but , prevented me from doing this the first time. cc
cc (though they're on vacation this week I believe) on the inline assembly options as potentially relevant for RFC and if they have thoughts on how to fix it for this case
I would agree with the conclusion that is the most likely candidate here for a cause of the regression. That being said I have no idea what TEXTREL is, what's happening there to cause it, or how we might fix this.
Looking at the objdump output, you can see the difference between the 2019-12-09 and 2019-12-10 nightlies: The textrel happens because the has global visibility and can therefore (in theory) be overridden at runtime, e.g. with LDPRELOAD. This means that the dynamic linker will need to patch the .text section at load time to fix up the call instruction. As suggested, adding should fix the problem since the linker will then resolve references to the symbol within the shared library itself.
That's probably the correct fix then, I'm just not 100% sure it will work on all targets . If it fails we should see it in CI, though.
Will this be released in a 1.41.1, or should distros just apply this downstream? We'd very much like Rust 1.41.0 without TEXTRELs on x86.
Also, thanks for the quick fix of course :)
I would not currently wait for a 1.41.1 release. I hope that it will make it into 1.42 though.
Alright, thanks for the info.
Thanks for fixing this! I verified that this solves the issue on our end, and opened a PR with a simple regression test. The test fails on i686-unknown-linux-gnu when I revert compiler-builtins to 0.1.24.
I'm not sure this is the right place to bring it up, but without this fix it is impossible to deploy a rust static library to platforms that enforce properly-relocatable code (x86 android). It didn't make the cut for 1.41.1, is there any chance for 1.42? Can we help to make this happen? Thanks!
is beta nominated, it will be backported soon and included in 1.42 release.
Fantastic, thanks. Do you think it would be worth it to also include the regression test () in the release?
CCing the reviewers
awesome, I am waiting for a release with this fix. Any idea when 1.42 is planned?
Stable releases usually occur every 6 weeks, so it should land in ~2 weeks.
I've nominated the regression test as well!


Incorrect hint for variable with a similar name defined using raw identifiers () Errors: Should be <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I've fixed this issue and will try to find and fix more similarly incorrect suggestions before submitting a PR.
claim I would love to take this up. It would help to know where I should begin.
Sorry for dropping this, my exams are around the corner.
claim
Hi I'm in the middle of the implementation of this issue. Would it be possible to assign it back to me?
claim
Unfortunately, I'm extremely busy right now, therefore I will unassign me so that someone else can work on it.


Hello, I'm trying to build a pure-LLVM Rust (no linking to at all). Building rust with set as in returns failure since Clang (the C compiler) doesn't allow . Here's my : Here are the relevant bits of the log: Thanks. A complete log is available here:
I think I may have found the culprit. I'm not well-versed in building rustc (I particularly don't know why rust can build its own LLVM instance, but I assume this is to accommodate systems where LLVM doesn't even exist?), but isn't the choice between and is pretty much irrelevant per libc? And by the way, using gcc as , while it does accept the command, it warns (instead of erroring out like clang-9) because isn't supported in the C compiler.