Const generic defaults are being stabilized, <!-- 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</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems to also happen with closures:
I got a fix for this one I think. claim
even worse, this compiles on beta but shouldn't
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
I think this needs to remain open until the fix is beta-backported :thinking: not 100% sure on procedure here
You might be correct. At least that's what happened last time one of my PRs was backport nominated (), though I'm not sure if that was due to that being a regression on stable. Regardless, thanks for reopening this.
that's my understading, too. I /think/ issues that are pending a beta/stable backport (like this one) will stay open until the corresponding backport PR has landed. The {stable,beta}-backport procedure is detailed but this detail is not explicited (I'll see if I can fix that to be more clear). For completeness, backports are discussed every Thursday during the compiler team weekly meeting (). Anyway, thanks a lot for fixing this issue and also to + for reporting and debugging :)
Copied from Zulip: Question/thought: Is this a case where tracking bound vars got in the way? Or did it actually help uncover a potential bug?
Not sure what you mean. The bug was that we were just not doing lifetime name resolution at all on const generic defaults. Like this code compiles on beta: edit: ohhh, you mean ? Yeah I think in this case it helped uncover the bug, because of the fact it ICEd and showed us we weren't resolving the closure default.
I guess this example shows that this did help us uncover a bug, but kind of indirectly: This just didn't uncover a case where "lost" bound vars.
this is now fixed on beta


Context: - the test had to be disabled there to get a fix in With running the UI tests targeting wasm32 causes this failure with LLVM asserts enabled: With LLVM asserts disabled it produces invalid wasm bytecode: Manually executing the rustc command printed by the UI test and adding generates the following IR . Running that through (built by bootstrap) also produces invalid bytecode (checked with ). Tested on base commit + PR (currently ) ping llvm
Hey LLVM ICE-breakers! This bug has been identified as a good "LLVM 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
Quick observations: The failing assert: Looking at the , it seems like the only way this assert could fail is if the value is too large to fit in the specified number of bytes. There are two calls to , and one of them has a check for out-of-range values already, so it's probably in .
No longer blocks the PR, it now disables the test on wasm32 instead.
Upstream issue:


<!-- 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: A helpful error message pointing to the end of the block. Instead, this happened: An error message with a wrong span: <!-- 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. --: cc labels: +T-compiler +F-let-else +requires-nightly +A-diagnostics
Let's try that again... label +T-compiler +F-let-else +requires-nightly +A-diagnostics
FTR this is the error for the equivalent:
I wonder how is affecting this, as this seems to be a bug in the desugaring and that PR changes it. what is the error output with your PR applied? Does it fix the issue? If so, maybe adding a test to your PR would be helpful.
I meant caused by the desugaring, not in the desugaring.
It won't fix it. This needs a bit of work I think, to push the error further inside the if-let-else branch, so the span marked is the implicit return expression or lack thereof, which is (in the source code) further down in the block.
Hmm if you move the println into the , it gives a similar error to the one emitted by : gives
That's because you have only now reproduced the actual desugaring.


While checking whether the can be ported from typenum to nightly with , I hit this warning. I am not sure whether it's a false positive or whether the behavior I want is meant to be disallowed, but I think it should be allowed when enabling . I've reduced the code though I left some stuff to show why it would be useful. Originally posted by in
is emitted if we successfully evaluate an anonymous constant with generic const arguments. Anonymous constants currently inherit all of their parents generics, so for the constant has both and in scope, even though it only uses . This would mean that pretty much all anonymous constants would cause that lint, so we add a flag to their MIR to detect whether they actually use any generic parameter: uses so that flag is true. The problem is now that is concrete, so evaluating the constant is successful, but the constant refers to which is still generic. We should just disable the lint if is enabled :shrug: cc
Another similar. Short example failing on Nightly (thanks to ilyvion for narrowing it down): My use case: I know it's a semantic/voluntary constraint only, and it's quite recursive, but I believe it deserves its place. (Alternatives I tried are at )
this has been fixed, needs test to close


