<!-- 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. --Github: Repro: Reproduces in: Stable Linux - rustc 1.61.0 ( 2022-05-18) Nightly Linux - rustc 1.63.0-nightly ( 2022-06-02) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I'll see if I can make a smaller repro case
So, the minimal repro case is MUCH smaller: in : In : Which points to these code chunks: This seems to work in the tests for , so it seems like the ICE only triggers when used from an external trait. Additionally, this ICE does NOT trigger in .
CC
Yeah, this seems to occur specifically when trying to compile an external crate that calls this function. Lib tests inside the crate that call the function don't ICE, but adding an integration test (outside of the crate's compilation unit) does trigger the ICE:
If the function is made , the ICE no longer occurs. For example, this commit does not ICE:
prioritize
, if the functions are made but placed in a private module, they get culled again, triggering the ICE:
It also appears that if you move the functions out of the , AND mark them as , the ICE is also abated. See this PR for addressing:
For folks joining now/as a TL;DR, the offending code is basically this: The function produces a value, that gets created in a static: Which gets loaded into a static in user code: It LOOKS like somehow the two original functions (declared inside a private, const fn; inside a private type), are getting culled, which means that when the static (in another compilation unit) goes to be created, the MIR for those functions are missing.
This is likely a disagreement between . Though I don't know much about codegen.
Anyways I think I have a fix, though I am not certain it's the right one. In any case, I at least have a minimized UI test for rustc devs who know codegen better than me. PR incoming.


Found with The attribute applies to The was initially lexed as part of a token This seems to be exactly the case described by the : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Do you have any suggestion for this case? The code path is going like this: Parser eat the first one of '' at here and set : fall pass at here: So this assertion is failed: The result is: and is true. Seems the assertion missed this scenario, do we need to add a TrailingToken::Gt ?
The assertion I wrote is overly conservative - it really just needs to check that we don't simultaneously break a token and 'really' capture a trailing token. Specifically, we only need to panic if we actually incremented in the match block. I think the simplest fix would be to add a variable, which gets set to in the parts of the block that increment . The assertion can then be changed to breaklasttoken


