The page currently talks only about the use of move with closures. The keyword is also valid before an async block. For example: . This page could be updated to include that usage. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Edit  and make the text talk about async blocks as well.
claim


Summary from : used as a tuple-struct constructor function should use the fully type-substituted form from the block, but does not. Thus, today this code is accepted, but it should not be. (Fixing this would be a breaking-change, so we should take care in how we deploy it.) Original bug report follows: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: In nightly rustc, compiles while yields a type mismatch error:
The one is incorrect, has all its generic parameters substituted, i.e. it's / in both cases, type or constructor function.
To be 100% clear here: I believe what is saying is that the compiler has a bug, and that the bug is that the code should be treated as a short-hand for: and thus should be yielding the same error that one sees for the cases in the code from the description. However, the code is not yielding an error at all.
T-compiler triage: leaving nominated for T-lang. Tagging as P-high priority to resolve whether the semantics described by is indeed what we want, and if so, how to address deploying a breaking-change to fix it.
cc I thought we had fixed this bug in (and to be clear, it's clearly a bug (as noted by in ). It should not compile.
Just to simplify a bit (still passes but shouldn't):
Just checked on godbolt and it seems to compile in every stable release since it was stabilized (). I haven't looked into the code again, but I don't really understand how didn't cover this. Did we forget to add a test with errors, and only tried to prevent ICEs, or something?


<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: This runs correctly (i.e. doesn't assert) when run with rust nightly, but fails at when run with miri on nightly (2020-02-20). It seems like miri just truncated the f64 to get the f32 and therefore converted the nan2 to a floating point zero instead of a floating point NaN
(Miri-the-tool has its own bugtracker at , where I see things earlier than when they are burried here.) Cc this could also be an apfloat issue as that's what Miri uses to implement casts. I don't think we are doing any truncation . Would be interesting to see the bit patterns involved.
for returns . So, this doesn't look like just a truncated to me, it looks like apfloat did something but that something is not correct (or at least, not nan-preserving -- I am not sure if that is a guarantee).
cc
Sorry, I should have said truncated the fraction there. The is the floating point exponent being set to all ones, the (plus the empty bottom 3 bits in the 8) is a truncation of the original fraction in the f64. By removing all the non-zero bits in the fraction it converted the NaN to an infinity. For reference for returns where the (plus the empty bottom 3 bits in the 8) is a truncation of the original fraction from 52 to 23 bits Note that the normal Rust compiler seems to always set the MSB in the fraction of a NaN during its conversion to avoid this problem. There is and is
Assuming that f64-to-f32 on NaN has fully defined semantics, we should probably have a test asserting these exact bit patterns for Miri. But what you wrote makes it sound even more like the bug is in apfloat, and not in the Miri code that feeds data to/from apfloat. FWIW, the float casting code is .
Yes, it does sound to me like an apfloat issue rather than something unique in Miri. Reading that casting method I can't see anything that is special casing the fraction truncation for NaNs, only for an 80bit extended precision type that has different NaN semantics. Sorry, I've not dealt with the bug workflow on Rust before - is it possible to move this bug to apfloat? Would you like me to create a separate bug on apfloat?
apfloat does not have a separate issue tracker, no need to move anything. However, if I understood correctly then apfloat is a direct Rust port of LLVM's apfloat -- so likely they have the same bug, and a fix would have to happen upstream as well.
Yes, rustcapfloat is a port of LLVM's APFloat, but (also in older versions, back to before started the Rust port). Note that the MSB of the significand is set, so this is indeed a NaN. It seems LLVM does not have the same bug. Something strange is up.
Hm, that's still not the same as the that we see at run-time though?
I think the LLVM C++ code doing the same cast is .
Sure, but that's intentional. Optimizations need to preserve whether something is a NaN but (by default) the payload bits, quiet/signaling distinction and sign bit are not generally preserved or guaranteed to match between compile time evaluation and run time evaluation.
So the semantics would be something like "if the result is a NaN, non-deterministically pick any legal NaN representation"?
That sounds about right. Kind of off-topic here, though -- if you want to discuss further, we have
The category should still be , but it looks like we don't enforce the significand is non-: <hr/ Wait, I just looked at your link and LLVM prints - that's a bitpattern, not a , lol. But with a to integer, it matches : (if you hover over the decimal value, helpfully shows it as hex)
Note that converting floats to double bit patterns happens when printing textual IR: I'm reasonably sure the constant folding produces a proper float (). But perhaps the non-zero bits in its significand are in bit positions 32? Then the bitcast code would silently drop them.
Just remembered I wanted to look at assembly or machine code to see what the LLVM lowers to and show that it's buggy in LLVM even outside of constant-folded bitcasts.
Also isn't a +Infinity, showing the had already truncated the significand?
. And I just realized that while the high half of is a f32 NaN, the whole bit string as an f64 is in fact a NaN and setting just one bit more (e.g. ) does make llc (and presumably bitcast folding) produce (an f32 NaN). So I guess that I interpreted incorrectly and the fptrunc folding is at fault after all.
So... what does this mean? Is it an LLVM bug, and do we have enough information to report it upstream?
Yes, either truncation needs to result in a non- (e.g. becoming when losing lower bits could be "rounded up" by setting it to ), or extracting the IEEE representation from should handle the situation by setting some bit. cc (I don't know who does upstream LLVM bug reports nowadays most often)
actually I misremembered what this bug is about. This is not just "surprising NaN payload", indeed the result here is not a NaN when it should be. So that is quite clearly a bug in LLVM's APfloat, or in the Rust port of it (but we seem confident the problem is upstream). It would be great if we could report this against LLVM, but I have no idea how to reproduce the problem with LLVM. Do we need to write a C++ program using APfloat, or can we somehow make this happen just with the right LLVM IR? was previously posted as an example, does this show an incorrect compilation? These bit patterns mean nothing to me.^^
Wow! That's extremely wrong! It turns a NaN into positive infinity! Poking it gives a bit more insight into the issue: shows that all bits in the NaN payload below the 29th bit are truncated here. Mercifully, I can repro this in rustcapfloat, which is easier for me to experiment with than LLVM's (okay, I also remember what a headache it was trying to make changes to LLVM in the past, and it's now not something I'm interested in doing in my spare time) That is, it reports has , but then turns it into . Doing some further digging shows points me to , where we call with a number that comes from the difference between (bits of significand) of the source and target, e.g. 53 - 22, or 29 (which all-but-confirms that this is the issue). (The branch where there's the sig::shiftleft is wrong too, FWIW). It's also pretty wrong — IEEE wants you to truncate the payload here, not shift it out. e.g. I think what you want to do is something like (this code intentionally doesn't compile, and is assuming is the target type and that things are beautifully simple enough that there's just a function which returns something I can bitand...): That said, this is possibly hopelessly wrong? I don't thing so but I don't have a copy of IEEE754 around to verify. ... ... Okay I tried to make it compile, and if you drop this beast in before the shifts (e.g. line 1488 as of commit ) the tests pass (Sorry, I foolishly did this in a github download of rustcapfloat, since my rustc is in the middle of other things, and so I can't easily just give you a patch) That said it could still have other issues. And the fix could be extremely wrong for other reasons, it's the result of not-very-long spent debugging. Someone who understands the code better should audit it for this issue ( It says you wrote ). Ditto for LLVM's version which I can hardly follow since my C++ is so rusty. That said, LLVM is a popular enough project that someone hopefully could take it from here? E.g. Turning a NaN into an infinity is extremely bad — obviously so. Masking away the bottom bits like this is an obvious bug (nothing anywhere does that), and so even if they don't care about preserving NaNs specifically I suspect they'd want to fix this. Edit: I wrote this without carefully reading the rest of this issue. I think you uncovered some of this? Maybe? I don't know. Maybe this helped, sorry if not.
Yeah that sounds wrong. :D I'm afraid I cannot comment on the internals of apfloat that you are getting into for the rest of your post. That stuff is way beyond me.^^ I understand you won't work on fixing this in LLVM, but could you make this a bugreport for them, in their bugzilla? I feel a bit awkward making a bugreport that basically says "look I don't know what I am talking about but I have it on good authority that what LLVM is doing is wrong". Would be better if someone who knows what they are talking about does that I think. ;) Chances are, they'll have someone who can fix it.
says I'll send them an email, but...
Argh. :/ I think this worked fine for me though. If they don't respond in a few days, we can also use me as a proxy.^^
That sounds fine. In the meantime it maybe be good for someone more familiar with the rustc_apfloat code to take a look at what I wrote anyway...
There was already a bug, but I a comment for it:
There's a fix on the LLVM side now, somewhere in -- there are multiple reviews, we should figure out which one actually landed. Anyone up for porting this back to the Rust apfloat?
I guess would be the page to check for what happened in apfloat upstream.
Done:
The fix on the LLVM side is the minimal possible fix to avoid the linked miscompilation here: It doesn't fix this bug in the general case.
is a more correct fix. But note that it's not just the change to APFloat that makes it correct (in fact, that change alone is arguably wrong), but at usage sites changing things to be (for example): I think we should probably do this inside our function, otherwise it would be incorrect too. This is unfortunate as it causes more divergence to upstream APFloat
are you referring to this segment of your comment above? Can you quote the part of the IEEE 754 standard which mandates this? Or alternatively, come up with an example like the one at the top where there is a mismatch between what happens at runtime vs during miri evaluation? Apparently hardware implementations shift out payloads as well: prints:
Larger example that compares runtime and const eval (as of nightly master): prints: Edit: apparently on the hardware it always unconditionally sets the highest bit of the mantissa when a NaN truncation is performed to work around the issue. Edit2: which is nothing other than turning the sNaN into a qNaN.
IEEE754-2019 6.2.3 (NaN Propagation) states that This seems impossible if the implementation shifts the payload out. But I guess this only applies to qNaN, although in my testing earlier it seemed to happen on sNaN on my machines. Anyway, I'm a bit busy at the moment, or I'd dig further into this.
I knew there were two patches but I have no idea which one landed... so far the plan was to only port things that have landed on the LLVM side. If there is still a bug left there, that seems worth reporting?
If the implementation shifts to the left on conversion to the wider format and back to the right on conversion to the narrower format, then the NaN payload will be the same. So I think that shifting is conformant with that rule of the standard. Otherwise hardware would be nonconformant as well. But maybe there's still some rule in the standard that LLVM apfloat violates.
Hmm, fair enough. Unfortunately, I don't think I'm going to have time to dig further into this for at least another week, but sounds good to me. Sorry for any trouble.
No trouble caused, thanks for looking into this. :)
Yes your comments were very helpful. I wouldn't have found or thought of looking for that LLVM MR for example.
This issue will be fixed by but that there are some other interesting test-cases that would not have been fixed by a more naive approach... would be great if we could get those testcases into our test suite as well :)


Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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! And nominating for compiler team prioritization.


The following code causes an ICE: As far as I can tell: Any number of characters can be inserted between and and the error will still happen. can be replaced with any unicode character and the error will still happen. No escape sequences other than cause the error. The error is reproducible on the stable or nightly compiler at outputs the following on my machine: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Godbolt says this regressed in 1.29.0.
pre-triage: this doesn't seem to be very important but would be of course nice to fix. Tagging it as .
claim Time to try an easy issue
I tried a few things and I will document what I found, so hopefully this can jumpstart some ideas: I removed the assert that was initiating the panic, and I see: Notice the OBOE on the positioning of the So, I tried different escape sequences, and got mildly confusing results Here we have an off by two error in the other direction Now, I tried the unicode escape that should (assuming I didn't misremember something) be equivalent to r: And that seems to work just fine. So, I suspect we somehow interpret escape sequences as the character they represent, but not other times. If this causes us to be offcut in the middle of a UTF-8 multibyte sequence, then we ICE, but there are cases where the will end up in the wrong spot even if we don't ICE. EDIT: a few more observations Turns out the OBOE can be seen with just old fashioned ASCII (no multi-byte utf-8 characters needed): In addition, springboarding off what found, going from 1.28.0 to.1.29.0 the ` in the error messages got a lot more specific, e.g. in 1.28.0 we see:
After a bunch of debug prints, and counting bytes, I am now convinced that the code in the function that is panicing, is not the problem. The inputs to that function are faulty. In particular the is OBO, potentially putting it in the middle of a UTF-8 sequence. I chased down the source of the bad data, and I think it is from in . The code appears to be computing the difference between how many bytes it takes in the source to represent an escape sequence vs how many the interpreted value takes. There are a number of match statements that seem to leave out. Adding them seems to fix the original problem. In addition the code for dealing with doesn't seem to take into account the varying number bytes the UTF-8 value will take. This seems to line up with what I was seeing. Also, I suspect the escape might need some tweaking for code points = 0x80 I forked and branched with what I have done so far:
unclaim I've been too distracted, and it seems has done most of the bug chasing
claim I'd like to take this up if this is still open.
It is open, go ahead :)
, FYI what is in my branch: seems to solve the r issue just fine, but does not address the u{} issue at all. My quick dirty attempts at that failed. You are welcome to leverage off of my stuff if you are taking this over. This has just been a fun distraction when I have time, but I can't reliably dedicate time to it. Also, I have not addressed unit tests at all yet. Also, I am beginning to suspect there may be a larger (yet subtle) underlying confusion somewhere else in the code about bytes vs characters. The findskips function I just updated has comments talking about characters, but data derived from what it generates is later fed into (in ) where we are dealing with bytes. So, perhaps there is a simplification if we can always deal with either just one of bytes or chars (and avoid any conversions). Or, on the other hand there may be a lot of comments that could use clarification.
I have also found that this off by n error will occur with any unicode character whose display width is non-standardized and non one. I have not yet checked the source to try to fix the issue, but I have worked with in my own code, and as it is a compiler dependency is probably the source of this problem. The largest issue with this is as far as I could find there is no standardization for the display width of these characters.
Hi, are you still working on this issue
release-assignment


https://crater- cc
Possibly accidentally injected by Would be good to find out why this is happening, so let's ping cleanup and see if we can bisect / shrink the problem down to something usable for finding a fix.
ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Failed to confirm that is the cause: Seems like it regressed prior to
For code I used:
modify labels: -E-needs-bisection
Reduced example: () Errors:
Split the macro in two parts to make it easier to follow, and removed the special lifetime : () Error: I think we can now modify labels: -E-needs-mcve
I believe that the most probable culprit is , cc
is indeed the culprit, I can reproduce the bug on
This was . Assigning for now until we have a better understanding of what's going on.
Fixed in


This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.


Sorry for the vague title. () <details<summaryRelevant errors:</summary</details<hrNote that this does not result in an ICE: Also works with shared references. <hr
Regression in – 1.44.0-nightly ( 2020-03-24) Commits:
This needs bisection ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
I suspect based on .
Assigning and removing nomination. This was .
Oops, forgot to cc
I just tried to repro in our test suite and passes... This is on unmodified master from 03:00 this morning.
Oh interesting, this only reproduces with , probably because the function is then never really compiled because it's dead code. The following also ICEs
found a fix, not sure if that is too ad-hoc though.


Especially the fact that the lines are broken up seems like a bug. () Errors: modify labels: A-diagnostics, C-bug, D-papercut, T-compiler
There are two things here have a label that has embedded newlines which causes the broken down ASCII art should find a way to reverse the order in which multiline spans are sorted, but this will require handling multiple labels. The current order is optimized for not having to tweak the label positions, but when no labels are involved, we could do much better.
So, using raw text from the program as part of our label feels like a hack. We should try to come up with another way of getting a name (and falling back to a description like "async block" or something if that doesn't work). Failing a good way of doing that, I guess we can scan the program text for newlines and only use it if there aren't any..
Agree, we should never be using snippets in labels. The change needs to happen in You have the which lets you get the and from there use an appropriate description. I think there is an open PR that adds description to all variants.


<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Note that the error is also present on stable (1.42.0). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
cc I don't think should be structurally matchable.
Note that this isn't matching on , it's matching on . There's a double pointer indirection because AtomicPtr requires T to be Sized.
References match by their pointee value, unlike raw pointers. You should use if you want to actually compare the pointers.


These include: The reasoning for all of these extensions is that they all have wide use not just in GitHub, but in many applications of Markdown.
I'm not sure if automatically creating links from bare domain names is a good idea, so if there's an option to disable that specifically I'd suggest it. The rest all seems fine to me.
Just like said for Autolinks. I'm also not sure to see the point of the task list one. However, adding strikethrough would be nice.
Tasklist would be useful for things like this: [x] Implemented thing [x] Some other implemented thing [ ] Unimplemented thing [ ] Some other unimplemented thing or possibly in the crate root [x] Webhooks [x] Websockets [ ] Websites [ ] Other
Another noteworthy extension to implement is . This would prevent the following tags from being used for safety reasons: - - - - -
We decided in not to add this. Instead rustdoc will now suggest to turn raw links into automatic links (). So I think the only thing left is adding task list parsing.


In this example: rustc throws a warning: Removing the parentheses as the message directs causes errors: It seems the warning is wrong, unless this is expected to compile <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: This also happens on nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this may apply to any binary op where the left-hand side is an expression that can be a statement without a semicolon, per: For example, adding with block expressions also reports unused parens: but removing those gets an error: As a workaround, it doesn't trigger if the operands are wrapped separately: or
claim


Notice the extra one column of indentation in front of the pipes. I presume this is unintentional because almost any other error is still printed without such extra indentation; for example: The relevant commit range is Mentioning because looks like it touches error messages vaguely along the same lines. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Could you show the output of ? The only thing I can think of is that there's a span that isn't being displayed.
<details<summary<codecargo +nightly-2020-04-20 check --message-format=json | jq</code</summarycompilefail,E0277n// here we declare the Foo trait with a bar methodntrait Foo {n fn bar(&self);n}nn// we now declare a function which takes an object implementing the Foo traitnfn somefunc<T: Foo(foo: T) {n ();n}nnfn main() {n // we now call the method with the i32 type, which doesn't implementn // the Foo traitn somefunc(5i32); // error: the trait bound is not satisfiedn}nntrait Foo {n fn bar(&self);n}nnfn somefunc<T: Foo(foo: T) {n (); // we can now use this method since i32 implements then // Foo traitn}nn// we implement the trait on the i32 typenimpl Foo for i32 {n fn bar(&self) {}n}nnfn main() {n somefunc(5i32); // ok!n}ncompilefail,E0277nfn somefunc<T(foo: T) {n println!("{:?}", foo); // error: the trait is notn // implemented for the type n}nnfn main() {n // We now call the method with the i32 type,n // which does implement the Debug trait.n somefunc(5i32);n}nnuse std::fmt;nn// Restrict the input type to types that implement Debug.nfn somefunc<T: fmt::Debug(foo: T) {n println!("{:?}", foo);n}nnfn main() {n // Calling the method is still fine, as i32 implements Debug.n somefunc(5i32);nn // This would fail to compile now:n // struct WithoutDebug;n // somefunc(WithoutDebug);n}ncompilefail,E0277n// here we declare the Foo trait with a bar methodntrait Foo {n fn bar(&self);n}nn// we now declare a function which takes an object implementing the Foo traitnfn somefunc<T: Foo(foo: T) {n ();n}nnfn main() {n // we now call the method with the i32 type, which doesn't implementn // the Foo traitn somefunc(5i32); // error: the trait bound is not satisfiedn}nntrait Foo {n fn bar(&self);n}nnfn somefunc<T: Foo(foo: T) {n (); // we can now use this method since i32 implements then // Foo traitn}nn// we implement the trait on the i32 typenimpl Foo for i32 {n fn bar(&self) {}n}nnfn main() {n somefunc(5i32); // ok!n}ncompilefail,E0277nfn somefunc<T(foo: T) {n println!("{:?}", foo); // error: the trait is notn // implemented for the type n}nnfn main() {n // We now call the method with the i32 type,n // which does implement the Debug trait.n somefunc(5i32);n}nnuse std::fmt;nn// Restrict the input type to types that implement Debug.nfn somefunc<T: fmt::Debug(foo: T) {n println!("{:?}", foo);n}nnfn main() {n // Calling the method is still fine, as i32 implements Debug.n somefunc(5i32);nn // This would fail to compile now:n // struct WithoutDebug;n // somefunc(WithoutDebug);n}n </details
I'm pretty sure it's happening because of this It is weird because that file should be accessible to in all environments now. I think we can get away with some well placed in a few places.
It maybe be nice if someone can find where this regressed ... ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Assigning as .
cargo bisect-rustc indicates that the regression is @ / PR cc
claim


<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":


Given this code (): I expected that would indicate that is not function but is. Instead, I got: A diagnostic along the lines of isn't a function, but is would be helpful. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details
I tried to resolve this issue with The error message now is Any informative error message suggestions?
Thanks for trying to address this. I'll comment on the PR you opened.


IIUC currently a trait object is always covariant in its associated types, regardless of their positions. This makes it possible to pass a non-static reference to a function expecting a static reference:
With rustc 1.0.0 ..= 1.16.0, the following error was emitted:
-- this looks plausibly similar to , but I don't know enough to be certain.
Oh wow how are these not invariant? Cc
Assigning as and removing .
Just in case, in my last action I've removed by accident and it back :).
Wait, these are supposed to be invariant. This is definitely a bug. It would be great to figure out just which nightly regressed this, maybe somebody can run cargo bisect? cleanup
Er, I guess I meant this? ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched toolchains nightly-2016-06-01 through nightly-2020-01-01 regression in nightly-2017-03-12 ... Previous error message: I used a slightly modified variant (just removed the IIRC): <details<summaryCode used</summary</details
Most likely candidate seems to be , cc
Thanks! Super useful.
After discussing a bit with this sounds more like than .
modify labels:-E-needs-bisection
Crater run from the fix (thanks to for the analysis). I was thinking about that and I realize that it's plausible that we could do variance inference on associated types and use that to inform the variance for types. It is sensible, for example, that a is covariant with respect to (that is the trait used in one of the affected examples). I'm a bit nervous about this though. For one thing, the core operations exposed by a type are clearly just its methods, but people can also project out from types (though that projection is generally considered invariant over the input types). But for another, it seems to give rise to some asymmetry and complexity around traits and variance that we have thus far avoided (and which I might prefer to continue to avoid).


despite it being usable in . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
hi there. Are you still working on this? :)
couldn't find the time to look into this deeper, sorry. Feel free to pick it up.
The target features for a particular architecture are taken from llvm in line 341. The seems to be a rust-specific target feature that is not present in llvm feature table, I think its the only one right now. I have made a basic naive pr which just prints it out since I'm hoping to get feedback for improving it


The specified method, EventsPoll::new looks like: might be related with the static mut?, but haven't tried to replicate it on a smaller example, will report back if i do so
cc Would be good to find out if this was caused by , and to find an MCVE, so: ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Imma try to bisect this, it's as good an opportunity as any to learn about it!
here's a minimal example that is self-contained and shows the issue:
Bisect shows the ICE was introduced between the nightlies of the 26th (no ICE) and the 27th (ICE is present). My pc is trying to find the particular commit still, but if that takes too long (like if it has to compile (I have no idea, this is my first time bisecting)) I'll leave it to people with beefier computers :3 That said, I think you can at least rest assured-ish because our PR was merged on the 29th (according to Github).
Minimized a bit further:
Wait, bisect just finished. :laughing: searched nightlies: from nightly-2020-04-26 to nightly-2020-04-28 regressed nightly: nightly-2020-04-27 searched commits: from to regressed commit: source code: Please give the steps for how to build your repository (platform, system dependencies, etc.) <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details
(working on the stack trace)
Use the  tool, which fetches the artifacts generated by when testing a PR. Your CPU will be way happier :D
Yaaas that's precisely what I used. It's sooooo goooooood :sparkles:
(I haven't been able to minimize since my last comment, so I think it is now minimal)
Awesome. I'll bisect again with that one. For now, I've the full backtrace taken from today's nightly to the bisect report. Do you know how I can compile using a specific rustc's commit? (I just did and used , which used today's nightly.
Now we know which PR regressed (). It's a rollup of multiple PRs, so we'll need to guess which one is the culprit using the power of deduction :D Here I'm pretty sure this has been caused by , cc
Kay, I'll leave it to Oli then. He knows way more than I do about static initialization soundness :D also, it's (apparently) his PR. I've done one last test: did bisect with your minimal counterexample, which ICE'd on the same commit. I've edited the bisection report to have your and its backtrace :3
I cannot tell if you are being facetious here, but there is the option of bisecting over the individual PR's in the rollup itself, e.g. via directly on a local rust checkout. It is unfortunate that we don't have a way to do that mechanically within itself (which would be a huge undertaking)
From some local testing, I can confirm that reverting from fixes the ICE. cc
yeah I think posted PR which essentially reverted by moving the check elsewhere (so that we still get the fix that was trying to land). Its just waiting review; I looked at it briefly but I'm not an expert on that code so I'm going to wait for to look at it.
Right, that sentence was unclear, sorry about that. I just wrote something quickly, to tell that they didn't need to bisect every PR in the rollup, that would have been a waste of time.
it's completely fine! I got your friendly tone when you posted it. The was very helpful in that regard :rainbow: :slightlysmilingface:


The first impl block with a constant is not collapsible like the second impl block with a function. !
As far as I can tell, this is the desired behaviour (not to hide associated impl constant). So unless I'm missing something, there is nothing to fix here? cc
Why are they not hidden? It felt surprising to me, as they are part of the impl block. Also because if an impl block contains both constants and methods, both the constants and the methods are hidden when the impl block is collapsed (and this I expected).
For example  contains constants, and it is collapsible, with both the constants and the methods hidden on collapse.
It seems weird to me as well but I wasn't the one enforcing it and I don't remember the reason. Let's wait to hear from first.
It seems odd to me that they're not treated equivalently.


<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Command: This code is from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: The compiler is at revision <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This , too. Cc
This happens on stable, too. Not very surprising imo since the original corresponding tickets ( , ) are only ~2 weeks old.
Those tickets report different ICEs, from what I can see. Same source code, but different assertion hit in the compiler.
Reduced: when I use an underscore binding instead of , the ICE no longer occurs:
The same ICE also triggers on this file in the miri submodule: (with --emit mir) I'm guessing it's so we need to match on the result of the and print different output depending on it
PR to fix this is up at
I'm getting a similar ice when checking with . I'm wondering if that's fixed as well.
That's a bit hard to tell based on a backtrace without line numbers. But with my patch, there is no more in that entire file, so I'd say -- probably. There's still an though, so I suspect there are still ICEs when a function pointer points to a non-function...
Btw it would be great if someone could review that PR. :) Looks like is pretty busy.
Can confirm this fixed the ICE :+1: :)


The compilation of crates fails in various ways when a certain combination of rustflags is set. With this configuration I encountered the following issues: During installation of the crate (version 0.7.5), rustc crashes with a . See the detailled error output below. When installing , the resulting binary doesn't work correctly (). Using each rustflag individually does not result in this issue. I could reproduce this both on stable and the recent nightly, and with set to either , or (without trying more). : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryError during cargo install --force sd</summary<p</p</detailsAlso possibly relevant for .
I was able to reproduce the errors by specifying (in addition to ) the s or instead of setting a . Other s (e.g. ) work fine as far as I can tell. Possibly related to ?
Possibly related to ?
This was It may be good to figure out if this happens on lld on Linux: ping cleanup or if it's just Windows thing: ping windows Removing nomination also.
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Second didn't work ... ping windows
ping windows
Hey Windows Group! This bug has been identified as a good "Windows candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
I spent some time trying to reproduce this, but wasn't able to. Can you provide more specific repro steps? Alternately, can you run under WinDbg, and show the stack trace and at the faulting address? What model CPU are you running on? Is it possible that the target features you're requesting are not available on that CPU?
I'm using a , so at least should be an exact match. AVX is definitely supported as well. I can still reproduce the with the current nightly during . Here are the exact reproduction steps, with to limit the features used: Clean the registry to rule out interference with pre-existing caches: Install : There's nothing more I did to reproduce it. However, just like with the broken installation, it seems somewhat sporadic - about 1 out of 10 times the compilation succeeds. Meta: : : : I'm also using the latest Visual Studio Build Tools, if that's relevant. I'll investigate with WinDbg later today and report back.
Does not reproduce with on 2700X with: LLVM 10 from MSYS2 modify labels: -O-windows +O-windows-msvc
Also reproduces on a different system with a for me with the same reproduction steps as above. Here is the WinDbg output and the stack trace. I used the rustc command specified in the cargo error log. <details<summaryCommand output</summary</details<details<summaryStack trace</summary</detailsAdditionally the WinDbg output and the stack trace of running a miscompiled executable: <details<summaryCommand output</summary</details<details<summaryStack trace</summary
Looks like it's reading a value from TLS and adding an offset to use as a pointer that is not 32-byte aligned (): This is happening in the call which tries to read/write a thread local: LLVM seems to believe it should be 32 byte aligned, but as far as I can tell when ntdll is allocating the TLS slots they're 16 byte aligned Sounds like a similar issue to When built with lld-link there's no alignment specified for the TLS section in the DLL: But using the default msvc linker instead results in the correct alignment: Seems like an LLD bug?
Ah, that's great that you've found what appears to be the root cause. Are you / have you opened an issue for ? Is there more support needed from Windows devs?
I filed a bug:
Finally got around to digging into LLD. Fix at
I'm not sure, does this address the case of enabled AVX-512, where alignment should be even larger (64 byte instead of 32)?
Yes, it does. When the loader (ntdll) encounters a module (exe/dll) using TLS, it looks up the TLS directory in the PE image and uses the alignment specified there for all TLS data in the module. So my patch just makes LLD save the max alignment of all .tls sections it encounters in the final binary. So that means as long as you're annotating your 's with the right alignment then it will work fine, i.e. using which is . In terms of allowed values, it's powers of 2 up to 8192 bytes with 16 as the default if unspecified.


Causes the following error: This is somewhat confusing, especially since is not a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This looks similar to what I reported in
Here we don't account for anything other than type mismatches which means that later we use the generic prefix We need to account for in the first snippet and ferry the prefix strings from there to the later (instead of what we do now).
I'd like to work on this claim
do not hesitate to reach out if you need help!
Do we need to get the correct prefix strings from the contents of or are they just ?
I believe they can be just "trait".


and all interfaces directly with the file-system should probably use rather than trying to coerce to handle these cases. (Similar issue to .)
nominating feature-complete
Accepted for backwards-compatible
My last referenced commit is a month old, but I'm still working on this issue (currently finishing up the support for Windows paths).
The issues here of dealing with filesystems that are not utf8 seem related to , at least tangentially.


When changing a pattern binding from something like to something like it's easy to end up with which yields an unhelpful syntax error message (). I don't believe it's obvious why and are valid, but is not. The same holds for bindings, of course. It would be nice if rustc's parser accepted the invalid syntax and provided one of its helpful "did you mean to write ?" error messages.
Current output:


<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --I'm trying to write an implementation of which takes an async closure and calls/awaits upon it continually. Everything appears to type check, but fails during compilation. It's probably worth metioning that implementing the same code with an async fn instead of an async closure fails type check. I'm fairly certain my reasoning about pinning and the like is incorrect in this code, but I would expect it to output a type error instead of a panic during compilation. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I realized it might be relevant that I'm using rustc nightly from :
, I'm not certain what means. Is that some kind of additional info I need to provide?
It means that we need a more minimal example that triggers the bug, since your code still depends on async-std. You don't necessarily have to provide that though, someone else can also do it.


In I noticed this surprising spelling suggestion: To me and don't seem like they would be similar enough to meet the threshold for showing such a suggestion. Can we calibrate this better for short idents? For comparison, even doesn't assume you mean . rustc 1.45.0-nightly ( 2020-05-23) Mentioning who worked on suggestions most recently in .
I debugged it a bit. is selected as the candidate because the edit distance is just 2 to . The code to fix is likely in or around . I tried some quick tricks but got ICEs and failing tests and gave up. One thing I didn't try that could perhaps work is to consider edit distance between characters of different alphabets/logogram sets as infinite, rather than 1, which is the case right now.
Thank you for investigating! Independent of what we do with different logogram sets (your suggestion sounds plausible), an edit distance of 2 for a string of length 2 should not meet the threshold for showing a suggestion, even within a single logogram set.
I think edit distance of 1 for a string of length 1 is reasonable (a lot of existing UI tests relies on it), but maybe an edit distance of 2 for a string of length 2 is not reasonable indeed. As you point out, with regular chars, the edit distance is still 2 but is not suggested. So maybe there is a simpler fix to be made for than looking at what alphabets/logogram sets characters belong to.


The feature gate for the issue is . When constructing a value using the word "default" is repeated twice. See for additional details, including alternative solutions. <!-- Include each step required to complete the feature. Typically, this is a PR implementing a feature, followed by a PR that stabilizes the feature. However for larger features an implementation could be broken up into multiple PRs. --- [X] Implement the RFC: [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [ ] Update examples in the documentation that currently use to use where it makes sense. [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilized. --- Should the language allow direct import of trait methods, this feature becomes redundant. This addition is likely to be stabilized only when we decide that direct import of trait methods is will not be supported. <!-- Include a list of all the PRs that were involved in implementing the feature. --
modify labels to +F-defaultfreefn
You call out in the description here - but why aren't or good alternatives? They work today, if the Default trait is in scope, and it is in the prelude.
is convenient when the compiler can not infer the type. But when it can, because redundant. Here is a discussion where this was mentioned as well:
FWIW I think it is often still good style to say to communicate to the human reader the type being constructed away, which can be declared very far away in the code (even in a different file).
I do no think this change takes away that and in certain cases you have to say . The change allows you to say in cases where you are currently saying .
happens a lot in struct displays, with being as redundant as .
A bit late to the party, but why not just a in the prelude instead ? That's less code to inline for the optimizer.
I am not sure I understand exactly what are you suggesting. But if the motivation described in the issues summary is not enough, please, read the discussion in
Is there a reason why this new free function isn't in the prelude when the feature is used?
Any additions to the prelude need to go through their own RFC. The bar is quite high, to say the least.
What's the status of this feature? I've found that The Book should be updated (Appendix C - Derivable Traits) but not really sure how to proceed.
One thing that I think is worth calling out is that this is putting a free function inside the module. So in order to avoid the stutter complaint of using , it sounds like you'd have to add a somewhere in order to use . So that stutter is still there in some sense and you have to write an import for it. Granted, this gets rid of the stutter at the call site. I also want to bring up the alternative. In particular, while it of course is not a replacement to avoid the stutter in all cases, I do think it is generally better to use in lieu of either a free function or . So to me, this on its own reduces the incidence of having to write a stuttering call, and thus also reduces the importance of adding things to std that allow one to avoid the stutter. As a more general point, to be honest, I'm not a huge fan of dumping aliases to things into std. I think it invites questions like, "Wait, what's the difference between the free function and ?" And it kind of just becomes another thing that folks need to learn, and another thing where some code will undoubtedly be using and other code will just be using the free function, which are expressed as two different things in std's API. More generally, do we have other aliases like this in std already? I know we have things like and , but we've deprecated the former. I wonder if it makes more sense to talk about "let's add aliases to std" as a more general policy question. In , wrote: To be honest, this seems infrequent enough where it might be reasonable to just define an internal helper function.
Isn't the plan to have in the prelude ?
I'm not aware of that plan. Could you please link to it?
You're right my bad. It was just a reminiscence of .
We discussed this in today's meeting. The general sentiment was: We'd like to make sure that can work even in const contexts. Ping what's the status of being able to say, for a free function like , that it's if and only if there's a const impl of ? We'd like to know if that'd be possible, even if it's nightly-only. And if it is, we'd like to use that for . Assuming that's possible, those of us in the meeting were generally in favor of having , and adding it to the prelude.
it's possible and already works (not yet in bootstrap libcore though): But we are not yet confident in whether we can safely (in the stability sense) stabilize a function that uses this feature without also stabilizing something of that feature at the same time.
Are we working on the assumption that something like won't be available in the future? Or is it more that we're okay with the potential for a little duplication down the road?
If one day it becomes possible to a trait method, then I think we'd still want to export the free function , we'd just turn it into a . So I don't see any reason we should wait for that. That looks great. It'd be helpful to know if we could stabilize a function using and without first stabilizing those two features themselves, but even if that's not the case, the confirmation that this can work is good enough for me to think we should stabilize this. I'm starting an FCP to get consensus on providing the free function , and exporting it from the prelude. (This consensus does not mean we have to stabilize it immediately; we can work with const-eval to figure out if it's possible to export something based on and , or if we need to wait for those features. For now, I'd just like to confirm consensus for the general plan of providing the function and the prelude re-export.) merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [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.
Oh sure, I just wanted to make sure that this was desired even in that situation. Personally I'm :+1: regardless.
This is still fairly early in the experimental stage, so I don't think we should stabilize anything using it just yet.
The primary blocker from our meeting was whether it would be possible, not necessarily doing so right away.
I think my general lean is in line with comment and comment . I'm hesitant to add alternative ways to invoke the same functionality without strong justification, and I don't believe that "reducing visual noise" is a sufficiently strong justification in this case. Also, given indicating that it would likely be easy to add support for to the language and the fact that as far as I can tell we've not ruled that out, other than that nobody has attempted it, I would prefer seeing an attempt to implement support for importing trait methods in general to stabizing this API.
since its been a month and a half and we're still only at 2/6 in favor of merging, I'm going to go ahead and close the FCP, though I will not be starting a new FCP to close the tracking issue because I still think we should work to resolve this issue through trait method imports or at least rule that out as a possibility. cancel
proposal cancelled.
Related discussion on Internals (some people here are proposing a lint to recommend over , to clear up some confusion related to the functional update syntax, which would make an anti-pattern right out of the gate):
Bevy 0.7 introduced a similar function in their own prelude: , bevyengine/bevy.
Just wanted to say that I very much enjoy using bevy's function. It's fairly common in struct initialisation, so it does make a tangible difference to the enjoyment of rust have such a shorthand.
There are tons of other traits that contains a single method, for example . Do we want to create free functions for all the traits?
No, just this one. It's more readable than .. Default::default()
I have included in my utils. You can write: and get correct type suggestions on the fly. I like this style personally.
There is really no need for this extra function, just simply add to the prelude
Trait methods can't be imported directly
This came up with Bevy uses of a free function: The lint : "function cannot return without recursing" is not raised by using Does not raise a warning: Raises a warning: This is
There is one thing that I noticed: When I initialize a struct I often start with and then jump to the definition of (using rust-analyzer) to see what the defaults are and to decide which fields I want to change. That's possible with and , but that's not possible with the free function (e.g. the one from bevy, it just jumps to definition inside the bevy crate). That's very unfortunate because from a visual perspective I would prefer .
That’s ok, IDEs will get smarter. It’s not a reason to not do it. On Fri, 23 Jun 2023 at 19:12, Jakob Schikowski
We discussed this in the libs-api meeting today. We would prefer to see a language feature to import the method directly. The language team seems to be open to this, but someone needs to write up a language proposal and drive the design of this feature. Since we are unlikely to stabilize the function as-is, we would like to remove it from the standard library. fcp close
Team member has proposed to close 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.
I am not familiar with the removal process, but if it is just another issue with, essentially, a revert of the original change, I can do that. Though, if someone happens to have a link to an example, I would appreciate it. Was the consensus to remove it now, or after support for importing trait methods is to the language? If someone wants to mentor me in writing a language proposal, I could probably do that as well. As I have not participated in the language processes in the past, it is not very likely I would manage it by myself.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to close, 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.
So, the feature has been removed in favor of a language change, but without actually formally proposing the language change? Disappointing.
TL;DR
maybe we can have a language feature (alias) specifically for when creating structs with to support which expands to . This makes sense because the language already has this syntax is places such as pattern matching
has there been any followup RFC/tracking issue for an eventual syntax?
For what it's worth, is an open issue on this, maybe we could have some discussion there to move things forward.


<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --reduced from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --repo @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Its a regression from but fortunately the fix is relatively easy. I'll provide a PR soon,


I was writing some code that does some x86 page table configuration, but then I noticed that Rust compiler started to panic with this code: And I did realize that I cannot use in since has attribute. If I rewrite the above code without crate: (Note that this is basically same thing as 's struct) This compiler error is displayed, which is normal: And here's output from (In this case, I'm trying to compile the first code): Looking at the backtrace, there's function and : While there's no line number(since the compiler is installed using ), thankfully there are only two calls to inside . And it seems like the first one is panicking since normal output has nothing more than , but I might be wrong. I ran about five minutes ago before submitting this issue, but result was the same. BTW: I initially found this bug in Clippy, but then I noticed that Rustc was doing the same thing.
Assigning [as discussed as part of the Prioritization WG procedure][link]. [link]: https://rust-(in.20some.20cases).20when.20repr(al
Would you please try this again for us?
The second one is one that does not panic rustc(The code that panics rustc is the first one). It is very similar to the first one except that it does not use external crate, and compiling it shows the error I was expecting. Also, the second code was one of my attempts to reproduce the same panic without external crate, but for some reason, it didn't panic the compiler. Only the first code does.


We fail to parse this (admittedly questionable) code as of beta: This broke one repository (not crate) in the beta crater run: https://crater-
cc I personally suspect that we may want to ask T-lang if we're good accepting this as expected breakage. Alternatively I guess we can adjust the shebang detection to not require a non-empty shebang.
Assigning .
For reference, here's the code responsible for parsing shebang in Linux kernel - (Fully whitespace (including empty) line isn't considered a shebang.)
I am inclined to close as won't fix; let's cc as the author of that repository as well. I'm going to go ahead and nominate this so that we can get a :+1: (or not) at the T-compiler meeting confirming won't fix status.
I made a fix in , which also has a benefit of simplifying the rules slightly.
Thanks guys, was more of a spelling mistake/leftover from previous version than unclear explanation of how to use shebang with rust as your previous explanation on how to use it worked fine in something else I was playing around with. But thank you very much for letting me know. Sent with Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐


Const generics and release mode and Hc128Rng::seedfromu64 and rustc 1.45.0-nightly ( 2020-05-29) or later cause cc linking error. To avoid the error, do any of: use rustc 1.45.0-nightly ( 2020-05-14) or earlier remove the remove the line compile in debug mode I'm guessing that Hc128Rng::seedfrom_u64 is not the only thing that will trigger this, but I have not been able to find any other examples.
I reduced it. works, but does not work. In both release and debug, it yields approximate the same error as before on: But compiles successfully on:
This fails with , but not .
This appears to be working now. I'll add a test.
and I were unable to reproduce an error with the examples here, but they still fail on extended CI (though not with the original error here). The PR is We'll have to revisit this one.
Note that on latest nightly, I am still encountering this issue. (Any time I use the crate and with , I trigger this.) Error:
Sorry to keep bumping. I continue to encounter this issue when I attempt to use with on latest nightly. <details<summaryCode</summary</details<details<summaryError</summary</details<details<summaryrustc --version --verbose</summary</details
Reliably reproduces for me using latest code. modify labels: -E-needs-mcve +E-needs-test
I encountered a different trigger for what I am guessing is the same underlying bug. Error message is ~identical. To work around, do one of: Have return an array instead of a . Replace with . rustc --version --verbose:
Different trigger. Allocating with causes an ICE, but simple works.
Manifest for installing rust and build-essentials on ubuntu 20.04.03 rustup self uninstall apt-get update sudo add-apt-repository "deb $(lsb_release -sc) main universe" apt-get -u dist-upgrade apt install aptitude sudo aptitude install libc6=2.31-0ubuntu9 sudo aptitude install build-essential apt-get update curl --proto '=https' --tlsv1.2 -sSf | sh -s -- --default-toolchain none -y rustup toolchain install nightly --allow-downgrade --profile minimal --component clippy rustup default stable rustup update nightly rustup update stable rustup target add wasm32-unknown-unknown --toolchain nightly sudo apt install -y cmake pkg-config libssl-dev git gcc build-essential clang libclang-dev rustc --version source $ [][1] #ArmanRiazi.Blockchain [1]:
still causes a linker error but passes with symbol mangling: I assume we end up mangling an unevaluated constant somewhere with ?


compiles fine. Constructing a literal doesn't work, listing two s gives , giving only one gives , with an empty list of missing fields.


... as documented. The problem: this line from the documentation: The weak count as reported by is 0 when the strong count is 0, even if there are still outstanding weak references: The combination of these two means that getting a pointer from is not enough to guarantee that it's safe to use in . Instead, you have to know that (if it originated from a strong reference) you still have an outstanding strong reference to the allocation, because otherwise the (exposed) weak count is 0, and thus calling is "documented UB". To properly document when this is intuitively allowed (i.e. it's allowed because I got the pointer from and have called more than , so there are still "unowned" raw weak references to claim) (which lines up with what the implementation allows), we need to expose (probably docs only) the fact that there is still being a weak reference count behind the hood being tracked until all of the s have been dropped. This will probably also require guaranteeing that doesn't drop its weak reference and become dangling "early" (e.g. note that failed, decrement the (real) weak count (potentially deallocating the place), and become a dangling weak via internal mutability) and that on a "zombie" increments the (real) weak count and creates a new "zombie" , not a dangling .
(I don't know if C-bug is the correct label for a "documentation bug," but it was the closest template to correct.)
I guess that means the internal weak count rather than the user-visible .
That's obviously the intent and what the implementation shows is the case, but when considering documented properties of an API, you have to only consider the documented API. A correct resolution to the issue would be to adjust the documentation to clarify that the weak count is referring to the hidden internal weak count that's not exposed (except conceptually for the safety of /). cc who wrote these methods and docs
Yes, it's meant as the actual number of weak pointers pointing there (including the ones „frozen“ to raw pointers), not what some method returns (if it's currently in the form of the raw pointer, you really can't even call the method, so I'm not sure if that part can even apply). I agree it could probably be documented better. I'd try to fix the docs, but considering I've already updated them like 3 times during the review and they still haven't ended up entirely correct, I'll probably ask if you want to give it a go first, as obviously the docs aren't my strong ability :-).
The main thing this requires is actually specifying how the "internal" weak count works, and guarnateeing that we don't do "clever" things with converting "zombie "s into dangling s. I really don't know the best way to do this or even where to do this, since it basically only impacts how and when is allowed to be called.
:thinking: Maybe just getting rid of the „weak count“ term altogether and try to describe it in a way that the pointer preserves the ownership of the , or that it's an alternative form of and it can be turned back if it still has the ownership. Or maybe just point out that the „weak count“ is meant in its natural meaning, not referring to the method.
Ok, looking into this, how about wording like this? On the intoraw: And on the : Do you think this would be better?
Yeah, I think that wording captures the semantics properly.
Thanks. I'll get around to submitting the changes some time soonish.


This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .


<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --The bug exists in the beta, nightly, and stable build channels. : The error and the backtrace provided are produced by the stable build. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
reduced: Edit: you can actually omit the enum declaration and it still crashes :thinking: `
oh, sorry, I've already got a fix. I'll post it soon. Though it may not be the best one.
Great! You should tweak not losing diags. For further reference, you could do when you work on an issue to avoid conflicts.
okay, thanks. Better late than never… claim
This is caused by , I believe. 1.44 emits errors w/o ICE'ing but 1.45 hits it. godbolt (1.44): godbolt (1.45):
Let's keep this open to track stable/beta backports.
The reference suggested this to be possible, which is how I came to suggest it to OP. We wanted to avoid naming them to not suggest any specific content.
here is another one: (assuming related)
The stable fix is reverted, and the nightly one is also but introduced another fix. I keep this open when that PR is beta-nominated, just in case.
We don't backport the fix in favor of this comment: So I'm just going to close this as fixed.


I tried to compile this code: I expected the code to compile Instead, it failed to compile with this lifetime error: If I change the function in these ways it compiles. This compiles successfully on Stable Rust 1.45.0 back to 1.26.0 (when lifetimes were stabilized) This fails to compile on these versions(haven't tried previous ones in the same channels): 1.46.0-beta.2 (2020-07-23 ) 1.47.0-nightly (2020-07-28 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Let’s find the culprit for this. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Assigning as and removing .
Regressed in which is a roll-up, likely
cc in case you want to fix this is a follow-up of
The explicit lifetimes are edit: the lt of doesn't matter
assigning to but they will probably need to delegate as there time is limited in near future.
Will look into this today. claim
This code compiles in Rust 1.17 but not in Rust 1.18+: unifies DerefMut/IndexMut to use the "fix-up" path originally used when performing method calls, so it broadens the bug to assignments as well.
Okay, this is an issue near convertplaceoptomutable. Just re-infer the index type and re-do the coercion is sufficient to fix the regionck failure (). However I am not sure why the existing code does not work. This piece of code is last touched in . cc do you have any clue why the existing approach does not work well with regionck?
Hmm.. I would not have expected that code to have to change, since the failure seems to try to make the anonymous lifetime on in the method match , which it should not. I think your patch is sound, but touching the "wrong" thing. Basically now we are creating new lifetimes for the index, when I would have thought that the container type's reference's lifetime needs adjustment. So looking at , I'm guessing is taking the wrong region and should instead invent a new one?
This issue is not related to anonymous lifetime actually, if you spell out the lifetime explicitly it's still the same. The root cause has been identified and that line actually is the culprit, a detailed analysis can be found in .
I a couple of examples of workarounds that allowed the function to compile, with the same signature.


<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --It is very finicky to reproduce. is as minimal as I could get without significantly changing the structure of the macro or having other errors cover it up. Apologies for the mess! Updated 2020-08-04: I got it down to a total of only 130 lines of code. Please review the improved output below. Instructions: the project: The ICE was triggered by change in , where I simply changed the scoping on a nested inner generated by a macro from public to private. : On stable, errors regarding scoping are printed (this error is repeated many times): On nightly, a backtrace occurs. <details<summary<strongBacktrace</strong</summary<p</p</details<details<summary<strongcargo expand with pub struct (updated 2020-08-04)</strong</summary<p</p</details
I have reduced this reproducer from about 500 lines of code total to 130 lines total. There are more syntax errors in it now, but the panic still triggers before them. Most of the other things I could change create an error that short circuits the compiler before the panic could trigger. EDIT: I also just updated the backtrace, because I didn't ask for a backtrace last time.
Let's get a MCVE and bisect the culprit PR. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Minimized:
is the likely cause.
Assigning as and removing .


<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --The following code compiles just fine but when trying to run on it I get the error described below <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Making this even more strange, this does not panic with instead.
<details<summaryBacktrace</summary</detailsRustdoc code:
The main function is not necessary, it also crashes on
Yeah this one is beyond me, I have no idea why this is breaking.
This never worked with ; on it says the feature isn't recognized and on it crashes.
Huh, I built that last code snippet in the Rust Playground and it compiled fine:
yes, it only crashes with rustdoc, which isn't available on the playground.
Oops, I missed that part. Sorry about that!
Feel free to ping me on all issues related to const generics claim
Thanks for fixing this!


to in the implementation of . This is correct for simple types like , but when 's implementation accesses borrowed data, this might lead to accessing already dropped data:
and also use in their impl. But I can't reproduce this problem with either of those instead of . Not sure why only seems to have this problem. Edit: Probably because contains in a , which doesn't implement . Adding a should fix that. (Testing that now.)
I think the problem is that puts no lifetime constraint on , so you can write any arbitrarily short-lived to the cell. It would have to at least outlive the reference.
Cc likely this affects upstream once_cell as well?
That's also the case for a Vec: This compiles fine. (As it should.) Replacing with from above here does give an error though, like it should. Looks like dropck does understand that 's is going to drop s. Looks like is what made that work properly for Vec and Box:
Oh, yeah, you're right
Doesn't look like it: the crate uses instead of :


Between nightly-2020-09-05 and nightly-2020-09-06, libproc_macro stopped preserving the jointness of a trailing joint punctuation token in a TokenStream (likely ; This breaks some real-world code such as the following, though only with old versions of some libraries as far as I have found. I don't know which behavior above is correct but I would like it to be intentionally decided so that we know what behavior to implement in proc-macro2. fails to compile since nightly-2020-09-06:
This has also broken 's webrender-wrench, which relied on this behavior in one of the dependencies. -- do you think a revert makes sense perhaps? Is there a patch expected soon-ish?
Marking this as P-critical based on the


<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for saturating operations. The feature gate for the issue is . <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implement the proposal: [x] FCP [x] Stabilization PR: <!-- Include any open questions that need to be answered before the feature can be stabilised. --
Just needed when dealing with time intervals. Also, unresloved questions seem to be from another tracking issue?
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] [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.
:bell: This is now entering its final comment period, as per the . :bell:
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.
I am very happy to see this stabilized. One thing I wanted to discuss is the documentation: it currently mentions two associated constants: But both are currently unstable. Should they be stabilized at the same time? Or should the documentation updated? It seems a bit weird that the documentation for stable methods is mentioning unstable features and therefore the code examples cannot be executed and verified on stable. This is really a newbie question, I don't know what is the correct approach here. I am pretty sure such circumstances have happened before? Also, once that question is resolved, I would be very glad to do the stabilization PR. It's my first tracking issue and it would kind of be a personal accomplishment :+1:
is being stabilized at the same time: still needs to be stabilized. it's suggested that that constant should probably not be part of the same tracking issue as the other constants there (, etc.). Feel free to send a PR that stabilizes just , then we can do an FCP on that PR and we'll remove it from that tracking issue. Feel free to make that PR without waiting for . In this specific case I don't think it's a problem if this gets stabilized while the docs still refer to something unstable. is pretty clear and uncontroversial. Even if it's unstable, it's still the best way we have to refer to the maximum value of a . (And it'll probably be stable anyway in ~two weeks.)


The code below does not compile on new versions of (bisect below) searched nightlies: from nightly-2020-09-11 to nightly-2020-09-12 regressed nightly: nightly-2020-09-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
cc
We probably just need to and likewise for Sync. Conceptually it's no different to a &mut T, so that should be reasonable.
can we assign the issue to you given that you've already provided a PR?
I'm going to self-assign, I don't expect to hit any roadblocks with the PR though, it's already bors-ready.


The match remains exhaustive with highlighted pattern removed, but it does not produce any warnings: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I know where the problem comes from: this bit of code tries to handle unreachable sub-or-patterns diagnostics, but it's a bit of a hack. What remains is to come up with a better solution. claim


Seaching for in the docs only surfaces . The solution seems to link from to so people can read more. However I'm not sure how to create a link between these since they live in separate crates. What's the right way to go about this? edit: if someone wants to pick this up, please do. This is probably a "good first issue" once we figure out how to link between the two. ! -- this is how I eventually learned about ; ideally it'd be easier to find. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
These can't use intra-doc links, so you need to use relative links. I think would work.
Mentoring instructions: At add a link to .
Could I take this on as my first issue?
please do!
Feel free to use the command to assign the issue to yourself and show you're working on it
claim
yay; thanks for landing this


The uses a heuristic based on the worst-case number of comparisons to determine between two strategies: , equivalent to pushing all elements of the other heap. the vector of the other heap and rebuilding the heap from scratch. I've done some benchmarking, and it turns out that method 1 (based on ) is always faster for two heaps based on randomly shuffled data – on the computers I've tested it on, anyway. I've included images of below: first the current strategy, then the strategy (method 1). In the benchmarks, two heaps are merged, one containing the number of elements on the x-axis, the other containing 100,000 minus that number (for the rightmost data points both heaps are equal in size). The red line (sometimes hiding behind the green one) is in both images that corresponding to , the other lines are not relevant to this issue (they aren't standard library types). ! ! From the jump in performance in the first graph, you can clearly see when the switch between the two approaches happens. Graphs are similar for smaller heaps, I didn't test larger ones. It's possible method 2 is faster under other circumstances (maybe if one of the heaps contains mostly very small/large elements?), especially if both heaps are (almost) equal in size. However, I think the benchmark is more close to the "average" real-world use case than such a case would be (I'd be happy to be proven wrong about this, though). <details<summarySimplification of the benchmark that only runs the parts relevant for this issue</summary</details
The comment suggests that the rebuild strategy is more efficient if at least one of the following is true: comparisons are very expensive the appended heap is much much larger than self but self must still contain a handful of elements so that the logarithm is 2 You can see how the slope of the append method is lower, so its advantage would show if you extended your benchmark by an order of magnitude. If you used a more expensive comparison function it would probably show earlier too.
The code for swaps the heaps if is larger than , so the appended heap is always smaller than or equal to the self heap. Indeed, the slope of the rebuild method is smaller, but I can't find conditions where that is outweighed by the higher base cost of the method. To simulate more expensive comparisons I've made a benchmark where each comparison involves some global atomic operations. Below that I've included a benchmark with ten times the number of items in the heaps in total (an order of magnitude more than that makes the benchmark very slow). The trends remain similar. ! ! The original implementation ( and ) seems to base its choice for heuristic mostly on the expectation it is a reasonable heuristic. However, I think reasoning from the worst-case scenario (O(n log(m))) is pessimistic for the method as a large number of es require only one or two comparisons (instead of log(m)) before ending up in the bottom two layers (that contain 75% of all items in the end). Maybe for even larger heaps the method actually is advantageous again, but I'm not sure how to determine a heuristic for that. <details<summaryChanged code for atomic benchmark</summary</details
Ah, I missed that. That indeed limits the opportunities to realize its advantage. The x-axis still says 50k though? First we would need a benchmark demonstrating that advantage anyway.
Only for the first image, that one has the same number of elements as before but a more expansive comparison implementation. The x-axis of the second image goes up to 500k, that one has normal "cheap" integer comparison but a larger number of items in the heaps. Certainly.
Naively, when I look at the graphs in the OP what I see isn't that extend is always going to be better -- the slopes seem to be clearly different, though two graphs with different scales and extra lines makes that comparison harder than it ought to be -- but that the current heuristic is doing a bad job of accounting for constant factors when picking the switchover point. Why isn't the answer here just use a number other than two in the heuristic?
Here's the two lines from a different measurement of the same benchmark in the same graph. It has a weird jump between and (artifact?), that's why included the more messy pictures initially. ! The slopes are indeed very different, and extrapolating them would lead to a crossover point. However, this crossover point can never actually be reached because you can't extrapolate beyond the rightmost data point. The benchmark is set up such that two heaps are merged, one containing x elements and the other 100,000 - x. The rightmost data point at x = 50,000 corresponds to merging two equally sized heaps. The data point that would be to the right of that (x = 52,500) would give the same result as the data point to the left (x = 47,500) because both involve merging a heap of 47,500 and 52,500 elements and the heaps are swapped in one of them to make sure the smaller heap is append to the larger one. In other words, beyond the rightmost data point the slopes change (become negative) and the data would mirror the data to the left of that point (which is why I didn't include it). The crossover point is thus only reachable (in this benchmark) if you'd remove the swap-optimization (theoretically I mean, practically that would worsen performance, or course). The TLDR is that it appears the number would have to be such that the condition always evaluates to . On another note, I've now also benchmarked merging very large heaps (100 million elements after merge), and is always more favorable there as well. !
Just tried the benchmark with changes from PR and scores significantly better. The heuristic could still be improved though. !
Thanks for the update to remind me about this One thing that I'd missed last time: ing from the contents of a can never hit the worst case (needing to bubble to the root every time), since it's being extended by something that's in roughly-descending order. Do you want to wait on before looking at more?
I think for now it would be better to wait and/or work towards a better heuristic (even though can perform better, it's still up to 25% slower when the second heap is much smaller). PS/Disclaimer: I'm the author of and not a reviewer, so I may be a little biased, however the benchmarks should speak for themself. Would be nice someone else could confirm my claims
Nice performance improvements in , just a pity it makes determining the switchover heuristic more difficult ;). I ran the benchmark again with and on my machine it also improves 's performance enough that it's the faster method when merging larger heaps. I guess it doesn't make much sense to merge as-is because of that. I'll have a look if I can determine a better heuristic based on the improved performance.
In order to determine the new switchover point, I ran some benchmarks for heaps of different lengths. For a constant total heap length (heap length after the operation), the execution time has an (approximately) linear relationship with the length of the smaller heap. This means the data can be fitted with a least-squares linear fit: ! The blue line is the rebuild strategy, and purple the extend strategy. The green vertical line indicates the intersection of the fitted lines, i.e. where the switchover between strategies should ideally be. The red vertical line indicates the switchover point using the current heuristic. The fits for all the different other lengths can be found in the collapsible section at the end of this comment. I've plotted the location of the ideal switchover point as a function of the total heap length (the current heuristic is not a smooth curve because it uses a fast but inexact log2): ! I think a couple points are noteworthy: The current heuristic is quite close to the ideal point for smaller heaps. The switchover point stays roughly constant (when considered as a percentage as in the graph above) for heap lengths 1000 to . For larger heaps, the ideal switchover point rises again, which is not reflected in the current heuristic. I am not sure how to best model a heuristic for larger heaps, especially because for the power-of-2 heaps show it drops again for the two largest heaps. However, I think it should be fairly straightforward to improve the current heuristic by setting a lower bound on the switchover point: This results in the green curve in the graph above. It is closer to the ideal switchover point in all cases, but for larger heaps it is still suboptimal. I'd love to hear ideas on how to improve the heuristic further for larger heaps. <details<summaryImages of all fits</summaryIn all graphs, blue is the rebuild strategy and purple the extend strategy. The dots indicate raw data points and the line is a least-squares linear fit. The green vertical line indicates the intersection of the fitted lines, i.e. where the switchover between strategies should ideally be. The red vertical line indicates the current switchover point. ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! </details


<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: Compiler doesn't generate any warnings Instead, this happened: Rustc says that is unused, even though it is declared as in asm. Adding arrows () fixes it <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Interesting bug! I used to determine that this bug has been around . and doing some debugging, I found that for all live nodes in , is never marked as being used in the RWU table. It only gets marked as read/written. , this is part of the information used to determine that is unused. That doesn't really make much sense though- does seem to fit the case where a variable is used as both an input and an output to some arbitrary assembly instruction. I'll go ahead and claim this. I have a solution in mind, just going to ask around zulip first before putting out a PR. claim


Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rustfmt 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!
Hi can you please the command to replicate this bug? Thanks
with set in
won't be able to get to this myself in the next few days. To fix this we probably have to compile it with , find the place where we call and put a before that
Hi the error occurred where we just erasing regions by simply doing this (tcx.eraseregions(&traitref)) and provided assertion with (tcx.normalizeerasingregions(paramenv, traitref)). Is this scenario correct? Just want to confirm as you already mentioned to put a tcx.normalizeerasingregions. Thanks
yes, so we do not want to use in as that can be a bit costly but instead normalize eagerly before then. To detect cases where we are still using unnormalized values a debug assert there. If we look at the backtrace we can find out where the is coming from and normalize it there
okay, thanks for the update.
Hi as you mentioned can you please elaborate it please? As I can see the Instace::resolve in but don't get you point to put tcx.normalizeerasing_regions. Thanks
Can you post the resulting backtrace using ?
here it is:
So I think that the easiest fix is to add before this call. I am however surprised that isn't actually normalized here. cc do we want to instead normalize this in mir building?


dilbert-feed is ICEing on beta with error: internal compiler error: could not fully normalize https://crater-
Full error log:
I'll bisect this one
Doesn't happen on the latest commit by on .
I can still reproduce with :
It may just be an instance of me not doing something right, I used:
gives me searched toolchains through regression in So this would have regressed in , cc
The PR did introduce some additional uses of inside specialized implementations. itself it is a stable function so I am not aware of any restrictions on its use. Perhaps this is some interaction with specialization?
Both sites where it is used are of this pattern: They're just there as hints to to let llvm DCE the dropinplace earlier. So if needed removing them should be safe.
Assigning as and removing .
Assigning myself to revert on beta (and potentially nightly, depending on if we can get a fix soon).
Do we know if removing fixes the problem? We also could use an MVCE, right?
MCVE would be good, yes.
I hit (what seems like) this ICE with in a pretty small experiment, would it be useful to try reducing that?
Yes, it would be -- even if it's a separate issue we can just open that :) MCVE is always useful.
ping cleanup This issue needs an MVCE
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Here's my nightly MCVE: Interestingly, it goes away when putting all of the code into one crate. <details<summaryFull error message (with <codeRUST_BACKTRACE=1</code):</summary</details
Hmm, this may be a distinct problem, but maybe not. Hard to tell.
I'm re-adding the MCVE label because the crate on beta does not require features, so we should be able to come up with a non-nightly MCVE. (Also, it would be good to have a single-crate MCVE, but perhaps the multicrate nature is critical here?)
cc , which may be the same underlying bug (but pre-existing?)
hey , did you manage to land a revert of on beta (and nightly?)?
If reverting the PR proves difficult more targeted options would be either removing the use of or only removing / stubbing while leaving the rest of the machinery unchanged. But the former may be insufficient since it also uses similar methods such as and .
Do we think given that we're likely to fix the regression here at least in and we should close this bug? Neither of those PRs fixes the underlying issue (whatever it is) since the lack of normalization is almost certainly still present, but we also don't have (AFAIK) a good test case here for the bug.
I expect so.


When panicking, every line of stack traces contain instead of a code location. E.g. I'm on rustc 1.47.0 and FreeBSD 12.1: Possible duplicate of I've tried mounting /proc but it didn't fix the problem.
Can you test on old Rust stable version to see if this is a regression ? Edit: This is an expected regression
It worked on 1.46.0:
Do you know if there is a build farm for freebsd like gcc build farm ? Because we could fo find from which PR caused the regression. Otherwise, since freebsd is a tier-2 target, not everyone could investigate it. modify labels: T-compiler
Error: Label P-medium can only be set by Rust team members Please let know if you're having trouble with this bot.
Assigning as discussed as part of the and removing .) and removing .
For what it's worth, this problem occurs on iOS (x86_64-apple-ios) builds too: 1.47.0: 1.46.0:
Likely caused by . (switching from libbacktrace to gimli) It seems that is not implemented for FreeBSD: I think this means that it can't find the debuginfo for any libraries and the current executable.
For iOS it may or may not work to extend the condition at to include iOS too.
You're right! I submitted a PR to fix it for iOS. Thanks a lot!
You might want to file another PR to update backtrace-rs submodule in this repo.
Thanks!
It looks like , so I think we could just extend to cover FreeBSD
Hi, could you ( or ) use rustup- toolchain-install-master to install and try this build: for freebsd?
Looks good!
backtrace-rs issue: backtrace-rs PR for issue:
What's left to do here? Would a PR that updates the submodule for library/backtrace be sufficient?


The code that truncates long lines doesn't take (hard) tabs into account, so the lines printed are off. Example code: Gives the following error: If you use four spaces instead of each tab it works as expected: cc and cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I thought we were already accounting for tabs, but looking we rely on which considers to not have a width, which we then assume to be 1.
claim