<!-- 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</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimized: I think it's just that this attr ICEs when attached to methods and not functions.
claim


Our snapshot builder is running CentOS 6.
I think we would have to build on CentOS5 to reliably support RHEL5. Perhaps we should just call it unsupported as we do for old OS X versions? The only alternative I can think of is actually getting a C library like working for Rust and statically linking it in the snapshot builds. Sadly, itself doesn't really support static linking (and is huge).
I agree with I think we could move forward to just supporting RHEL=6.4 Do you agree? Can this bug be closed?
By the way, my earlier mention of musl isn't actually relevant. It only runs on kernels newer than the one offered by RHEL5 anyway.
The thing is that RHEL systems that many people use at work are upgraded rarely because stability is important in complex-shared setups and utmost in production. If I can't get Rust for RHEL5 then it will literally be 5 years before I can use Rust at work. It's not like your macbook where you might as well take the latest OSX after a month or two. We're currently still moving systems to RHEL5 and shutting down HPUX11 and RHEL3 sometime next year. RHEL6 is for new projects only and not used for anything in operations. The thing is that it's kind of a nightmare imagining how you could even get Rust going again on RHEL5 since you need an already-working Rust to bootstrap compiling. You'd have to go back to the last snapshot that worked and start trying to build incrementally-newer versions until you got up-to-date. Maybe you could start with a chroot configured like RHEL6 and somehow work backwards.
This per precisely the problem for me as well. I would love to be able to write a few tools in rust, and introduce some coworkers to the language.
I think your idea of using musl is a good one. I haven't used it before but the FAQ says it works on 2.6 kernels and RHEL5 is 2.6.18. I will see if I can build it. The other thing, though is that it's not just glibc but every one of the dependencies which depend on glibc -- which is likely all of them -- will have to be built with musl. How big that job is depends on how many dependencies Rust has. I haven't had the pleasure of building from source yet but I imagine it's quite a few. Still, some effort is warranted to avoid freezing out a large fraction of professional programmers. Update: musl builds with no problems in RHEL5. Too bad it doesn't seem to come with a test suite. Now to imagine how to build all those dependencies. The big problem still is that Rust can't bootstrap in RHEL5 environment so I'll still have to make in RHEL6.
This is worse than I thought Rust snapshot doesn't work on CentOS 6.5 which is equivalent to the final release of RHEL6. How am I the first one to notice? The only newer platform is RHEL7 which was released in June of this year. This platform requirement makes no sense. LLVM works fine on Redhat 5. Julia -- also based on LLVM -- compiles on RHEL5 without a hitch. Why does LLVM want GLIBCXX bla bla anyway? Doesn't clang++ ship it's own stdc++ library? Update: I went through the build process. Tried a few times with different Linuxs (Linuxi?) and was only successful using an up-to-date Arch. I think it may never be practical to reduce the build requirements to enable building on less bleeding-edge distros. What can and should be done is to cross-compile targeting older or alternative libc and ship binaries with own libstdc++ or libc++. The build process makes LLVM but not clang or clang++. I think the way forward would be to build clang (or just use Arch's if it doesn't need patching) and then use it's cross compiling capabilities along with the kernel sources, binutils and glibc from Centos5 srpms (or uclibc or musl might be good alternatives to old glibc; maybe even glibc can be configured to not use interfaces past 2.12; I'm not an expert). Anyway, it's an all-day project and I'll have to see if I'm still interested this weekend. Question: If the build-system requirements are bleeding-edge, is there any particular reason to build LLVM from scratch rather than using the very up-to-date one that always exists on Arch? Answer: Yes, duh. You have to cross-compile LLVM and all of it's dependencies too in order to ship a glibc-free This may also be a good time to integrate some patchelf technology. If most linux installations will be binary-only then it's good to let the user select where to install it. Some non-root users will want to try it in their home directory and some sysadmins would prefer to install to /opt/rust rather than piling everything up in /usr/local.
Just came across the same issue. I'm very surprised to find that rust aparently doesn't even run on RHEL6. Is there a way to compile a rust program for RHEL6 or 5?
Are you sure that snapshots don't work on RHEL 6.5? Nightlies I understand since they link libstdc++ dynamically, but snapshots link it statically. If snapshots work you should be able to build from source.
We use to use Rust in production, however we have a non trivial number of customers on RHEL 5 (and CentOS). The fact is that 5.10 came out less than a year ago and is not scheduled for EOL until sometime in 2017. If Rust decides to not support such platforms, it will mean that we will not be able to use it and I suspect that a large number of potential users will be in the same boat. I would like to add that we have figured out work arounds to run builds on CentOS 5.10 for now, but we really need rustc to properly support the platform.
Maybe musl is going to be the way forward…
So, I'm a bit confused about why musl is needed. When I looked, in the rust nightly there was only 1 symbol that depended on glibc 2.6, and that was conditionally detected when llvm when compiled on a box that had glibc 2.6. If rust was compiled on CentOS 5.10, it should "just work". I actually got it working (using really bad hacks), so it should be doable without embedding libc.
libstdc++ is pretty easy to install (just need to grab a new enough gcc, and there are packages for it on RHEL 5)
honestly, I'm pretty sure that getting musl working properly will be a win, regardless of whether it is possible to build rustc on old boxes. The ability to (optionally) build a totally self-contained native binary from Rust, especially if the total file size remains plausible, would be very nice.
cc re musl.
The latest snapshot (being in ) should fix this issue.
I've built rust successfully on my RHEL 5.5 machine, and a basic "hello world" is working. Thank you very much!


iterates over (which point to a slice of bytes in memory). When the code points expire (no more bytes available in the slice), there is no chance of the iterator ever returning more values. Therefore, should implement . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It is currently fused in practice and I don't think there's a good reason to change that in the future. This would technically be an API change but one that should have no negative impact to existing code. Which is the long winded way of saying I agree.
Thanks for the quick response! I realize that this is an API change but didn't feel it'd warrant a "feature suggestion". I guess for now I'm just throwing the idea out there.
This is a great idea and I'd be happy to see a PR that implements it. I was just ticking off a checklist. It's not a breaking change and it is useful, so implementing it should not be at all controversial.
Sounds good, I'll get to it tomorrow! claim
Note that, procedurally, a new trait impl is insta-stable so will need a FCP. (That's totally ok, just wanted to note it. You can and should send a PR for it.)


I tried this code: I expected to see this happen: it compile Instead, this happened: it didnt It most recently worked on Rust 1.60 and this nighty: : searched nightlies: from nightly-2022-04-26 to nightly-2022-04-29 regressed nightly: nightly-2022-04-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Slightly simplified reproduction: In other words, this isn't specific to .
Since this has been fixed now and we never received any reports outside of bevy, I'm going to go ahead and retroactively mark this as P-high. I had suggested , but that appears not to have been correct.


<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Et Voila! ! Here's the final result, pushing a PR soon
Should be fixed by


: <!-- 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 --
Also ICEs on beta. Output on stable: label regression-from-stable-to-beta
searched nightlies: from nightly-2022-04-16 to nightly-2022-04-17 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium


<!-- 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: runs infinitely Instead, this happened: return directly The is set to :
According to and , rustc doesn't emit , which means the loop generated by the tail call shouldn't be removed(I guess).
This was apparently working in 1.58 and regressed in 1.59. label regression-from-stable-to-stable
Small reproducer:
From a cursory look, probably due to:
From cargo bisect: Probably related to
I'm tagging this as , as discussed in the . The following reproduction is concerning: This exits with an , which is not good. Presumably, is returning even though it returns . One of many ways in which this can likely be unsound.
Upstream fix: Upstream backport issue:
Reopening to beta-nominate. This regression is a nasty miscompilation that can silently induce unsoundness in valid code, given a certain opt-level setting, and is not platform-specific. The patch to LLVM to fix this is quite small:
As per T-compiler meeting (), lowering priority of this issue since has been there for a long time and the "illegal hardware instruction" mentioned is the we generate intentionally here. label +P-high -P-critical
Closing this as the beta backport has happened.


Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.


See https://crater- This is a 1.62 regression, it seems, based on Crater. At the very least, it's a diagnostics issue that we're suggesting adding an already existing lifetime bound. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2022-04-01 to nightly-2022-05-31 regressed nightly: nightly-2022-05-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details, cc
The issue is that bound is causing the new wf check introduced in to fail. Regarding the diagnostics being weird, the issue is probably because we don't handle the case where a higher-ranked lifetime doesn't outlive itself. We just see a borrowck error, see that it's due to the binder's lifetime, and suggest adding it. Not sure if that needs fixed, personally think it's not worth it.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
This got fixed on nightly by enabling nll by default
claim For the test


Building a simple fuzz target using --cfg fuzzing -Cpasses=sancov-module -Cllvm-args=-sanitizer-coverage-level=4 -Cllvm-args=-sanitizer-coverage-inline-8bit-counters results in a linker error: {symbol} referenced in section {section} at {rcgu}: defined in discarded section {other section} of {other rcgu}. One possible workaround is to set -Ccodegen-units=1 (any higher value triggers the error). Alternatively, -Znew-llvm-pass-manager=no and -Cpasses=sancov (instead of -Cpasses=sancov-module) will also result in a successful build. Repro steps: : Note: The same error also occurs with rustc 1.61.0 (stable channel). : Note: GNU ld is the default linker on this system. On another system where the linker is LLD, a similar error occurs, the message is just worded a bit differently.
We somehow end up running sancov-module on an input that already has defined. For the example IR below, the following happens: We generate a new which has a numeric suffix (".19" in the error message above). This is part of the $sancov.modulector8bitcounters (no suffix) comdat. The suffixed is to which already mentions and the original (no suffix). The .initarray.2 that is generated from is mentioned in two comdat groups: f and sancov.modulector8bitcounters. If we subsequently link this object with another object which also has a sancov.modulector8bitcounters comdat group, the linker will preserve only one of the sancov.modulector8bitcounters comdat groups. The error message shown earlier happens when the linker discards the comdat group that contains but keeps the .initarray.2 that references that symbol. It can do this because that .initarray.2 is also mentioned in comdat group f. LLVM IR before sancov-module: Some relevant sections of the IR after : After machine code generation, : There is an assert in CreateInitCallsForSections: This assert will trigger when is created. Of course, that only happens in LLVM builds with asserts enabled. What I don't yet know is why the sancov-module pass is being run on a module it has already been run for. I can see the multiple runs in the output if I pass in -Cllvm-args=-print-before-all, one of which creates the suffixed function, but I do not know what causes the pass to be run multiple times on the same module.
Passes configured with should probably be included only in pre-link optimization stage in: Similarly to sanitizer passes configured a few lines earlier: Otherwise they will be executed multiple times with LTO (a thin local LTO is enabled by default when using multiple codegen units).
Thank you. I was thinking along the same lines. I have a patch that does this, which I will send for review once I've tested it. I am wondering if there is value in also being able to specify passes specifically for the LTO stage; perhaps with a new -Zlink-passes flag. What do you think?


<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: I expected the compiler to let me know that function signature was wrong with the Result<, B`. Once I changed this, it compiled fine. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I've come up a solution with which the output of this test case will be like the following: It is cumbersome for still having E0391 printed, but it seems not easy to remove this without a significant code changes. I think the first message E0121 "the placeholder is not allowed within types on item signatures for return types" should have told the user enough information how to fix the problem. Any comments/suggestions?
having an early return for when there's no generics on will solve this problem.
Thanks a lot for the advise! After the following code change, the faulty message has gone way, and correct output generated.
The output of the test case after the fix is correct:
great, now you can send a pull request :).
Thanks for your work


has this to say about a better way to turn a into a : A strict reading, if I understand correctly, says that these two statements are contradictory. The documentation says that it is safe to create a and then use to create a out of its pointer. But the documentation says that, when creating a , must have previously been allocated via precisely and only , not for some other type —not even if happens to be transmutable from , not even if and are ABI-compatible, not only if is a wrapper around , but only itself. I suspect it was meant to say it must have previously been allocated by , not ; after all, if it could only have been allocated by in the first place, the next bullet point would be redundant (because obviously has the same alignment as ).
label A-docs
Relevant: looks like it will fix this if approved, by explicitly allowing allocation using something other than Vec<T(which can be a Vec<Uor even manual allocation)
Hm, that PR does remove the text I pointed out, but it also adds this text: Isn’t that equally problematic (albeit a slightly different but related problem, since it’s talking about the contents of the memory rather than its ), since it is actually fine for them to be properly initialized values of some other type that is suitably bytewise-compatible (for a proper choice of wording for “suitably compatible”) with but is not actually itself? Or does “properly initialized values of type ” actually also cover that (i.e. does it mean “bytes containing valid representations of ” and not “memory regions which have been constructed as s”?).
Rust doesn't have typed memory, types only have effect on accesses, so if some memory can be interpreted as some type T and it's valid at that type, it's a properly initialized value of type T. Nothing remembers the "original type" of some data. Just like how you can cast a to a and use them interchangeably. This is a safe operation if you use , too.


This perfectly wrong statement causes compiler to mention s, and even though nothing like this is written in the code: (here and after normal errors about argument number/type mismatch are not shown as they are not the problem) Originally I've found this while editing some async code and passing instead of . I was very confused and thought that it somehow relates to //etc but after some minification I was left with the snippet above. This error becomes less confusing after desugaring loop by hand: Note that using is required to trigger this bug, using doesn't trigger it for some reason. In fact, you don't even need a : So in the end, this can be triggered with an / one of branches on which is diverging expression with that is being passed to a function with wrong number of arguments. As I previously said, I've found this while working on async code and I think this is the main way how this error can be seen (let's be serious, nobody calls functions with loop arguments). The reason why it's easier to find this error with async is that blocks are commonly passed to functions (like ) and can contain loops inside them. In my case the code looked something like this: Which caused an error like this: ! Note that "expected because of this" points to the last statement in the block even though it has nothing to do, really, with the error. searched nightlies: from nightly-2022-04-10 to nightly-2022-05-09 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: : : </detailsBisection shows that this issue was introduced by which aligns with other observations. This is likely caused by the same underlying problem as : diagnostic code calls a second time which confuses different parts of the compiler. cc as they've worked on fixing issues caused by before This is reproducible with (2022-07-02 ) and with most nightly-es after (except for those that ICE). label +A-diagnostics +D-confusing +D-incorrect <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I wonder if this is also fixed by -- I will check and/or fix this too. claim


Running clippy or build on the Vaultwarden code-base using breaks. It is broken since and still works on Tried to run before running this without luck. If you need any more information, please let me know. Vaultwarden: Working: Broken since: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Looks like this is a duplicate of , , , , , and Sorry for the clutter ;)


<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: <!-- The following is not always necessary. --Ideally the output should look like: Highlight to the user that the keywords and are mutually exclusive. Replace with . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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 output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: This code should compile normally. Instead, this happened: In the function, T was already bounded by the trait which does have an associated item named . However, Rust complains that no associated item named was found for . <!-- 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. --:
I did some digging and this might be related to Mind taking a look?
A fix exists here at but we're waiting on 's pending RPIT refactor work to fix this. In the mean time, developers who need this feature can use the branch in . https://rust-


When using in the to enable profiling, having a local copy of is required. If no such copy is present, errors about missing libraries are emitted and the build fails. Expected behavior: Bootstrap initializes the submodule when is enabled. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This should be pretty easy to fix - call in if profiling is enabled.
claim