<!-- 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 --
cc is this fixed by one of your PRs? This looked like it might be , but while was bisected to this one was bisected to , not sure what to make of it :thinking:
Yes, this issue is fixed in (ice → errors): <details<summarystderr</summary</detailsI'm not sure why the bisection points differ, they all share the same root cause. It doesn't really matter though. Btw, I saw about another new reproducer but I dismissed it as irrelevant since I assumed it required , too (I did run it but didn't notice I could omit that flag). Sorry about that. Thanks for opening a separate issue because now we actually have 2 beautiful regression tests for the bug fixed in ! So let's not close this issue then but wait for to get merged and then I will open a separate PR with the regression tests & assign you. claim


Obviously a corner case. This would never actually be used for anything, this is just testing the bounds of what the compiler is capable of. Running this Ruby method with numarguments or greater generates a Rust file which can be used to reproduce the output. (via ) : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +regression-from-stable-to-beta
Nothing that Ruby code can achieve that Rust macros couldn't do as well: ()
Haha, just tried out a different direction of “many arguments”. Apparently this results in a segfault, AFAICT It’s explicitly a stack overflow on stable (and AFAIK segfaults can happen on stack overflow in sound rust code, so maybe it isn’t some memory unsafety). <hrEdit: Opened this as a separate issue
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low


<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilization. Make sure to include the relevant RFC for the feature if it has one. If the new feature is small, it may be fine to skip the RFC process. In that case, you can use use in your initial implementation PR. The reviewer will ask you to open a tracking issue if they agree your feature can be without an RFC. --Feature gate: This is a tracking issue for (and friends for the other unsigned types). Like (), this generates simpler code than the underlying integer type because it can avoid a separate zero check. <!-- Include a short description of the feature. --<!-- For most library features, it'd be useful to include a summarized version of the public API. (E.g. just the public function signatures without their doc comments or implementation.) --<!-- For larger features, more steps might be involved. If the feature is changed later, please add those PRs here as well. --- [x] Implementation: [ ] Final commenting period (FCP) [ ] Stabilization PR <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final commenting period (FCP) is always needed before stabilization. This works as follows: A library team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final commenting period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet.
Great, something else that just breaks my code. Sigh.


With , I would like to propose  for stabilization as well. (I think this in the tracking issue is the right thing to do now, rather than filing a PR?)
shall we stabilize ? 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. This will be merged soon.


we should change the following function to use a instead of Using a walker causes the control-flow to be a lot more complicated and given that this code is soundness-critical, we should make sure it's as easy to understand as possible <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


This enhancement suggestion looks a bit silly to me, but I think it's worth asking for an opinion in this bug tracker. I think this is a reasonable usage pattern of and . I've used it with a larger SomeData to avoid both an useless initialization and the use of that in those cases is slightly slower, the disadvantage is that this code contains and it's a bit fiddly: An API that removes the unsafety could be: is similar to , but it doesn't include any growing strategy (and doesn't include such growing/realloc code in the binary), so it just uses the capacity. If the capacity isn't enough it panics (just like the first code panics if the capacity is finished at ).
label C-enhancement
label -C-enhancement C-feature-request
It might be better to return a instead to let the user handle the failure case.
An extra note. Currently on this code: I think LLVM12 isn't able to see that code will never realloc and doesn't need a bound test:
The naive implementation of already optimizes out the reallocation case with . Since (parts of) the reallocation code is inlined into , this would give smaller code size (). Here is a use case that I encounter fairly frequently: I want to construct a , so I preallocate one and push elements into it. However, if there is an off-by-one error in the preallocation, then it would reallocate every time. Having a function (followed by unwrap) would help catch these errors.
I suggest creating a fixed-capacity type wrapper instead, so that it can also be used with and many more methods without realloc code bloat.
I suggest creating a fixed-capacity Vec type wrapper instead, so that it can also be used with Extend and many more methods without realloc code bloat. A question: such wrapper doesn't cause bloat itself?
No, I don't think it'd be much different from deref that gives you the as a slice.
What do you envision to do when the vector runs out of space?
Panic. I also hope that the wrapper type with a fixed-size storage would be easier for optimizer to reason about (similarly how taking a slice of a vec before a loop helps remove bounds checks in the loop). If the optimizer is able to remove capacity checks, then failure handling code doesn't matter, because it will be optimized out too.


Interestingly, it can't be as simply implemented outside of , because the field can't be directly borrowed, but if you need to use reference and , then you can't have the slice at the same time, because it'd violate mutable aliasing rules. If necessary, the capacity error behavior could be configurable via a type parameter, e.g. or (that silently ignores excess elements). The extra argument would allow compile-time specialized code (so no extra runtime check), and inflexibility of a type argument wouldn't get in the way, because it's a temporary object that you'd create on demand, so you can create a different one for each use.
why not add unchecked versions of functions with capacity check (, , , , , ...)?


The second error in this snippet is "nonsense" because it says the type parameter is not constrained, while the real error was already reported — the actual type could not be imported. Found in: rustc 1.13.0-nightly ( 2016-09-26)
.


Error: That's this: The GVN MIR diff is this: searched nightlies: from nightly-2023-06-01 to nightly-2023-11-08 regressed nightly: nightly-2023-10-30 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This issue is a bit old but I've now minimized the reproducer, it's in the description. the assertion that's failing here looks to me like it is simply too picky, and it should be checking if the alignment of the allocation is the alignment of the type we're reading from it, instead of exactly equal. Do you agree that this is just a too-picky assertion?
I agree the assertion is just too picky. I expect the subtlety of needing to pass the larger alignment for the llvm constant.
I can't figure out what you mean here. What LLVM constant? Why is there subtelty? Maybe I just don't understand what's going on with GVN here, I'm assuming that GVN has merged two constants together so that we're now loading part of a more-aligned constant to get a less-aligned one. Is that wrong?
I mean, this is codegen code. It creates a constant for llvm. That constant has some alignment. We need to pick the right one, between the lhs and rhs of the assert.
Where are we picking an alignment? Is it down here?
smaller repro: <!-- ICE: Rustc '-Zmir-opt-level=5 -Cdebuginfo=2 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' File: --auto-reduced (treereduce-rust): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --
I don't really know.


TBH, the simplest solution is a codegen test, and check that the generated constant has the right over-alignment.
I don't have confidence in my ability to do that, so I think it would unblock you faster if you took this issue. I feel like just this diff is a fix for this ICE: But I don't understand why the assertion was exact in the first place, or what the hazard would be from over-aligning the allocation.


<!-- 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
glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Compiler error on but ICE on label +regression-from-stable-to-stable
cc
A previous (now-fixed) ICE with the same error message is
Thanks for the report! Would be good to get a better backtrace; this one seems to be missing many frames and there are no line numbers.
, I updated the backtrace in my first post. I used rustup to get the latest trunk version, and the one I have been using does not have line numbers. If there is a flag or configuration for rustup to get rustc binaries with line numbers, I would be happy to change the settings on my testing machine.
I think getting line numbers requires a debug build of the compiler, so it's not quite as easy as installing something via rustup.
Labeling .
Here's a backtrace with debug info: <details</details
Unfortunately, this bottoms out ; more digging will be needed to determine the true underlying cause of the error.
Here is the actual backtrace of the underlying CTFE/Miri error: <details</detailsIt points to this line: can handle pointer values just fine, so I think what is happening is that we are reading parts of a pointer value here, which indeed is not supported in CTFE.
So... I guess the fix is to make this kind of error also be permitted during validation and turn it into a proper validation error?
Permitting it at the top-level is no good, since then we don't know "where in the value" it arose. We need a version of that catches this error and turns it into a validation error with the current "path".
Oh... right, we should fix this in general, and not just wrap in .


Maybe we should not have any automatic way to bubble up errors and require all sites to use ?
I think we should wrap it but put the wrapped thing into a helper function sow e can also use it for the other places. So basically, you want to use a different error type for validation, one that excludes all the other errors? I am open to refactorings here.
Let's start out with wrapping, and then I can experiment with the refactoring so we can have a look at the usability effect of it Instructions: wrap the call at in a macro invocation and capture the error. Emit a validation message about the fact that reading parts of a pointer is not possible during CTFE. Don't forget to add a test (the failing example from this issue works great as a test) and run the test with
There are quite a few calls in that will all have this problem, so ideally they should all be treated this way. To avoid code duplication, it will probably make sense to move this into a helper function.
Reopening this to track that is still called unguarded a few times in , so e.g. the issue can still arise with .


At line 393, the guard object's field is incremented by the value returned from a read implementation. If a questionable returns a value larger than the buffer size, it will take that value and set the length of the vector over the boundary. This bug is reachable from and . Here is a that demonstrates the bug. It segfaults with .
This is definitely broken - nice find. A simple fix would be to just add an in the drop impl: You can still get weird behavior in readtoendwithreservation, but it should be memory safe and it seems best to avoid a bunch of extra logic in the main loop.
It looks like the bug was introduced in
Assigning as and removing .


Since the function is tagged the exact name presumably has to exactly match something that another system is expecting, which may not be snake case. For example, JNI bindings will look something like
Modifying lints requires an RFC now, as it can impact a LOT of code.
(By modifying I mean "major changes" not bugfixes)
Hm, while I think new lints definitely want an RFC, modifications to existing ones can probably go through the lang team's nomination process, leading to either an immediate decision or request for RFC.
I'm fine with that, just following (what I thought was) procedure. :smile:


On native Windows:
This looks sus: That's a which is an absolute Unix path. On Windows it will be interpreted relative to the root of the current directory. For example, if your current directory is then it'll be . (Also it'd be nice to use raw strings here because the is confusing in the context of paths)


<!-- 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
searched nightlies: from nightly-2023-02-17 to nightly-2023-02-19 regressed nightly: nightly-2023-02-18 searched commit range: regressed commit: - -cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details


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! cc the PR reviewer, and -- nominating for prioritization.


I was playing with DST by reimplementing the primitive as a , but hit an ICE while testing. The code is in this cc This seems similar to cc
Minimal test case:


Right.. is my own PR; I'm noting this as an issue, mainly so I won't forget this, because I won't do this myself right now / today. Or someone else can do this if they want. I'm not 100% certain where the best place for such a test to go is, and/or whether it makes sense to have them in one place or separated and more close to the respective type's definition. A test to prevent any future regression removing the new auto trait implementations introduced by can look about as follows <s` </sEdit: This code is needlessly complicated, see my comment below. label C-enhancement, A-testsuite, E-easy, E-needs-test, T-libs <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
FYI, somehow I missed the more straightforward way of writing these.


<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: expect 1 RPITITs in call to '', 'thread 'rustc' panicked at 'assertion failed: expect 1 RPITITs in call to '' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- query stack: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of [checkmodimplwf] checking that impls are well-formed in top-level module [analysis] running analysis passes on this crate --
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
fyi


Command was with the following <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
And yes, was enough to get the build to finish, in case there were any questions as to whether that was the difference.
This is the first PR that fails with the error described in I do not know if the fault is here or in the symbol mangling but it as I understand it that function that is called is only used for the the size of an array and it feels strange that it shall be a bool -- it seems pretty clear the bug is in the symbol mangling rather than with , because it's not adding anything out of the "ordinary" Rust code. That said, it's likely that the const generic could be replaced to avoid the error perhaps.
Yeah, isn't this "just" an instance of new symbol mangling not being compatible with const generics?
was to tired that night when I hade bisected the rust build and this hade nothing to do with arrays that I was writing. was possible to avoid the bisect all together if I only hade looked trough all of the log. it is saying that it is eg. that fails so it is the bool in the path that is triggering the fault in symbol mangling. according to only unsigned integers is handled and the rest is left for "future const-generics work" shall this be marked with some const-generic label? right now it is only bool that also needs to be handled for rustc to compile but do not know how to go forward
seems like there is a issue for adding mangling support here so this will probably be fixed when that issue is fixed.


On the latest nightly (previously it worked fine) Rust fails to compile this code: It emits this error message: I managed to strip it down to this example: It fails to compile with this error: If is replaced with , then it compiles fine, so the error seems to be related to matching on s.
Sorry for the breakage, fix on its way.


I just upgraded my to . But when I tried to rebuild my project, it failed with the following errors: , , etc... are constants of type . What does the error mean? I am confused.
Thanks . It seems that the bug is fixed, please merge it to upstream asap. :)
The same as


<!-- ICE: Rustc '' 'error: internal compiler error: expected type of closure to be a closure', 'error: internal compiler error: expected type of closure to be a closure' File: --auto-reduced (treereduce-rust): original: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirbuilt] building MIR for [unsafetycheckresult] unsafety-checking [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkmoditemtypes] checking item types in top-level module [analysis] running analysis passes on this crate --
regression in ping
nice, that's one of the ICE messages I just too


<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'no entry found for key'', 'thread 'rustc' panicked at 'no entry found for key'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in nightly-2023-11-08 / ping
I think is fixing an issue that may have the same root cause.


<!-- ICE: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in nightly-2023-11-08 / ping
This should be fixed by
I'm intrigued as to why you believe could rectify this problem. The issue can be distilled as follows: It results in a panic at due to the closure utilizing the type from its outermost function, eventually returning . This issue appears to be unrelated to .
You're provably correct, and I am likely wrong about the root cause of the issue. I will look tomorrow. Feel free to claim this issue if you've already found a solution in the process of investigation.


If I run the following code : I get the following error : I don't see any reason for the trait Debug not to be implemented for BinaryHeap. If seeing the nodes of it is a problem, at least a could be enough.
Should be fine to display the elements -- probably an oversight?
Probably an oversight. Implementing the solution shouldn't take more than a line (few at most) and it is annoying that you can't easily implement debug for struct owning one BinaryHeap.


About to submit a PR for exposing intrinsics::needs_drop under mem. Needs a tracking issue. Here it is!
The PR is
fcp merge Seems like this may be good to stabilize!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, 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 is now complete.


I tried this code: I expected to see this happen: Instead, this happened: The problem doesn't occur with optimization enabled. It most recently worked on: Also fails on: modify labels: +regression-from-stable-to-stable -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Thanks for reporting this! This is an issue with a debug build so it's unlikely to be prioritized high but I'm interested in helping out because this is very goofy. The slow code here is the Iterator impl on slices. I think in the last stable release we switched the implementation of BufReader to eventually use ReadBuf, and the slow code is ReadBuf initializing the remaining uninitialized capacity. It does this by iterating over a slice, and that iteration is the slow bit. What I don't get here is why we need to initialize at all. That doesn't seem right.
WG-prioritization assigning highest priority since this looks a pretty visible runtime perf. regression (). If the assessment should be revised, please feel free to comment. label -I-prioritize +P-critical i-slow
I've tried bisecting with and feeding this command: . Regression seems to be in and confirm <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
:joy: I was so sure this wasn't my fault. More fool me for not bisecting it myself.
(This probably shows an opportunity to add a benchmark to the newly-established "runtime benchmarks" (rather than the compilation-time benchmarks that has classically focused on...)
After sleeping on this, I realized that there's no real reason to expect the worlds-worst-memset code which is the source of the slowdown to be totally optimized out with . And of course it isn't. This is also a substantial regression with optimizations.


Here's a version of the original program that's touched up a bit: On 1.63 I see runtime ~0.43 s, and on 1.64 ~4.8 s. So we have a slowdown of around 10x, though I suspect that number could be ratcheted up higher.
claim
Awesome, thanks for the really quick fix!


Minimized from : This issue was introduced in the build, and so it is likely to be a result of the upgrade to LLVM 17 ().
I have bisected the LLVM pass to the pass on main. I'm trying to get a diff of before/after so I can start tracking down the exact location of the incorrect optimization.
The optimization transforms this switch lookup which appears to correspond to the : with only the calculation of and changing from: to: with the rest of the IR remaining unchanged. The transform of appears to be okay ( by 64 -by 6). The transform of introduces the issue because although the instruction is marked as , is equal to which is negative in the signed representation and so subtracting 128 does cause signed underflow.
The IR output from rustc without any optimization passes outputs is: Which appears correct to me. This suggests that the is being introduced in a later optimization pass. I'll continue bisecting when I get a chance.
Looks like this instruction is being generated by a pass that's run before the pass. Before : Which is correct. So the real errant pass is , it just doesn't cause incorrect x86 to be emitted until a later pass.
Looks like this issue is known and a fix is in progress upstream at


: Local docs: ! But has the same issue: Probably caused by: ()
It seems like this css rule: applies to this element: !. Before () this rule wouldn't have applied because it would've been contrained by instead of .
This also had some other side-effects here: ! The search results have top/bottom margins compared to the previous styling.
The second issue was fixed in I'm checking for the first one, unless you want to send a PR?
Hmm, sorry I didn't/don't have much time to dig into this more. I couldn't think of an immediate fix for this because it kinda looked non-trivial (to me) :/
Don't worry, I'll send a fix in the next hours then.


This compiles successfully with . It's possible that this regressed when the two features were separated. It's also possible that stabilizing never_type first will make this issue moot.
I'm very surprised that this is still open. can you add the I-nomiated flag please, if you think it's appropriate here? modify labels: T-compiler C-Bug
This only seems to occur with nightly features enabled, so I'm not sure it's supposed to be nominated. I'll mention it in the tracking issue though.


Windows 8.1 64-bit / MSYS2 / MinGW-w64 cc
Interesting! This is testing the property that the duration between two instants plus the first is the same as the second. Unfortunately this isn't true on Windows due to the +/- one problem on multiple cores. Have to think about what's the best course of action here.
This still fails, btw


Originally stumbled upon through the eval IRC bot: Here's the smallest reproduction I could get, Removing either the block or the borrow displays only a normal compiler error (not an ICE) trace
triage: P-high, assigned to ; removing I-nominated label


For clarity, the second call to ends up using the impl on . cc I had concerns about this kind of thing when these impls were being introduced but I thought I convinced myself that this kind of thing couldn't happen. Did something change in the way we designed these impls since then?
Possible solutions are to either remove the impl for or update to prevent it from invoking . Seems to me like the second is the better approach.
I believe the reason for the was because it was considered a good thing to require callers to explicitly pass references. I think we've actually gone back and forth on that a few times. Are we committed now to allowing callers to just say ?


Rust's runtime installs a signal handler to distinguish stack overflows from other faults. This requires using an alternate signal stack (), which we create with the default size . That's usually quite small, 8KB or so depending on the target, but it's still plenty for what the handler is doing. There's currently no guard page like we have on normal stacks. That alternate stack is shared by all signals for a thread, so if a user installs any other signal handler, and they opt in with the flag , they'll be limited to the same tiny stack. If their handler happens to be more involved and overflows that stack, it may silently clobber other memory. If we had a guard page on the signal stack, that would cause a process abort instead. This was reported to the Security Response WG with a reproducer in . However, after discussion we decided to treat this as a normal issue for a few reasons: Setting a custom signal handler requires code. Signal handlers already run in a quite constrained environment, e.g. . It's unusual to use for signals other than , and if you choose so, you also bear responsibility to make sure that stack suffices. Nevertheless, as a defensive measure, it's still a reasonable idea to map a guard page when Rust is creating its signal stack, so an unexpected overflow will abort rather than silently corrupting memory. For full protection, that would also depend on the guard page not being skipped, but not all targets have stack probes yet (). Thanks to for reporting this in accordance with our , even though we have decided not to treat this as a security issue at this time. cc
cc This is another reason we perhaps shouldn't be registering the signal handler... cc


hey everyone, I get this message from when is executed: It seems there are some backports still missing for beta, since I can fix this by reverting locally, and there are some subsequent fixes in nightly who seemed to have fixed the issue for good. So, is there somewhere a list of the nightly backports needed to fix this problem? Thanks.
can I ping you on this? Beta is not compiling on gentoo, I assume at least one patch from nightly still needs to be backported to beta.
There is that should have fixed that and it's .
Hi, I'm on latest beta from last week. If I apply locally and compile, I get access denied error:
Logs says you don't have permission to put files into path from your build configuration. Without you would still get permission error.
I believe this is a sandbox error, so x.py install tries to write to / instead of it's prefix, and this is caused either by or it was already introduced by the older If I revert them both locally, I get a working x.py install
Interesting :thinking: Can you share your build configuration?
it basically does this: which translates to: and the patch seems to make x.py ignore the DESTDIR="" command In the rust context, the build config you asked me to share is the Have it attached for you, please feel free to ask for any additional information. also I can provide you with the full build log:
Did you wait for whole process(x.py install) to be finished? I don't understand how mkdir gets you into access denied error for path while you can actually create dirs/files in it..
Maybe there is some confusion about relative and absolute path? The access denied error is valid, as x.py never should mess with /usr/lib/ in install, but use /var/tmp/portage/dev-lang/rust-1.74.0_beta/image/ as it's prefix, if you want to name it like that.
True, there is a confusion between prefix and DESTDIR right now. I will fix it today.
Thank you, I'm happy to test any patch before you commit it to master.
You can test
yes this works for me, please also beta nominate
has this been beta-nominated? I'm new to this process, it's just I can't see a rollup pullrequest anywhere and the release of 1.74.0 is coming closer every day.


It is cc
for backport, the PR's responsible team (T-bootstrap) also needs to label it beta-accepted. Once it has both labels, the release team will handle the actual backport.


<!-- 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: note the duplicate <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
feature, not a bug: we want people to be very strongly discouraged, so we say it twice.
the more repetions, the more discouraged. lang_items should go up to 10.
Maybe we should print it in an infinite loop, just to be on the save side?
This is happening on as well.
claim The source of the problem is the decorator for which is adding two to the Diagnostic instead of one. I'm trying to dig further and decipher the marco-generated decorator code here: I also noticed that the behaviour seems to differ across gates. E.g. building this: emits one note for and two notes for : Not sure what's different about these gates. I'm new to this area, so if you can provide any pointers based on the above, please do.
This program tests all the internal gates: It produces the following output: Of the 21 internal gates, only the last 6 result in duplicate notes.
These should be more, there's a file somewhere that defines all the features but I can't check it right now on mobile
I think that should be all of them. This is super weird indeed, no idea
Thanks & I found what's different about gates with duplicate notes: they all have an associated issue. Here's the full list grepped from : Notice that the second last field in the last 6 lines is unlike the rest where it is . Apparently having an associated issue causes this problem.
The root cause is the being passed on this line: Its value is for gates that have an associated issue and for others. Since already has a attribute: this results in duplicates. The solution is to always pass for internal gates.


is useless () so skip it.
Neither of the macro chapters have sections for "common macros". Should we add one? Presumably there would be quite a few of them.
There is for the macros in std, plus some of the built-in syntax extensions. It's not that easy to find; there used to be a module in the rustdoc output but no longer :( I'm not sure exactly what should be documented where. The built-in syntax extensions like might deserve special mention, as they give you capabilities within that you otherwise would not have. cc
I think , , and also deserve mentions.
I would like to take on the task of documenting all the common macros. I've started them and appreciate some input on how big the final list should be, and if every macro needs an example (or three). What about the most common one, prinln! ? Should that be in there too?
It's not clear to me what doing this issue actually means. Moving some docs between some places?
The original issue was to add several common macro definitions with examples in TRPL, which I agreed with. I'm not sure what's up with the edits.


Trying to search for anything on results in a Javascript error: on line 313 of I'm on Chrome 30.0.1599.101 if that matters.
Weirdly, search results still appear if I search for most things, but not for anything starting with "sle" like "sleep".
This appears to be dying because of the method defined in . This shouldn't be showing up in the search because the entire module should be pruned as a result of it being private. This warrants more investigation...
Update: seems like it's not for "any" keyword as the OP states; for example or don't trigger any error for me. does for instance.
doesn't work either.
Happens to me too.
, , , , , , , and (and all shortened forms e.g. , ) don't work for me, but does work (i.e. shows results). The error I'm getting (on Firefox Nightly 29.0a1) is .
The error happens when a trait is implemented on a type that is pruned by one of the passes ( or ). The type was pruned but the implementation was not, so the search index included a method that referenced a missing type. fixes this.


See: This code: produces on latest stable (1.61.0).
Maybe we could form a heuristic around tokens that we know should eventually be followed by -- , , , etc. If we see one of those, (then some random other tokens), then we see , then that would be a suspicious rbrace which we could point out later.. e.g. if we see that triggers the heuristic, but not
The problem is that the error happens in the lexer, not the parser. Ideally we'd rework the lexer to have a token stream mode of operation instead of a token tree mode of operation, only for code that is being passed to the parser (i.e., not coming from a macro).
This is particularly confusing when the points to a macro: gives on 1.65.0-nightly (2022-08-31 )
the output now changed to: Do you think the should be removed?
This is changed to: it seems more helpful now.
Let's close this ticket after adding these two cases to the test suite then. I'm sure there are outstanding issues in this area, but we can hope that we'll get tickets for those more specific cases, while the tests keep us from regressing silently (hopefully, lets make sure the tests are fully annotated so its harder to do that by accident).


The example currently uses , but now that the macro has been stabilized in , it should probably use that instead. This should be an easy contribution for someone who wants to land a first contribution. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
hey can u help me from where i can fix this
Can u tell me how u solve this?
I have already solved this one and it is in the process of being reviewed for merging. If you wish to solve an issue, you need to pick one that has not been assigned yet. Try looking at this:
hey im new to open source, i want to grow in this field . Can i contact with u ?
I am pretty new to this project myself, but please reach out if you have any starter-questions and then I might be able to help you out. There is a chat on https://rust- - I am just "Mads Ravn" in there.
Thanks


The docs for  state: And include an example which uses to copy the value from an unaligned pointer into an aligned one. However, the docs for  state: Either the docs for are wrong, and does not need to be aligned, or the example for invokes UB and should be updated to use
cc (It's also notable that the example in is wrong when it uses as is seen if you move the statement out of the block; we should fix that ASAP)
Good catch! What we'd really want is , I think... we don't want an intermediate value on the stack. Feel free to suggest code that we can use instead. We have several doctests that need They have been there since 1.0 and longer, probably. But nobody listens to me when I say that there is existing code that we need to support ASAP.
The example given is just using to put it on the stack anyway. If you're having to copy the value at all, there's really no reason to use at that point, since the only reason to use it instead of is to avoid the copy (which is optimized out in release mode anyway). I think we can probably just remove the unaligned example entirely and change the documentation to read: I think we should probably mention the caveat WRT the optimizer eliminating the copy (or can it even do that in this case? The docs mention that the drop glue generated for packed structs does this copy automatically, I'm curious if it's doing so in a way that is UB or if the copy is just the price you have to pay here. It's also worth noting that there's no way to an unsized value through an unaligned pointer, but I'm not sure that's worth bringing up at all in the docs, since there's no reasonable way to actually get that pointer in the first place.
Oh, good point. Yeah then you can basically just make it , right? I wonder why / ever got used here? Well but wouldn't it make sense for that text to come with an example? It cannot, because then it would be introducing alignment errors. Uh... yeah. With it could work. Doesn't seem like a reasonable thing to have either way?
Presumably because they wanted the example to continue to use Sure, we could -- it just wouldn't ever call the function being documented.


Yes, it's just unrelated to dropping unaligned pointers since the only place you can reasonably copy them to is the stack. Unless you happen to already have an valid pointer of the proper size and alignment sitting around
I'm not actually sure unalgined DSTs are so unreasonable. For example, is only stopped by this rule: Which could be solved if we had e.g. a way to express "does not have drop glue" as a bound ( doesn't work for obvious reasons). In any case, I think "copy unaligned" functions make sense but we might want to consider multiple variants for src only / dest only / both unaligned. This can be expressed in LLVM IR though in a brief test I couldn't demonstrate that it currently makes a codegen difference (but I could only try on x86_64, where alignment rarely matters for codegen).
:rofl: fair. I guess all of this is basically saying an in-place drop of unaligned data is just not possible. Do an "out-of-place" drop instead.
Actually looks like the use of an unaligned pointer in the doctest just caused to fail to land. ;)
Proposed fix at


I tried this code: I expected to see this happen: “error[E0658]: the type is experimental” Instead, this happened: Successful compilation, as long as I'm using a nightly compiler, but the error when on stable 1.75. This is incorrect because nightly features should always require attributes on nightly (until they're stabilized, which hasn't happened yet 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. --: label +F-never_type +requires-nightly
searched nightlies: from nightly-2023-11-11 to nightly-2024-02-01 regressed nightly: nightly-2024-01-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsThen, bisecting Manually verified that reverting (as ) restored the error. cc
Not sure to understand why fixing the visitor implementation introduced this bug. Maybe it highlighted a limitation? Gonna check.
Ok I think I know why: implementation of the not calling the equivalent function. Checking where it is used.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Fix was already approved in . Waiting for CI to be unlocked.


One issue that came up in the discussion is that the type implements . This might have been introduced accidentally. probably does not matter at all, given that users will only observe a by reference. However has the impliciation that we will not be able to add non thread-safe methods to - e.g. in order to optimize thread-local wake-ups again. It might be interesting to see whether and support could be removed from the type. Unfortunately that is however a breaking change - even though it is not likely that any code currently uses out of the direct path. In a similar fashion it had been observed in the implementation of () that the type is also and . While it had been expected for - given that s are used to wake-up tasks from different threads, it might not have been for . One downside of s being is that it prevents optimizations. E.g. in linked ticket the original implementation contained an optimization that while a was not d (and thereby equipped with a different vtable) it could wake-up the local eventloop again by just setting a non-synchronized boolean flag in the current thread. However given that could be transferred to another thread, and called from there even within the context - this optmization is invalid. Here it would also be interesting if the requirement could be removed. I expect the amount of real-world usages to be in the same ballpark as sending across threads - hopefully 0. But it's again a breaking change cc , , ,
Even if this weren't a breaking change, I'd want to see some really good evidence these optimizations would matter for real world code before choosing to make these types non-. I don't think getting rid of an atomic update in is a compelling example. Basically, in my view the current API is intentional and correct.
was introduced to leave room for future unforeseen requirements, and being restricts its usefulness as such, which is unfortunate. I can see a case for since we have , but it's difficult to imagine a case where it makes sense to be accessing a single from multiple threads concurrently.
I have an example of where the current API is resulting in performance issues: I am trying to implement a combined Executor/Reactor around a winit event loop. To wake up the event loop from a different thread we have to post a message to the event loop which can be a non-trivial operation.


But on the same thread, we know that we don't need to wake up the eventloop, so we can use much cheaper mechanisms like an atomic bool.
But that would be true if wakers were just also, which was an intentional part of the simplification from the previous design.
I think the point is that being precludes the otherwise noninvasive restoration of a more efficient through an additional method on .
I don't think it should be the judgement of the libs team (or any of us) to determine whether something is good enough and not needs to be further optimized for any use-case. Rusts goal as a language is to enable zero cost abstractions. This requires in my opinion to not be opinionated on any design choices which have a performance/footprint impact. I think some of the decisions that have been taken in the async/await world however are opinionated, and will have an impact on use-cases that currently are still better implemented with different mechanisms. I do not really want to elaborate on anything more particular, because I fear this would bring the discussion back to a arguing whether any X% performance degradation is still good enough. That is an OK decision to have for a software project whichs needs to decide whether Rusts async/await support is good enough for them, and whether they have to apply workarounds or not. But it's not a discussion which will move the issue here any more forward, because for yet another project the outcoming of the discussion might be different. PS: I do think it's okay and good if libraries like tokio or async-std are being more opinionated about what threading models they support, and they might sacrifice performance gains in rare usage scenarios for easy of use. But and language features are different, and we expect people to use them also for niche use-cases (e.g. there is certainly a lot of cool evaluation going on with the use of async/await in embedded contexts or kernels - where requirements might be very different than for a webserver based on tokio).
This is a trade off: Context is either Sync or it isn't, some users benefit from one choice (they can use references to Context as threadsafe) and some users benefit from the other choice (they can have nonthreadsafe constructs inside the Context construct).


Ultimately the libs team has to decide one way or the other on these points in the API where there is a trade off between thread safety and not. However, this decision has already been made and it would be a breaking change to change it, so this discussion is moot.
Do you have an example where this is actually done within the ecosystem, or a use-case for it? As far as I can tell, this would require spawning a thread using something like and capturing the from within a ?
A common way a user could depend on a type being is to store it in an and send it across threads. This isn't very likely for Context but it is a very reasonable pattern for .
I think its a fair point that we didnt intentionally make context send and sync, and that this precludes adding more fields to context that are not send and sync, and that since context is just a buffer for future changes, it would probably have been better to make it non-threadsafe. But now its a breaking change. If crater showed no regressions and there's no known patterns it nullifies, I would be open to changing this about Context personally, but I am somewhat doubtful the libs team as a whole would approve making a breaking change to support hypothetical future extensions. If anyone on the thread wants to pursue a change to context (not waker), they should get crater results as the next step of the conversation.
There is no discussion about being or not - it obviously has to be. The question is purely about . And in order to do what you describe you have to store an and send it somewhere. Which is very doubtful to happen, due to the not very useful lifetime and due to already being an like thing internally. As mentioned, the most likely way to see this behavior is some scoped thread API being used inside - or people doing some very advanced synchronization against an IO driver running in another thread. For all those there are certainly better ways than to rely on being . E.g. to return a flag from the synchronized section and call from the original thread when done. Or to and send the if there is doubt whether it needs to be persisted somewhere else. And yes, the impact on is even bigger. It was meant as an extension point. But we can not add any functions to it which are not thread-safe. E.g.


if we want to add methods which spawn another task on the same thread as the current executor thread, and which allows for spawning futures (like Tokios ) - we would have an issue.
Why would these be "certainly better" than just calling from the scoped threads?
To be a little more expansive: the scoped threadpool you're talking about could very well not be scoped inside a poll method - rather, the waker could be cloned once and then owned by one thread and referenced by many other scoped threads in some sort of threadpool construct for CPU bound tasks. This seems like a perfectly valid implementation which allows you to divide up the work among many threads without cloning the waker many times. This is potentially an optimization. I don't think this optimization is very important, but I don't think the optimizations allowed by making waker are very important either. The point is that there's a trade off between the optimizations allowed by assuming references to wakers can be shared across threads and the optimizations allowed by assuming they can't be, its not the case that one side is inherently the "zero cost" side.
We discussed this at the recent Libs meeting and felt that deferring to would make sense here.
Though I don't have the bandwidth to carry this, this definitely seems interesting. Seeing projects such as and closed-source initiatives lead me to believe that there may actually be a decent case to enable some form of -to avoid the synchronization overhead on single-threaded runtimes. I don't know if we should make this a priority, but at least we probably shouldn't close it just yet.
I think bringing back would be a nice additional improvement. But for the moment it would be nice to just fix the general sync-ness, which blocks all other fixes and improvements.
As the person who originally introduced , it was very much a conscious decision to get rid of it and to make and . This was called out explicitly .
The cited discussion in the RFC justifies making Send, and predates the decision to (re)introduce . Making doesn't defeat the objectives discussed there. In particular, it does not impact ergonomics for the common case at all.
This was recently closed, however the issue mentions both and . The recent change only affects . There is good reason that is , however after reading this issue I'm unsure that there are good reasons why is .


(NOT A CONTRIBUTION) Waker supports wakebyref, and so it is possible to pass to another thread and wake it from that thread. This functionality would not be possible without Waker being Sync. Supporting wakers that are either not Send or not Sync will best be done by adding new APIs to Context and a new LocalWaker type.
Forgive me the naive question, but how does a type work with ? As I understand, requires , as a concrete type not a trait, so this would also require a trait? At this point we have two completely incompatible async systems... Which is only useful if is not cheap to clone, and has the burden of another lifetime bound. It surprises me that the docs don't say anything about the intended cost of .
(NOT A CONTRIBUTION) Future::poll does not take Waker as an argument, Future::poll takes Context. Context could have the ability to set a LocalWaker, so that an executor could set this. Reactors which operate on the same thread as the future that polls them could migrate to using the LocalWaker argument instead of Waker. Here is a pre-RFC that someone wrote with a possible API: Commentary like this is both factually wrong and not helpful for the mood of the thread.


The Switch terminator, which is used in pattern matching, is currently unimplemented in MIR. This terminator should load the discriminant from an lvalue and branch to the appropriate basic block target based on what is found there. It has to integrate with the code.


<!-- 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 and . The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- 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 these methods - see [x] Adjust documentation [x] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --These new methods are being introduced as an unstable feature to give time to validate their names, types, and documentation, before stabilisation. Implementation (with docs) is in , currently in review/rework.
fcp merge Check out recap of this API in
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.


Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
Broken by
Miri fix:
triage: miri breakage gets 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. --Saving a Hello World program as UTF-16: and trying to compile it causes about as many errors as there are characters in the file complaining of . Instead, using some heuristics to determine that the file is saved as UTF16 and printing a more helpful error message would be much friendlier to new users who are most likely to run into this issue. <!-- 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 --
claim
There's still a question. Should throw an error and exit, or read the file using UTF 16?
I do not think rustc should parse the file as UTF-16, as this would introduce an ambiguity. I opened this issue only to address the poor UX of the current error messages.
release-assignment This seems more complicated than expected, because I dont know any reliable way to check if the file is utf-16.
Maybe add a help message when output error "unknown start of token: u{0}".


<!-- 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
cc
Now fixed by errors, see rust-lang/glacier. However, the new error looks unrelated to and it might just be the case that it masks a still existing bug, not sure.
Fixed on the latest nightly, marking as E-needs-test (or, feel free to close if we have a sufficient regression test) labels: +E-needs-test


<!-- 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


cc
I think you have a PR that improves type inference in some cases where closures are involved (?), do you know if by chance that fixes this as well?
This is not closure specific:
This must be duo to . It seems to enforce the numeric fallback rule a bit too eagerly.
Another example from IRC is that type checked while didn't. Rather interesting.
edwardw, not just that, type inference regressed slightly at the time of the range stabilization PR.
also related
Have a partial fix by deferring numeric fallback, but it seems to hit now.
OK, so I spent some time digging into this. I don't think that deferring numeric fallback is necessarily the solution. sorry if I kept disappearing on IRC, I had to put my head down and study the log to see what was happening. So what seems to happen is that we correctly come up with the constraint: However, we are unable to make the connection between and . The reason is that the new has separate impls for each of the numeric types, whereas the old had only impl for a type . When we process the projections, we first try to resolve (without considering the output type ), and we get ambiguity, because there are many impls that could apply. Unfortunately this all seems a bit right to me. Basically we're trying to infer the type of the range from the output type, which is the reverse direction inference is supposed to go. When we used a blanket impl, we were able to resolve this because there was only one impl for . Probably the best fix is to go back to that, actually, but this is an interesting quandry. I'll have to think about it a bit.
To be clear, the example I was digging into was
Also, to put it another way: having a single blanket impl allows us to draw the connection that when you iterate over , you get . With the current setup of many distinct impls, that is not known to be true.
After some discussion with on RFC, I just wanted to clarify a few things (I myself was a touch confused too). the impl is probably the easiest way to fix this in the short term. , to some extent, this limitation is an artifact of how trait matching is implemented. That is, we intentionally do not take output bindings into account when selecting traits.


However, it doesn't have to be this way, but it'd take some work to massage the trait matching infrastructure, since impl selection doesn't presently have access to output binding information, that'd have to be propagated inward. It might be interesting to try and address this in a more wholistic way (i.e., something that accounts for the full set of facts that are registered). particular, the important constraint that we MUST maintain is that, during trans, given the input types, we can derive the output type. But it's permissible for us to use the output type to derive the input type during type checking, since once inference is done, we then have the input types to supply during trans so that we can rederive the output.
The fix is very simple then. Thanks for helping diagnose the problem and pointing to the right direction.


This code compiled fine before 1.0.0-nightly ( 2015-01-23 16:08:14 +0000): But with that version, it now gives this error:
changing to should work, I stumbled upon the same thing and the doc seems to be updated: (see at the very bottom) EDIT: Maybe worth noting that these work:
That's just a workaround to a bug (not sure if that was implied). should fall back to being as per the existence of the integer fallback.
I don't necessarily expect this to work. Fallback comes late in the process, once all constraints are known, but (like method dispatch) requires the type being cast to be known immediately.
It's plausible we could make it work since we know that the type is integral (I imagine that's how it ever worked, not sure what would have changed that, though it might have been something I did). It occurs to me though that this is somewhat forward-hostile to the idea of integer literals ever being used for anything other than plain ints (but enabling such a feature may well wind up requiring opt-in anyway).
(Though really it's sort of silly that requires the type to be known immediately, so I guess fixing that would be another way to ease the forward compat fears.)
I thought this was a feature because it's saying that it doesn't know if it's or for example. Would it assume it's signed only if it contains negative numbers in the range? EDIT3: what said makes sense: EDIT2: ignore the following, my bad But I might be missing something because this doesn't output anything from : EDIT: just realized -1u32 is too big so the following makes sense: There's no output from , unless using


Consider the following rust source (in ): It is obvious that it has syntax error. It also seems obvious that the generated error shouldn't depend on name of file except noting the name of file. However, it doesn't happen in practice: Note extra spaces after . Rust version (although it is not strictly relevant, see below): The core issue lies in the . The idea of the code is to make enough space in the beginning of line (filled with spaces) and then overwrite it character by character. However, in order to estimate the required space, which is wrong since in Rust can contain non-ASCII which require more than one byte for storage and keeps lines in s. It means that this isuue reveals itself only when a non-ASCII string is passed as an argument — and that's exactly what's happening in  under very specific circumstances: when processing a primary file, when is set (i. e. ) and when_ name of the primary file happens to have a non-ASCII name. The errorneous code for was introduced in . This bug landed in stable . The obvious fix is to change the line in into cc
I want to raise a question: is it really an issue worth fixing? It fires under very specific circumstances and the fix makes slower for every case, not only these specific ones.
I believe so.


EDIT: Removed talk of variance, since it doesn't seem to be the cause and it was unnecessarily longer due to it. It seems to me like is an attempt to introduce the second approach from the of RFC 738. It seems to me that the commit is actually a breaking change, because it broke my code without my changing it. Consider this reduced example (thanks to for helping me to reduce it further). This overflows on the recursive requirement evaluation: I attempted to bump the recursion limit to 2046 even and it just told me to try again with 4096, so I figure it's just going to infinitely recurse if allowed. This only seems to happen if I use a reference, so I think that has something to do with it. came up with an example that actually hangs rustc completely when using a recursive type: The real-world scenario that led me to this bug was a with keys:
cc
My suspicion (which I removed from the first post because I'm not quite sure if it's the reason) is that it has to do with variance. Creating my own similar to the one in rust but with a instead of a , OR with instead of seemed to solve the issue, but again I'm not sure if that's the reason. I figured it was because is ok to have as a covariant but must be an invariant, from my limited understanding of variance.
(More) reduced test case (reduced in that it's isolated from the stdlib): there is in fact an interaction with variance. The problem is that the "infinite cycle" detection doesn't seem to be kicking in here because an endless set of new region variables are being generated. This is probably due to the variance of . I have to think on this a second.
(Er, the variance of various things. :)
So I've kind of thought this through. I think the right fix is to enhance the trait matching system to understand that there is in fact no need to keep generating new constraints. This seems to be a bit complicated (it interacts with, among other things, ). The short-term pragmatic fix is probably to modify MarkerTrait to be invariant, not contravariant. This is stricter than necessary but probably not terrible. The implication is that if one knows that e.g. holds, that alone would not be enough to conclude that .


It is probably possible for us to loosen this in the future, even after 1.0, though strictly speaking it would not be backwards compatible. (I guess a more limited fix would just be to change the variance of and specifically.) (The reason it is not 100% backwards compat is because impls that are not overlapping for an invariant trait can overlap for a contravariant trait; but this is unlikely to occur except for with object types.)
I plan to work around this problem for now by changing the definition of . The underlying issue has been splintered off into .


<!-- 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 --
cc for ClashingExternDeclarations in backtrace.
claim
Thank you for fixing it! There is nothing better than software with only a few open issues.
Not a problem! Thank you for the report, and especially for taking the time to make a minimal example :)


Currently in , Rust is hooking into the glibc extension for retrieving / even in case Rust does not manage and is e.g. just loaded into a process as a . While this is great and convenient, it's unfortunately not implemented in a safe way. Various C commandline argument parsers are modifying while parsing, so the information that gets passed into might not be correct anymore. Examples of such parsers are glibc's own  parser, noting " The default is to permute the contents of argv while scanning it so that eventually all the non-options are at the end. This allows options to be given in any order, even with programs that were not written to expect this. " GLib's  parser, which removes all already handled arguments from and only leaves others (removed ones are set to and moved to the end). Qt does the same thing in in . It shuffles around arguments in and removes (by setting to ) arguments it handled already. This means that at least can easily be too big, and Rust would read beyond the (new) end of . This caused crashes in because of calling on when creating an around such an "removed" argument. Now the question is how this should be handled in Rust. I see three options here Remove the extension usage and handle glibc like all other libcs Copy all arguments in . This means everybody has to pay for that even if they don't use arguments, and this is theoretically still not safe if the shared library is loaded at the same time the array is modified and a partially written pointer value is read Handle pointers in by skipping over them. This means we would lose the exact length information of the iterator, and this is still theoretically not safe for the same reason as 2. See This code was in 2019 by (CC I've created as a proposed fix for this, which implements option 3. : <details<summaryBacktrace</summary<pAlso </p</details
Arguably swapping two entries of is still a lot less dangerous than setting one to NULL -- it seems totally legitimate to assume that there are no NULL pointers in , and does not insert any NULL there either. So what GLib does here is certainly questionable, more so than what does. That would be a data race.


However, just like multi-threaded programs cannot mutate the process environment or write to the global pointer ( is inherently unsafe if there are other threads; also see the discussion in ), I would argue that multi-threaded programs cannot mutate . Global state such as or is inherently read-only in a concurrent program; there is just no way to make mutation safe. So, I think for concurrent programs we can already assume that there are no concurrent mutations, and if there are then that is a bug in the code that performs the mutation. What remains is the question whether we should adjust the args handling to be able to deal with NULL pointers in .
The problem here is that this behaviour of GLib exists since literally decades, and I'm sure we'll find other commandline parsers that are doing similar things if we search a bit. My first reaction also was that this feels like something to fix in GLib, but that doesn't seem to be a practical resolution because of the above. Skipping over s seems to be a relatively cheap mitigation if we decide that concurrent modifications of are simply wrong (who even does that! also seems less likely than ).
I can't judge how common it is to add NULLs there, and don't have an opinion on whether we should support that -- let's see what says. If you know of another library doing this that could be useful, though GLib doing it for decades on its own already means this is quite wide-spread. I hope GLib does this before any threads are spawned, because otherwise I'm afraid that is just inherently doomed.
I'll search a bit later. An application could surely do that, but that's just asking for problems and I wouldn't really worry about that. The following would work around this FWIW. Maybe should be conditional on glibc.
nit: s/Same/Some
Qt does the same thing in in . It shuffles around arguments in and removes (by setting to ) arguments it handled already.
's library is not affected because it always copies each string directly into a vector and then operates on that.
Another approach would be parsing . Doesn't work if proc isn't available, but so do things like .
is created by the kernel reading from the original location of argv (as specified by the auxiliary vector). If you edit argv, so will the commandline reported by the kernel.


Skipping over NULL seems less safe; would it make sense to just stop at the first NULL?
To the best of my knowledge, it's completely valid to parse argv by stopping at the first NULL; if an argument parser is replacing an argument with NULL, it should not expect that arguments after that point will be seen. I've seen plenty of C programs that just do or equivalent.
For the commandline parsers from GLib and Qt that would be sufficient, yes. Considering the below, it seems OK to do that and there shouldn't really be any risk of missing useful arguments. TIL that is -terminated. Thanks for pointing that out :)


Steps to reproduce: Alternative steps to reproduce that will provides a suitable compiler: On OS X, with LLVM assertions disabled (like in rustc builds in , which are the default in Servo’s ), rustc 1.20.0-nightly ( 2017-06-28) fails with: This problem does not occur with from rustup, which has LLVM assertions enabled. (But perhaps that’s not the only difference between the two kinds of builds?)
What’s ?
It’s also enabled in the "non-alt" build, so probably not relevant.
Have you tried building the project in the same disk partition where you've installed rustc, i.e. inside ?
Yes. With the second set of steps (and ), the error message looks like this:
Does show anything special?
not as far I can tell.
Okay... There are for dyld but I doubt if they are useful. The problem is that is not found, meaning is not expanded properly. I've checked does not* have an load command, meaning the is only supplied through . I don't think the alt-build's and normal build's Cargo has any difference though. Verify if is correct?
with and without in : Both contain:
Both contains directly inside ? (not )
Almost, the one has a different hash:
Huh, that's even stranger. The should be resolved correctly. But the alt- rustc linked using the libstd from the non-alt-build??
Well it sounds unlikely to me that “from the other build” is really what’s going on, I’d bet on incorrect hashing. How is the hexadecimal part of determined? What base values are being hashed?
IIRC rustc will just search for all , it doesn't recompute the hash. Would it work if you move out of , and then do a + ?
I first hit the issue before the "non-alt" build was downloaded.
I've tried to reproduce it myself and it seems plays a role in finding which is linked. I can make it link to the correctly hashed by: "Install" it sure does not contain , and includes it. It should work. Overriding without installing causes rustc not able to find .
What is "it" and what does "installing" mean?
Run after extracting the tarball (sorry was on mobile so did not check the exact instruction).
What does this do besides copying the files?


Regardless, this is a regression, it only happens on OS X, and only with "alternate" builds…
It looks like the problem is presumably that and don't have the same hash. One fairly clear problem is that Servo for some reason doesn't download rust-std from alt by-default AFAICT; having some quick prints to the util script. That would lead to incompatibilities; this should be fixed.
I've filed which should fix this.
Good catch! This fixes the problem, thank you.


has an unusual format: it takes as it's first parameter where everything else in the trait takes . It should take as it's first parameter for consistency with everything else. It is located in
+1. There are a few different things to consider here, though: does not operate on any FP number per se like most other operations do, but rather constructs a new FP number from two arguments one of which happens to be FP number. This function’s signature is consistent with most other methods that construct some kind of FP number (e.g. ). We might want to consider whether methods such as shouldn’t just go ahead and take instead. can’t currently be chained, but I see literally 0 cases where anybody would chain this function. cc
Okay, but from a consistency standpoint, it's like 1/80 for vs . It it keeps the same format, it and it's similar functions would probably be better to go at the end or beginning of the function list where they won't be so unusual.
Nominating for 1.0-beta P-backcompat-libs
One should be able to call this thing as a method, one way or another. We need to make sure that is resolved.
0 beta, P-backcompat-libs
I started to fix this.


<!-- 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. --Hey! I was trying to make it work somehow with , when the function depends on the other generic parameters. I came to this approach and encountered an ICE. <!-- 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. --: <details<summary<strongOutput</strong</summary<p</p</details
label requires-nightly F-typealiasimpl_trait
Regression in nightly-2023-02-22 Regression in cc
still crashing, rustc 1.77.0-nightly ( 2024-01-08)


<!-- ICE: Rustc '' 'error: internal compiler error: node HirId(DefId(0:32 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments::{constant}::checktrybindstighter).22) (pat ) cannot be placed in TypeckResults with hirowner DefId(0:22 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments)', 'error: internal compiler error: node HirId(DefId(0:32 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments::{constant}::checktrybindstighter).22) (pat ) cannot be placed in TypeckResults with hirowner DefId(0:22 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments)' File: --auto-reduced (treereduce-rust): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to cc


<!-- 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. --: <details<summary<strongError output</strong</summary<p</p</details<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2022-09-05 commit[0] 2022-09-03: Auto merge of - cjgillot:old-no-lt, r=estebank commit[1] 2022-09-04: Auto merge of - matthiaskrgr:rollup-9n0257m, r=matthiaskrgr commit[2] 2022-09-04: Auto merge of - nikic:update-llvm-7, r=cuviper commit[3] 2022-09-04: Auto merge of - jswrenn:transmute, r=oli-obk commit[4] 2022-09-04: Auto merge of - klensy:bump-deps-08-22, r=Dylan-DPC commit[5] 2022-09-04: Auto merge of - compiler-errors:head-span-for-enclosing-scope, r=oli-obk commit[6] 2022-09-04: Auto merge of - matthiaskrgr:rollup-uj24yb5, r=matthiaskrgr commit[7] 2022-09-04: Auto merge of - asquared31415:vec-zero-opts, r=thomcc
Minimal: This has nothing to do with the transmutability feature. Also, it's fixed by , since the above desugars to:
WG-prioritization assigning priority (). label -I-prioritize +P-medium -needs-triage
This is but needs a test. To whoever does it, please commit the example I minimized and not the other one, since we don't need to make the test depend on the transmutability feature.


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!
That PR was a rollup. Without having looked at any logs, Edit: Oh uh, nope, sorry, had a different change in mind. Will take a closer look. :)
Ah, the problem is The call to was changed from to try first. Returning null there would work fine, as it still falls back to . Edit: And the same for .


Miri is in "test pass" state in https://rust-lang- since rust-lang/rust and rust-lang/rust has been closed. Also I didn't found , so I assume Miri should build from the branch of it. However, Miri in the latest nightly (, rust-lang/rust from . rust-lang/rust already contains rust-lang/rust. Actually Miri is missing since , and is still missing even rust-lang/rust has been merged. I can't find any additional information about Miri in the latest nightly. What's going on with it? Edit: I mentioned the wrong PR. It should be instead of .
Oh, I had not even noticed this, thanks! This looks like a rustc issue, so I'll move the issue there.
Cc any idea why Miri is missing from ?
The log at looks good in terms of tests, but one thing is strange: Notice the "test-fail" for "cargo-miri". However, I don't think anything actually cares about that test state, so I am not sure if this is actually a problem. I guess something is going wrong when doing the nightly release (Miri has special logic there to avoid shipping when tests fail), but I do not know how to access the logs for that.
Thanks for the report! This is a bug in our release process: Release process logs are not available publicly unfortunately :(
rust-lang/promote-release has been closed, but Miri is still not available due to . Maybe Miri will be available tomorrow and this can be closed then.


File: auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2021-04-12 finding bors merge commits found 9 bors merge commits in the specified range commit[0] 2021-04-10: Auto merge of - Aaron1011:new-preexp-tests, r=petrochenkov commit[1] 2021-04-10: Auto merge of - Aaron1011:derive-invoc-order, r=petrochenkov commit[2] 2021-04-11: Auto merge of - RalfJung:liballoc-miri, r=Manishearth commit[3] 2021-04-11: Auto merge of - nagisa:nixos-patching-fix, r=Mark-Simulacrum commit[4] 2021-04-11: Auto merge of - JohnTitor:issue-, r=estebank commit[5] 2021-04-11: Auto merge of - Aaron1011:feature/final-preexp-tts, r=petrochenkov commit[6] 2021-04-11: Auto merge of - LingMan:patch-1, r=nagisa commit[7] 2021-04-11: Auto merge of - tweksteen:androidsetmessage, r=m-ou-se commit[8] 2021-04-11: Auto merge of - hyd-dev:uwtable, r=nagisa
claim
Reduced reproduction:
claim


Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!


I've tried reducing this but wasn't really able to so far. I might try again some other time. The code below currently ICEs on Nightly (). When trying to reproduce locally for the backtrace, I had an older Nightly first () where this actually didn't crash the compiler, so it's apparently a regression. <details<summary<strongBacktrace</strong</summary<p</p</details
This is my first time using cargo-bisect-rustc and it's fantastic. It identified the regression as... searched nightlies: from nightly-2020-02-13 to nightly-2020-05-14 regressed nightly: nightly-2020-03-20 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
is a rollup commit. The only PR which was part of that and (to me) looks like it could have caused this issue is .
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.


produces: <details</detailsIt should not be possible to access the type parameter in the type of the const parameter. cc Thanks to for .
Hi, I am new to rust compiler development and have decided to try to fix this issue to get started. If I understand the const-generics RFC correctly, type parameters can not be used in a const generic parameter because it cannot be ensured that the actual types have the "structural match" property. However, checking reveals that fn pointers (as well as raw pointers and empty arrays) always support structural matching, regardless of the types used within. My question is: is there another reason why const generic parameters are not allowed to use type parameters? If so, I think an additional check has to be to .
Actually, I think I may have interpreted. It looks like this example is intended to work to me. cc just to clarify.
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.


<!-- 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
Probably related to
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.


<!-- 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":


Here's a minimized version of the code I'm working with: Compiling this on stable or nightly gives a warning on the indicated line, despite the attribute on . A similar issue was reported before in , and addressed in a follow-up PR , but it seems to be cropping up again here, maybe because a non-ASCII field name is involved. It was agreed in that punning of non-snake-case fields in patterns should not produce an additional warning, so I think this is a bona fide bug. (Incidentally, on stable the same warning appears twice in the compiler output, but this duplication seems to be fixed on nightly.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It's actually unrelated to the non-ASCII field names; reduced: claim
Thanks


A code attached below used to compile with rustc 1.48 (stable) and stopped to work with 1.49 (stable). Two thing help to make the code compile: 1) comment out 2) explicitly deref . To compile code below one need to add to dependencies. Maybe this is due to some conflict between ArcSwap instance method and Access load method? I tried this code: I expected to see this happen: It should compile properly (it worked with rustc version 1.48 and earlier versions as well). Instead, this happened: I got compilation error It most recently worked on: Rust 1.48 :
searched nightlies: from nightly-2020-10-01 to nightly-2020-11-14 regressed nightly: nightly-2020-10-07 searched commits: from to regressed commit: () <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning as discussed as part of the and removing .
:
The examples now print actionable feedback for the user, in the form of errors complaining about multiple applicable impl's. For example, the now prints: So I think this might just need a regression test. label: E-needs-test


Godbolt: Basically the issue is that you compute , check that it doesn't overflow, and then you verify that is greater than , which it of course always is, since you checked for an overflow! This is probably an LLVM optimization bug, but I'm starting here :-) Command line arguments: Source: ASM:
Slightly reduced testcase: LLVM does not realize that and are the same here.
Ok, looks like the thing to do is file an LLVM bug -- do you know off hand if they're ok with Rust reproducers, or do they prefer C ones?
Ok, ended up converting to C because that seemed easy:
Submitted additionally for the IR pattern above (which is an issue separate from the missing combining). Just verified that fixing this does indeed eliminate the check in this example.
am I correct in reading that this has been waiting on a review of the LLVM patch?
Needs a rebase. More generally though, I think this is fighting a losing battle. and are not considered canonical IR for a reason: They optimize badly in the middle end. I think we'd be better off with generating the canonical variants instead (which are and ). LLVM will still form during CGP, but this should optimize better in the middle end (including avoiding the issue here). As we already have a good benchmark for the overhead of overflow checks in , I think it might be worth trying to rerun that without using the unsigned overflow intrinsics.
From the :
once this makes it's way into Rust's LLVM (is there a good way to track this?) I'll verify that the assembly in this bug was improved, and if so I'll rebase the rustc patch and we can get some new numbers!
Ok, confirmed that the recent LLVM10 update removes this branch: Shall this be closed?
Actually, that was probably premature. We should add a codegen test.
is there a good example of what a test looks like? I can spin one up pretty easily if someone can point me at how to add one.
Codegen tests are located in . One test that is thematically related: . They use . Codegen tests can be run with:
Thanks much, that's exactly what I needed! PR is up now.


mentioned a leak coming from but not , I think I tracked this down to the use of in when given a comma-separated list. I've made that demonstrates it with , if it gets much simpler than this then the leak doesn't occur when built with --release. I'm testing on rustc 1.37.0-nightly ( 2019-06-30) nightly-x8664-pc-windows-msvc, targeting x8664-pc-windows-msvc.
Valgrind Memcheck also reports heap in use at exit on a Linux VM with the test linked above.
Thanks a lot for creating a reduced test case and creating this issue here. I stumbled over the original issue when carg-fuzz reported a memory leak in this code This PR appears to fix the issue This was also with rustc 1.37.0-nightly on Linux. I can check if I can repro with the fuzz test case on other platforms.
Looks like the early return doesn't interact well with box syntax's preallocation. MIR generation issue? cc
should be here: Now that can only schedule drops for locals, we should get the type from to avoid this sort of problem in the future.
Confirmed with my fuzzing test case that the problem is fixed in the latest rust nightly. Thanks for fixing it so quickly.


See the case in .
Not critical for 0.6; de-milestoning
-- does it make sense for the AST fold to visit macros? Or is the current code correct?
From my perspective: yes, definitely. In particular, I'm going to want ident-folds to hit the idents inside of macro invocations. Could it break code to add this traversal? Well, the only place you're going to see unexpanded macro invocations is prior to expansion, and the only thing inside of macro invocations is tokens, so it seems very unlikely. To summarize: yes, this fold should visit macro invocations.
In that case, nominating for milestone 5, production-ready
accepted for production-ready milestone
I've implemented this in a local branch, I expect to push it soon (next two days)
done, now. FIXME removed downstream.