Bug originally found by , which I've then reduced. I tried this code: I expected to see this happen: Instead, this happened: code compiles successfully and onwards modify labels: +I-unsound +regression-from-stable-to-stable -regression-untriaged This does not occur if the implied-lifetime-bounds array is in closure parameter position; so it looks like a bug w.r.t. not properly checking the closure output type implied bounds?does not help (as of )
Bisected to nightly-2022-08-10: <- looks maybe interesting
you beat me by one minute :) cc for being possible cause of this unsoundness?
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler -needs-triage
Oh, neat it did turn out to be a new soundness bug instead of a dupe of . Thanks for figuring out this was a regression,
for we have a terminator calling , i.e. a function which returns . This does not include the implied bounds. Checking that is WF requires proving which succeeds without checking the usable implied bounds of the trait-ref. edit: there's a bit more to this than I thought
This soundness bug is effectively only reproducible via the traits because the impls for it are builtin and so a little screwy. An attempt to write an explicit impl for the builtin impls would require an explicit bound that holds which is not present on the builtin impl. There is an assumption that all it takes for an assoc type to be wf is the where clauses on it and the impl hold, and that all arguments in the traitref are wf. The builtin impls violate this by not having the required implied bound on the impl so we end up with being able to be proven wf without proving the implied bounds. When calling we check that the fn sig of is wf which is . Before we would check the normalized signature is wf so the return type would be which would cause us to prove . Now that we check the unnormalized_ signature is wf we end up never seeing the normalized form with the which introduces the implied bound. It is generally an invariant of the type system that holding should imply also holds. The fact that can be well formed but is not, is concerning. In an ideal world proving the traits would require also proving all the implied bounds hold but right now that is not possible afaik. A simple fix (albeit hacky until we make implied bounds desugared to actual bounds) would be to make us also check not just .


<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Nearly 50% performance regression between versions 1.71 and 1.72 when copying small byte arrays with platform (Macbook Pro M1). Used to track down the regression to I tried this code: I expected to see this happen: to run about 6,200,000 ns/iter like version 1.71 Instead, this happened: 9,159,412 ns/iter <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.71 More specifically nightly-2023-06-06-aarch64-apple-darwin 72 nightly-2023-06-07-aarch64-apple-darwin <!-- Provide the version you are using that has the regression. --: Searched nightlies: from nightly-2023-06-06 to nightly-2023-06-07 regressed nightly: nightly-2023-06-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-apple-darwin Reproduce with: </details modify labels: +regression-from-stable-to-stable -regression-untriaged
Here's a demo for :
Oof, that's massively worse. But even with a nice size (), it's still a small regression: We should probably revert , or limit it to very small arrays (<= 8 bytes / 1 usize? )
The original motivation of that PR is for arrays larger than that, so I'm not so sure. If I strip this down to just the pointer write it's not as bad, but it's quite clear that the problem is just x86-isel: Is that even good instruction selection?
Hmm, curiously looking at just the part of the push logic that copies the value, the assembly is entirely reasonable: then in the context of a "real" push, it somehow still blows up:
Here's a small tweak to try to fix this for 1.73:
I've opened to track the suboptimal codegen mentioned in Once a new nightly is out, please give it a shot and reopen if you're still seeing the regression.
On Ubuntu VM running on Ryzen 5950X this is far worse: 4x regression.
Things look much better with . Thanks for the quick fix!
Thanks for confirming! I'll see if it can make 1.73.


I tried this code: I expected it to compile successfully. Instead, this happened: It most recently worked on 1.72 Regressed in cc Originally reported in cc modify labels: +regression-from-stable-to-beta -regression-untriaged
WG-prioritization assigning priority (). label -I-prioritize +P-high


I tried this code: I expected to see this happen: The lint is allowed. Instead, this happened: The lint still triggers. (Applying to the entire module works). (I'm assuming that this is unintentional, thus reporting as a "bug". If this behavior is intentional, consider this a feature request to change it). Latest playground nightly:
The problem here is that the lint is associated with the private item, not the item which names it in its bounds:
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.


() never finishes building the crate (0.11.3) when building with optimizations. Regression is exactly in the LLVM 17 upgrade: <details<summaryBacktrace</summary<p</p</details modify labels: +regression-from-stable-to-nightly -regression-untriaged
WG-prioritization assigning priority (). is it clear by looking at he stacktrace what kind of code is involved that causes the issue? I'm thinking if a smaller reproducible can help. label -I-prioritize +P-high
Can reproduce also with (to skip installing the asm dependency)
Problematic IR: Based on output, it looks like we go into an infinite loop unswitching loop.
Here is a test case for :
I've filed This appears to be related to the new invariant condition injection.


The documentation of the macro currently does not mention at all that it also accepts optional format arguments, for example: Other macros like at least have the following sentence under "Panics": So maybe it would be good to do the following? [ ] Update the "Panics" section to be similar to [ ] Extend / adjust example to also show usage of custom message <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Any ? I mostly drew from the docs for , and I also took the liberty of cleaning up some of the formatting/typography.
Thanks! To me this looks good, but I don't know what the maintainers think.


When working on Miri I noticed "portable-atomics" gets rebuilt every time I switch between a check-build and actutally running tests. This boils down to being different between the two invocations: in check builds it contains but in test builds it does not. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Cc
HEAD: ! Seems working fine here.
I'll have to try if I can till reproduce. But note that I mentioned "test build" above, so this would be vs .
Yeah I can still reproduce the problems with those invocations. (It's not the latest master but recent enough: .) Sorry for not giving the exact commands in the issue description.
I missed the tests part, sorry. I just reproduce it too. I will be working on it by the coming week. claim


File: reduced: original: Version information Command: Program output:
cc
Some notes dump: the original test fuzzed into this MCVE is . NLLs and do compute the same scopes on that original difference in scopes here is on a somewhat ambiguous case in the current implementation: the loan ultimately flows into via member constraints, not a regular outlives constraint. NLL still computes a scope for it, doesn't since it considers the loan to escape the we ignored the member constraint here and computed the scope anyways, it would result in the same results as NLLs and not trigger the assert. A handful of other tests would then fail of SCC member constraints difference between this test and these other 4 seems to me to be about applied member constraints. That is, in this test the member constraint is likely not applied, so maybe the loan should only be considered to escape via these. We had discussed this very subject before, but thought the distinction didn't matter for the purpose of computing scopes -- maybe we were wrong in these edge cases. That should be a correct fix and should work on these 5 tests. So I'll look into that next.


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


<!-- 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. --We have this code in our project on commit from line 44 and beyond: I expected to see this happen: running the doctest with the following command should work (note that we modify the release profile to have lto = "fat" enabled): Instead, this happened: the program crashes, compiling the same code in a separate example and the same cargo configuration results in an executable that works. Turning LTO off also makes a doctest that compiles properly, indicating LTO is at fault or part of the problem when combined with doctests. It has been happening randomly for doctests on a lot of Rust versions but we could not identify what the issue was, looks like enabling LTO creates a miscompile where a value that is provably 0 (as it's never modified by the code) is asserted to be != 0 and crashes the program, sometimes different things error out, it looks like the program is reading at the wrong location on the stack. The value being asserted != 0 is in Unfortunately we are not able to minify this issue at the moment as it's not happening reliably across doctests. <!-- 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. --: Unfortunately on nightly (used to recover the doctest binaries via RUSTDOCFLAGS="-Z unstable-options --persist-doctests doctestbins") only exhibits the crash for the parallel version of an encryption algorithm used with rayon (on current stable we can also get the crash with a serial algorithm but we don't seem to be able to recover the doctest binary). The archive contains the for the code compiled as an example (running fine) and the code compiled as a doctest exhibiting the miscompilation, if needed I can provide the binaries, but I would understand if nobody would want to run a binary coming from a bug report. Here is a snippet of a backtrace with two threads erroring on two different issues (while there is no problem having the same code compiled as an example). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</detailsWe have also seen some flaky doctests on x8664 and could not narrow down the issue, we have turned off LTO for all of our doctests for now and we will monitor how things evolve, the reason for the suspicion of an issue on x86 as well is that M1 builds have been running with LTO off for months and have never exhibited the flaky doctest we saw on x8664, though given the compiled code in that case is significantly different (intrinsics usage being one factor) we can't yet be sure a similar issue is happening on x8664. Cheers
have you run the tests with miri to make sure that no UB is happening?
Hello not yet, I guess it's the occasion to use it, I'll report back
Should I try it on the example reproducing the doctest or is there a way to run it on doctests ?
I forgot whether Miri runs doctests. But you can just extract the doctest into a binary and run that.
Hello no undefined behavior found by MIRI, it seems rayon does not terminate its threads so MIRI detects that but the doctest taken out as an example is UB free (I adapted our crypto parameters to be very small but still trigger the crashing doctest). Cheers
adding I-unsound as this looks like a miscompilation. The next step would be to minimize the issue and create a smaller reproducer.
agreed, for now it's a bit hard as we used to hit that a bit randomly until we identified it seemed linked to doctests + LTO, we will try to find a way to minify it, in the meantime the assembly in the original report should already contain the miscompiled code (though I understand it's likely way too big for a reasonable analysis) Cheers
FWIW, a pattern I've seen a few times with doctests + fat lto is that doctests are unoptimized, so you get optimized IR from LTO fed into the backend with disabled optimization. This can expose bugs in FastISel that we don't otherwise hit. The key to reproducing it outside doc tests may be to use an lto=fat opt-level=0 configuration.
Thanks will give it a shot, I'm surprised doctest don't honor opitmization/configuration from the Cargo profile though any reason for this? If the various parts are not supposed to have mismatched opt levels then yes I can see how some hypothesis done would break at the junction of the optimized code and unoptimized one
For the doctest as an example binary with the lto=fat opt-level=0 configuration I cannot get it to crash
setting the opt-level=0 in release allows the doctest to pass as well, so a mixing of LTO and non 0 opt level seems to trigger the issue for the doctest, trying to minimize the repro case
setting opt-level=1 in release with LTO=fat crashes the doc test
Hello again, some news, I have a state where I'm able to trigger the crash at will with a single line being uncommented. the repro branch is here MIRI is still OK on the doctest taken as an example. The interesting part is in here, the line below will cause the doctest to crash when not commented, i.e. that function call has the issue, when commented out and inlining the function (i.e. the rest of the doctest below) the execution goes well. I will attach the dump of the assembly for both. nokfunctioncall.S has both the call to the function and the inlined version okfunctioninlined.S only has the inlined version run MIRI Run doctest
still feels like the wrong part of the stack gets read in the function where a value should be a 0 and something else is read from who knows where edit: will try to minify some more
With some logging from the inlined non bugged version Edit: the "MIRI run done" was a check for the MIRI example, I share the code between both, both runs here are normal runs from the function call bugged version looks like the first iteration of a loop is fine but then the data gets corrupted here the native modulus 2^64 is encoded as 0 in a u128, so the 2^64 are valid, but the is random data and seems to be changing from run to run
looks similar in spirit to with the sensitivity to opt levels, though I'm not familiar with the mir opt level
Hello, minified the example to an iterator call returning corrupted data when a specific feature (on which the code does not depend) is enabled. Disabling said feature makes the code run properly, changing the iterator to be an immutable iter does not cause the issue () The iterator in question is a wrapping lending iterator that is defined in , immutable variant is here Available here Run the doctest and crash it : Run the doctest and does not crash : Tried to take the code out to a different repo, it did not repro Let me know if there is something more I can do, but here I can't seem to minify it anymore than that at the moment
I can reproduce the crash on aarch64-linux after also enabling the seeder_unix feature. I'm not sure how to debug though -- it doesn't seem like rustdoc has any support for that at all? does nothing and neither does . How do you even get the executable it generates? Passing to rustdoc does fix the issue, so this looks like another "passing O3 IR to O0 backend" issue.
I do the following (notice RUSTDOCFLAGS) : then and copy the only executable found in there Yes I agree with the O3 thing, I just don't quite get why rustdoc does not use the configuration from the cargo profile provided in the command line Edit: I'm guessing it's not an easy problem and there may be a reason for this
should there be a rustdoc specific bug report somewhere ? I have to say I posted here mainly because I found an old issue that looked similar
Thanks, using worked! I've used this LLVM patch () to identify as the miscompiled function. This is the extracted IR: Yes, I think that would be a good idea. I think this is probably a cargo bug, as doesn't get passed to .
Thanks a lot and great that you could find the faulty function! Alright then you advise opening an issue on to let them know of the opt level not being forwarded ?
Upstream issue: Yeah. It might be intentional, but it seems suspicious to forward but not .
WG-prioritization assigning priority (). label -I-prioritize +P-high


<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' 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
cc
Oh I see, nested or-patterns are usually flattened except not here because of the bindings! Fix incoming, thanks again


This is a common typo I make when hoisting an inconditional let binding into the let chain to merge two let-chains that could be one. The parser only needs to do look-ahead 1 and 2 to detect the case and recover. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


An iterator returns None if it is empty, but Peekable's isempty is defined like this: This needs to be changed to use isnone(). In fact, the code from testpeekableis_empty() fails. It looks like this escaped detection because of a missing "#[test]"
Whoops! Feel free to submit a pull request fixing it. :)


Hi there! I encountered a weird situation when writing a device driver using . Despite getting correct temperature readings in byte form from my thermocouple converter, all readings were incorrect after casting them to floats and applying some fundamental transformations. After much confusion, I tried using instead and found it worked perfectly! However, I knew the transformations should be correct either way: I tested this exact setup and formula using Linux and the crate. That led me to test those transformations on a few different machines. Please take a look at the results below to gain better insight. Arduino Device Other machines for all below MacBook Pro M1 on macOS and Asahi Linux () Linux () macOS () Ryzen desktop machine running Linux () Milk-V Duo () I can do more if you'd like! If there's any additional context I can give, or checking to be done, please let me know, and I'll happily look into it! Also, I did check the crate to see if it was working properly! I assume that since the and ufmt_float'd are the same, it must be an issue with itself. Please see and of the original test to get more info. Thank you for taking a look at my problem!
trying to figure out if this is a regression. I see that you tested on , does it also reproduce on other versions of the rust compiler? Did you try using a stable compiler (if usable for your project)?
AVR doesn't support 64-bit floats in Rust (operations on them should end up being linker errors, though ): The fundamental issue is that AVR intrinsics (e.g. operations for i32 or f32) require a special calling convention that hasn't been yet exposed from LLVM, preventing Rust's compiler-builtins from chiming in with its own implementation. Some intrinsics (such as those for i32, u32, f32 etc.) get implemented by linking the resulting AVR binaries with (that's why working with AVR requires avr-gcc), but GCC doesn't provide implementations for f64. tl;dr f64 is not supported, but (probably) should throw a linker error instead of trying to link with compiler-builtin's implementation (because that implementation uses a different calling convention than the LLVM's codegen expects) Edit: GCC does seem to contain proper impls nowadays (, actually) - maybe LLVM gets the calling convention wrong? I'll take a look over the weekend.
Alright, got it! -- fix at: (note that merging that merge request in compiler-builtins doesn't yet solve the issue here, because then I'll need to prepare another merge request bumping compiler-builtins inside rustc - all should be ready within a few days) As for the cause - since AVRs don't have a native support for floating-point operations, those must be implemented in software; usually implementations for things like that end up in a crate called compiler-builtins (linked above), which implements them in Rust using simple bitwise operations and whatnot. There's a difference, though, between the ABI as expected by LLVM and the code that's present inside compiler-builtins - for "bigger" types (like i64, i128, f32 etc.), AVR requires a special calling convention (which defines things like "which register should contain which value") that is not yet supported by compiler-builtins (and not so easy to expose there). So instead, we pull hand-written functions ("intrinsics") from GCC's standard library (which is why avr-gcc is required as the linker) - those functions use the correct registers -- but the linking order is that stuff from compiler-builtins gets linked before GCC's, that's why those invalid intrinsics have to be commented out in compiler-builtins (so that the avr-gcc can provide its own, correct definitions). This is exactly the same case as we used to have .
Woah, thanks for the fix! Sorry for not updating this issue for a bit - my wired internet hasn't been working, so I haven't had access to my Linux machine to test this functionality. Thank you for taking the time to get it working (and explain it to me)!


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


This code panics, but it should not: The panic disappears when the is inlined (because then we hit a different code path in ). What happens here is a bug in the logic that computes the offset of : since it is an unsized field, the offset is computed dynamically, by taking the statically known offset and then rounding it up to the dynamic alignment of the field. However, since the struct is packed, we need to cap the dynamic alignment of the field to the packing of the surrounding struct -- which we currently do not do. This is just yet another case where the non-compositional nature of is causing issues...
A slight variant of this code ICEs: It hits which, it seems, was never updated when support for was implemented.
WG-prioritization assigning priority (). label -I-prioritize +P-medium EDIT: lowered priority after discussion on Zulip


I believe the intention in let-else is that this code should be considered syntactically invalid, but it compiles successfully today. If you replace with , it correctly fails to parse.
I believe here is the missing case for ExprKind::ConstBlock: This should be changed to an exhaustive match so that future new ExprKind variants are forced to touch this code. Some other unhandled cases that can end in : ExprKind::Become ExprKind::FormatArgs ExprKind::IncludedBytes ExprKind::InlineAsm ExprKind::MacCall ExprKind::OffsetOf ExprKind::Yeet


and currently store pointers as , which is not ideal: They should really work with pointers and strict provenance APIs like , , etc. See a PR fixing a similar issue for some context: (note: in that one I ended up rewriting the whole thing, I think this issue requires far less changes). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(I do plan to work on this, but if you want to work on this instead — feel free to , I can mentor you) <subcc
claim
Could you briefly describe and , also a comprehensive insight about this issue would greatly help, although I had a look at which currently is an . If I understand correctly, we are building a for this and aim to improve existing implementations as seen in languages like C++ by making it more strict, and there is some discussion that can basically do most of what C++ can and this addition might have some diverging path. Let me know, so I can move forward!
claim
Hi strict provenance means that we aren't doing pointer-int conversions and only operate through pointer types like suggested by OP. and currently use which doesn't work under strict provenance. If you'd like I can work on this issue.
Did you mean to mentor me for the same? I would be happy to learn!
is already working on this issue, is this right? Let's not override other people working on it already unless they agree or it's been several weeks with no response.
Hi yes I am working on this issue. This is my first time contributing so it will take me sometime. I will reassign the issue to me.
claim
Hi Just checking in :) Are you still working on this issue?
Yup I am still working on this issue :)
Let us know on Zulip if you need any help
with this resolved, I think rustc is free from "fuzzy provenance casts" :)
Awesome :-)


The inliner strategy for dealing with storage statements is simple. If a callee local already has some storage statements, they are preserved as is when integrating callee into the caller. There are no new storage statements for such locals. Turns out this approach is unsound due to peculiar semantics of MIR. It is well defined to return from a function while there are still some live locals. At the same time it is undefined behaviour to execute StorageLive for already live local. Effectively inliner is obliged to end the storage for locals that are still live when callee returns, which it doesn't do at the moment. Arguably this is more of a bug in MIR semantics, then one in the inliner
hey would you like to first T-opsem discuss this? Maybe have this topic on a meeting and figure out a plan to fix this?
Oh, interesting catch. Cc Maybe we should just allow StorageLive on an already live local (and declare it to first implicitly free the local, and then make it live again)...


For this snippet (): rustc gives: Since , for const-able values, rustc suggests the creation of a constant binding. Here this is not possible because is not const fn. However, we can suggest instead.
Personally, I prefer over a separate binding. Even in the case, the generated code will call the initialization function many times. Maybe in the case where bindings are possible, we can suggest both? Where they are not possible, we don't suggest anything right now, so at the least we should suggest there. what do you think?
Once is stable we can suggest that :3. But until then sounds reasonable.
Agreed, good point about . It seems to have a stabilization PR open with an FCP, which is blocked: . Maybe there might be progress on it this month: . Even if we stabilize inline const, it might make sense to wait with suggesting it for a while so that we don't make code depend on the latest MSRV immediately. So therefore, I think that it might still make sense to implement this in the meantime.
I think this should (in the future) suggest  instead, since the function would only be called once if were , whereas calls it for every element.


The compiler struggles to optimize the for position on Iterators. Simplifying the implementation has increased the efficiency in various scenarios OMM: Old position(): #[inline] fn check<T( mut predicate: impl FnMut(T) -bool, ) -impl FnMut(usize, T) -ControlFlow<usize, usize{ #[rustcinheritoverflowchecks] move { if predicate(x) { ControlFlow::Break(i) } else { ControlFlow::Continue(i + 1) } } } self.tryfold(0, check(predicate)).breakvalue() Simplified version (There are several alternative implementations producing similar results as well): let mut position = 0; while let Some(x) = () { if predicate(x) { return Some(position); } position += 1; } None Bench results: <details </summary<br</detailsBenchmarks are named after the iterator and were run using . Ranges benefit massively (big ones by multiple orders of magnitude), while for other types, speedups are usually between 0% and 100%. A specific implementation for range calculating the position would of course be even faster, but I don't think position() is called that often on ranges. The implementation is similar to the one, which was introduced to reduce compile times , so perhaps this would help in that regard as well. However, the compiler appears to occasionally forget how to optimize the function after editing unrelated code. This also happens with the current implementation, so I don't know how reproducible the speedups are (FWIW Ranges have never failed to improve, though). I did not attempt to benchmark compilation speed, but according to the memory usage is down from 11.8 MB to 8.3 MB which looks promising. I was motivated by a on reddit, where some context and speculation can be found.
The -based implementation is likely intended to speed up position-finding in or iterators. So measuring range or slice iters doesn't exercise it well. That said, they should be equally fast for slices. Going through should end up with a very similar white-let loop. The call-tree is deeper, so this might affect optimizations. Have you tried compiling with 1CGU or LTO to see if that makes a difference? Benchmarks are fickle.
The godbolt example does show that try_fold version results in a few more instructions. looks like it's trying to do some branchless version of the accumulator increments here: while is an unconditional increment sitting in its own block. Maybe ControlFlow is not well-suited for carrying the value and the loop state at the same time? CC
I did some quick measurements for a chain of vecs: So the current impl does indeed work better for chains Yes, the difference is the ControlFlow abstraction Yes: No real differences though, results were with these settings. This made me retest an alternative I used previously (reducing ControlFlow size from <usize, usizeto <usize, ()): And this one actually beats the current one for the chain test: The chain_alt is even faster, but it's an attempt to keep the current style, updated for keeping the counter outside the fold: It isn't pretty, but it works The Assembly and IR are too long for me too really identify where the benefit comes from, curiously the faster version has more instructions, but I guess with all the jumps everywhere that doesn't mean a lot. I am interested in testing these more thoroughly, is there a nice resource with some real world data to test them on? Edit: Went digging in recent projects and I had a solution for Advent of Code Day 6 using .rposition() and .position() with the relevant part being: And changing to the alt version (with check(predicate, acc)) improved runtime from 8.8 ms to 6.2 ms, a 40% speedup! (I know there is an algebraic solution to the problem, but still)
You could make a PR and we can do a perf run. It doesn't have dedicated benchmarks that stress and I haven't checked if any of the runtime benchmarks make use of at all, but the compiler also makes use of it internally so it might show up in builds too.
Yes, we learned in that if you don't need move access to the accumulator -- either because is fine, as in that thread, or seemingly because you can , as seen here -- then it's better to use with a closure instead of needing LLVM to understand the threading through the +. (Maybe this'll be better once LLVM does better with 2-variant enums and stops losing information about them, but for now we're stuck with this.)


run Output: Miri: The underlying issue was found when reviewing the implementation of . The code is a reproduction to trigger the unsoundness. The implementation in question features: Where is turned into and dropped. Yes, that’s , not . The code for seems to be doing the same thing. For comparison: The code for (and the same thing for ) seems to properly use a … no actually, that’s a with zero lengths… notably the allocator is correct though. So the buggy code for should just switch to create a presumably. label I-unsound requires-nightly T-libs


creates an error string dynamically, then passes it as an unsafe pointer to , which then casts the string to , then to , then throws it to another task. Nominating.


<!-- ICE: Rustc '' 'error: internal compiler error: is not fully resolved', 'error: internal compiler error: is not fully resolved' File: --Another regression of snippet: 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: [checkmodimpl_wf] checking that impls are well-formed in top-level module [analysis] running analysis passes on this crate --
This is caused by the fact that  does not check for const effect vars when visiting . It should be relatively simple to match on in the folder.
Working on this one.


<!-- ICE: Rustc '' 'error: internal compiler error: cannot get associated-item of ', 'error: internal compiler error: cannot get associated-item of ' File: --another one caused by 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: [associated_item] computing associated item data for [typeck] type-checking [analysis] running analysis passes on this crate --
fyi
not caused by that, only exposed by it. The issue is a typo using instead of in diagnostic code, getting the wrong and then attempting to treat as an associated item


<!-- 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 ` <!-- 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 --
Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details


No response No response No response
I thought the intent with was to use it in a passthrough style, so you can insert it into existing expressions ie. becomes . In which case, maybe the lint should be for not using the value resulting from evaluating .
Not sure about the majority of users but for me is a convenience over . I use it without using the return value almost all of the time.
Probably a common thing to do, sure, but if we're talking about adding a lint, why not nudge the user in the direction of the intended and documented usage? You could at least do both: "insert into an existing expression or pass it a borrow" etc.
The fix in will only report a hint when there is already a happened. For example this code: before this fix the error is: with the fix, since there is already a error, the lint will try to find out the original macro, and suggest a borrow: The suggestion is not 100% right, since if we change it to , we need one more extra fix now(the return type is not expecting a reference), but there is a different issue, at least we have already moved one step on. If the original code is: Then suggest a borrow is a great and correct hint.
Similar in the scenario of function argument: original error is: new errors from the fix:
Would not also be a good hint? The suggestion wouldn't compile anyway right? Because would need to change to take ? Without involved, the compiler does indeed suggest that: Once that's addressed (whichever way it's done), once again becomes transparent, and eg. or works. does not, however, and I see why a "consider borrowing" hint would be good there. However, if you make the change first and leave as-is, the resulting error does not include the suggestion to change , which is unhelpful. (I agree that the message is even less helpful though, I'm not disputing that.)
Yes, it's a good hint, but from the implementation view of a hint, it's much harder to analyze the following code from the error point and then construct a new expression. Even it seems an easy thing for humans. You are right, the suggestion is not 100% right, we may need an extra follow-up fix after applying the hint, which is also a common thing in rustc diagnostics.


<!-- 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
seem like options that when paired together would cause issues... At first glance, I'm actually not sure why this is filed as a bug.
I agree. Nobody should be testing , I don't know why those passes are even in the codebase. But this is a bug. I've found this in real code with a much smaller set of flags: And this bisects to Bisected by hand, there's no nightly with that PR yet. Don't know where Matthias got that toolchain.
Afaict likes to do ICE testing against master
We just hit this on Fuchsia as well. I think we should revert the PR until we fix this issue and reland it.
Another one with
Also here's a list of files from the rustc repo that all seem to trigger the problem in one way or another
Looks like there is one more issue in GVN ():
There is no basis for the assumption that interpreter will never downcast to an uninhabited variant:
nice example! That assert was as an experiment to see if we ever hit that codepath, and it seems like the answer is yes. It should thus be removed, with a suitable const-eval test case.
I wonder if that code shouldn't have a read somewhere though... it is conceptually a match after all. Still, the assertion should go: That adds test, but not the others.
WG-prioritization assigning priority (). label -I-prioritize +P-medium


The user wanted something with "linux", and there is a name-value cfg that has the value "linux", so they probably wanted that. No response


I tried this code (as package ): Run the following, which will break at , step the next 4 lines () to define the variables, then print twice -- the first time will succeed, the second time will fail: I expected to see this happen: would work the same no matter how many times I called it, instead everything seems to be undefined after the first call. Below I show that seems to work (including multiple times), works (including multiple times), but after a single call to , neither of these works anymore: Oddly, if I break on filename / line number instead of function name, it seems to work as expected: I'm using from a git checkout from yesterday:
Realized was not a but an ; have changed to . Don't think it changes the rest, behavior still the same with .
Works just fine in gdb for me: Rust-lldb doesn't want to load for me at all, but plain lldb works fine too. For reference I'm using lldb version 14.0.6.
If only gdb worked on aarch64-darwin! But thanks for prompting me to try other OS -- I can confirm that I do not see the bug using rust-lldb on x86_64-linux, so this may be isolated to one of darwin / aarch64 / aarch64-darwin. (Still repros for me on aarch64-darwin with lldb 16.0.6.)


Crates with long type names result in a strange-looking error, see ! I've tested this on Chrome and Firefox, and by building the docs locally from I believe the text is rendering vertically due to long type names like which are auto-generated from OpenAPI. Link to original issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The issue is related to the rule which prevents breaking anywhere in the type name. Unfortunately using breaks . We even have a comment about the weird behaviour in the code, not sure how to fix this.
claim


<!-- 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<!-- query stack: [livesymbolsandignoredderivedtraits] finding live symbols in crate [checkmod_deathness] checking deathness of variables in top-level module [analysis] running analysis passes on this crate --
Bisects to nightly-2023-06-02 commit[0] 2023-05-31: Auto merge of - oli-obk:valtrees2, r=lcnr commit[1] 2023-05-31: Auto merge of - petrochenkov:strictflavor, r=lqd,wesleywiser commit[2] 2023-06-01: Auto merge of - Urgau:upliftcastreftomut, r=b-naber commit[3] 2023-06-01: Auto merge of - oli-obk:constevalstep_limit, r=fee1-dead commit[4] 2023-06-01: Auto merge of - Dylan-DPC:rollup-93zj7jw, r=Dylan-DPC commit[5] 2023-06-01: Auto merge of - saethlin:enable-sroa, r=oli-obk,scottmcm commit[6] 2023-06-01: Auto merge of - cjgillot:separate-const-switch, r=oli-obk commit[7] 2023-06-01: Auto merge of - Kobzol:try-build-skip-docs, r=mark-simulacrum ERROR: no CI builds available between and within last 167 days
Minimized:
Very likely btw.


<!-- 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
Regression from
Fixed in


<!-- ICE: Rustc '' 'error: internal compiler error: asm const cannot be resolved', 'error: internal compiler error: asm const cannot be resolved' 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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2021-12-16 lol commit[0] 2021-12-14: Auto merge of - matthiaskrgr:rollup-hjjyhow, r=matthiaskrgr commit[1] 2021-12-14: Auto merge of - Amanieu:stableasm, r=joshtriplett commit[2] 2021-12-15: Auto merge of - matthiaskrgr:rollup-cw9qolb, r=matthiaskrgr commit[3] 2021-12-15: Auto merge of - matthiaskrgr:rollup-jszf9zp, r=matthiaskrgr commit[4] 2021-12-15: Auto merge of - yaahc:track-caller-result, r=cuviper commit[5] 2021-12-15: Auto merge of - matthiaskrgr:rollup-rhajuvw, r=matthiaskrgr commit[6] 2021-12-15: Auto merge of - matthiaskrgr:rollup-2g082jw, r=matthiaskrgr ERROR: no CI builds available between and within last 167 days ~/vcs/github/rustbisect via v1.78.0-nightly too I would guess ? cc
Doubt it, that's just when the stabilization happened, there's no meaningful changes there
Actually bisects to which support for in .
label +F-asm +A-inline-assembly +F-inline_const -needs-triage
cc
claim


<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: value <= 0xFFFFFF00'', 'thread 'rustc' panicked at 'assertion failed: value <= 0xFFFFFF00'' 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: [mirdropselaboratedandconst_checked] elaborating drops for [analysis] running analysis passes on this crate --
cc
I cannot reproduce this with a local stage 1 build nightly and beta show this tho...
maybe this is a rustc miscompile? cc
I can reproduce this on aarch64-apple-darwin, and on beta.
The calls to seem bogus because index is potentially out of range (the valid range is restricted further in comparison to u32):
WG-prioritization assigning priority (). label -I-prioritize +P-medium


<!-- 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
I suspect this is related to cc
tests/ui/suggestions/unnamable-
Very likely. I'll take a look soon.
For the record: it was that caused this.


When running , this file is opened for me . I thought I'd use that file in my note taking application, which I have set to a dark theme. However for in that documentation is set to have the and the background uses the default color. This leads to the text becoming hard to read. ! I would prefer the text color not to be explicitly set, or if you insist on the dark gray text, making sure that the background color is also set to something light.
Transferred to rust-lang/rust. The CSS for this lives at
It's not rustdoc so to speak. I'll fix the issue.


I tried this code: I expected to see this happen: Both and can be inlined. Instead, this happened: <details<summarycargo asm</summary</detailsWhen using , it works well. Also, when I replace with , it works well. <details<summarycargo asm</summary</details:
I think this is an llvm issue related to inlining when the target features do not match exactly and when using inline assembly: is implemented using asm and has . This seems to prevent it getting inlined into functions with additional target features. When compiling for a specific target with all these features enabled it should get inlined, but this restriction makes it very difficult to implement runtime dispatch and get performant code. I'm currently facing the same issue, and plan to replace the asm implementation with one that uses the new rust intrinsic, but this only solves the problem for masked loads/stores. The problem also exists for the implementations of , for which there is not yet a rust intrinsic.


<!-- 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. --from Rustc will crash "normally" (expected as the bug is not fixed) but when trying to print the query stack, rustc will eat up all available memory which is BAD. <!-- 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
Its very likely hat this was caused by cc
This looks like again. It was fixed in , but the doesn't actually test what it's supposed to, because it doesn't check for the "end of query stack" line. (This also means that we currently have an UI that will fill up your entire RAM and then get killed.) The / calls are needed to fix this, not sure why they got removed.
WG-prioritization assigning priority (). label -I-prioritize +P-critical


The documentation for these methods state respectively: However these clearly return pointers rather than references. Later on they state the following restrictions, which make sense for references but it isn't clear to me that this restriction is necessary for pointers. At the very least the change needs to be made there too.
These are nightly-only traits that aren't particularly on-track for stabilization anytime soon, but yes, changing them to be correct on those counts would be fine.
Indeed, while it's nightly only I wasn't actually going to call it from nightly, but was looking because of it's use in other stable functions, e.g. . Would make a patch, but I wasn't sure whether to leave the undefined behavior line in or whether it should be removed.
It's still UB, yeah! This is partly because it still has to fulfill the safety conditions of . Obviously, that isn't a full justification: there is the question of adding until the pointer is offset to the "last element", which would not trigger "language UB" via that implementation detail... But the library defines it as UB, which means the implementation may include code that would cause an optimizer to see that it is "impossible" for the defined-UB result to happen. And the question of whether the "surface functions" have this obligation was settled in so yes, the same conclusion applies.


The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?


Replacing with in makes it compile, so it feels to me the RPIT version should be accepted too. This is minimized from the . bisected: searched nightlies: from nightly-2024-03-14 to nightly-2024-03-20 regressed nightly: nightly-2024-03-16 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details label F-type-alias-impl-trait
label F-typealiasimpl_trait
Strange that this is due to . I'll look into this :thinking:
This started passing in . I wonder if it's because we were erroneously defining an opaque to be equal to itself.
yea looks like it


<!-- ICE: Rustc '-Znext-solver=coherence -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: did not expect successful goal when collecting ambiguity errors', 'error: internal compiler error: did not expect successful goal when collecting ambiguity errors' File: --snippet: 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: [specializationgraphof] building specialization graph of trait [coherenttrait] coherence checking all impls of trait [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
regression in


<!-- ICE: Rustc '-Zsanitizer=cfi -Ccodegen-units=1 -Clto -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'', 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'' File: --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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I believe this happens since cc
seems to also cause problems
The core problem here is the encoding of the receiver on a object that has no principal. There's a fix for this in the larger patch stack I was breaking down to land piecewise. I'll upload it in a moment. claim


PRs are bouncing due to test timeouts. Nothing has landed since cc
Very, very unfortunately, just landed. This means that the breakage is not unconditional.
Segfault!
had also been reporting segfaults on master.
I got a segfault on
What is causing this?
Weird, seemed to make it through.
This appears to be because of a channel deadlock. Investigating now.
Fixed the deadlock, investigating the segfault now.


Sorry, I don't have simple code to reproduce the issue, because the project is large. The repro is this: Contents of the mentioned file is: I tried increasing , did not help. Also works on stable. This may be duplicate of because timing.
This is also affecting :
Using the starlark-rust repro, this bisects to
overflow is fatal in the old trait solver, so by proving additional goals, especially if they have inference variables, we can end up with new sources of overflow causing an error. the most straightforward fix is to use the new solver for this lint given that the lint uses an empty environment it uses pretty much the same parts of the solver as coherence so it should already be ready for that
WG-prioritization assigning priority (). label -I-prioritize +P-high
I have a somewhat minimal repro, it has a lot of deps (via bevy) but not much code: Where is not something (I think) that can be decomposed into a tuple.


<!-- ICE: Rustc '--edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'we captured CapturedPlace {'', 'thread 'rustc' panicked at 'we captured CapturedPlace {'' File: --snippet: 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: [typeck] type-checking [analysis] running analysis passes on this crate --
probably also caused by ?
yep ill put up a fix in a few


Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


The idea of changing a field to unit type to preserve field numbering makes sense for fields in the middle of a tuple. However, if the unused field is at the end, or it's the only field, then deleting it won't affect field numbering of any other field. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


: <details<summary<strongBacktrace</strong</summary<p</p</details
This looks to be a recent regression from cc and is on beta 1.79, but is just in diagnostics.


The for that function state (emphasis mine) However, the way this function gets called does not ensure that the alignment is at least the size of a word. Cc (discovered by failing CI in )


This crashes with every edition except 2015 :thinking: <!-- ICE: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed: ().isnone()'', 'thread 'rustc' panicked at 'assertion failed: ().isnone()'' File: --snippet: 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: [resolverforlowering_raw] getting the resolver for lowering --
Minimized:
:sweatsmile: while the "minimized" example is fixed, my original finding still crashes :upsidedown_face: cc in case you would like to have a look again


<!-- 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 --
rustc repro:
This ^ bisects to cc
This likely exposed a preexisting bug in cc previously was silently bailing when it couldn't deref a type it expected to be able to deref.
is most likely going to be removed, but this also reproduces with edition 2024 and : claim


This is a recent regression, starting with when is set, in my case to where I have prepared a locally built sysroot (that's ), then rustc now assumes it can find the linker in the sysroot, which does not work. See for some more details. It is new to me that the sysroot is supposed to contain the linker as well, is that expected behavior? Also the error message in that case is really unhelpful.^^ Maybe rustc should check that the path it sets for actually exists before starting ?
Yes. The blog post has a summary of that PR
That blog post doesn't mention the term "sysroot" so it doesn't help with my issue.
FWIW what I would have expected is that rustc searches for the linker binary somewhere around . Isn't that how we find some other things as well that are usually installed with rustc by rustup?
How do you handle windows-gnu? Imo this also uses a self-contained linker by default.
No idea. CI passes on Windows, whatever github gives us when we say .
Yeah the rust-lld linker has been in the sysroot since , is used by default in e.g. some of the wasm and aarch64 targets, and rustc had flags to opt-into using it since that PR. What is new is that it is now used by nightlies we distribute. bootstrap puts it in the sysroot when is true (and it's now the default on x64 linux under certain conditions), so you can also set that when -ing if you want it. It works with or without download-ci-llvm.
We resolve the sysroot from rustc driver, not current executable.
Yes, the surprise is just that the linker is searched in the sysroot and thus affected by --sysroot, rather than being searched directly. But I guess this is working as intended, I just need to add some more stuff to these custom sysroots then.
This broke cargo's CI since the build-std tests try to verify that nothing in the sysroot is required. Would it be possible to change it so that it will only require rust-lld if it exists in the sysroot (similar to windows-gnu and other targets)?
I don't know what we do on windows-gnu but we can do something similar, yes. I'll open a PR.
FWIW I managed to add tests for windows-gnu and they work like a charm. So no copying of files seems to be required there. Though I do recall xargo copying some things for windows-gnu so maybe I am not testing enough... but my tests do involve building a small program against the sysroot and running it, so maybe those files are just not needed any more.
We actually hit a binutils linker bug last week on windows-gnu (not windows-gnullvm), and the linker flavor there is gnu-cc, so do these targets really use rust-lld by default?
How does this work with cross-compilation -- I assume we are always taking the host sysroot even when building for another target? To me that seems like a sign that this shouldn't be part of the sysroot, it should be part of the rustc distribution. The sysroot is for target-related things.
In particular, I would expect that if I set to a folder that only contains a sysroot for some foreign target, then that should work if I also set appropriately (and use the right linker and everything). But currently that will then likely fail as it tries to search the host target in the folder, and with it will instead silently fall back to the slow linker.
They do use a self-contained linker from sysroot by default, but not rust-lld. We ship from binutils for those targets.
Thanks for the clarification. That explains why there's no existence check (and your 2nd hack for older GCCs in that other issue :). Locally, it was just using mingw's ld probably because of $PATH differences.
Linkers are generally target-dependent, so it's pretty reasonable to ship them in target sysroot, I guess. rust-lld is just applicable to a wide range of targets by being a cross-linker. Also there's no target vs host separation for sysroot in rustc right now, there's just one sysroot. Maybe there's some space for improvements here, it's just not many people use to notice any issues.
I still hope to migrate both rust-lld and mingw linker to the common directory layout scheme based on .
rust-lld is just applicable to a wide range of targets by being a cross-linker. If I'm on macOS and want to build for a Linux target, then the binary shipped in the sysroot is going to be completely useless to me. So in that sense shipping them in the target sysroot seems pointless. (Of course our cross-compile story is not great so such cross-building will hardly ever work, but it demonstrates the fundamental issue I was pointing out.) Even when I am on and building for I probably want to use a 64bit program for the linking, and not a binary shipped in the i686 sysroot -- this is e.g. how Firefox is (or was) built as 4GB of RAM (the maximum accessible to 32bit programs) are just not enough for linking. Given that these are binaries that need to be run on the host (i.e. the machine where the build happens), IMO the only sensible location is together with the other host stuff, i.e., where lives.
Ah I think I understand. That's right, and on macOS we wouldn't look for in the "x8664-unknown-linux-gnu sysroot" . You can try this locally on a helloworld (look for the path to ), from with a target:
Oh, so we always assume that contains a sysroot for the host and the current target. That's news to me as well (and Miri certainly doesn't guarantee it). But the fallback in your PR should solve that as well, I think.


For example, from (And many more.) I think this is due to Should we just drop these from ?
cc


() Like and the other ABIs, should not trigger and for non-FFI-safe types. Related: , ; tracking issue . No response No response_


When downloading the (and variant) target, the that ships with the compiler is broken: Upon further inspection, the symbols are indeed built for x86-64 and not LoongArch: It's not clear what causes this, but contains no corresponding definitions for . This issue appears related, in that it would catch whatever causes this:
cc


<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: alloc <addrand dealloc <addris printed Instead, this happened: only alloc <addris printed <!-- 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. --: forgets that it's been initialized with an allocator, and always deletes the node with the global allocator. There seems to be one more place where this happens in the same file. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim


The DEFAULTMINSTACK_SIZE is the default stack size assigned when creating a thread. This value varies across different platforms. The issue is that there isn't enough explanation as to why these values are different, and users might not realize that the stack size can vary. Recently, I was running existing Windows code on a WASI target, and I kept encountering font decoding failures. Since it worked correctly on Windows, I suspected WASI's instability and spent considerable time debugging. After several days, I discovered that the root cause was the stack size: WASI has a very small stack size of 4KB, while Windows has a much larger stack size of 2MB. Once I forcibly increased the thread's stack size, all issues were resolved. I felt quite frustrated that such a simple reason caused the problem. Although this is my personal experience, I believe that rather than setting different default stack sizes for different platforms without a compelling reason, it would be better to have a consistent stack size across all platforms in Rust. However, I acknowledge that this suggestion might not be very effective because the required memory can vary depending on the instruction set or architecture. I would like to discuss this matter further.
Different platforms have different useful minimum stack sizes. I have no idea why only 4KiB is reserved on wasi.
In my opinion, this isn't an issue of "inconsistency" this is an issue of a target having an absurdly low value, period. Please open a PR to raise it.
What are the criteria for determining that? Since I don't know, I can't tell whether the 4KB for WASI is inappropriate or not, and I also can't open a PR because I don't know the appropriate value.
...a zillion insanely low-level minutiae like how big the registers are, mostly. an article that might help: as that article explains, the smallest thread stack size of all platforms that I'm aware of, aside from the ones in our repo that only ask for 4096 bytes, is 64KiB. the current 4096 bytes boundary has caused you significant pain so it seems sensible to raise it to at least that much, then fool around and see how it works.
having done some review of our platform code, I am pretty sure 4096 bytes was just picked as the "unsupported" value and platforms that initially lacked thread support, like wasm32-wasi, just inherited that value.
I understand. The differences between the platforms are indeed huge..! Before proceeding, I would like to hear the opinion or history from Alex Crichton, the main maintainer of the wasi target. , could you please share your thoughts on this issue?
I commented a bit on but I've no recollection for the current value for wasi. I suspect it was a number of historical accidents that led to this, and stack sizes should definitely be larger than 4k by default on wasi. Thanks for the issue


<!-- ICE: Rustc '' 'error: internal compiler error: could not find allocation for alloc3', 'error: internal compiler error: could not find allocation for alloc3' 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: [evalstaticinitializer] evaluating initializer of static [analysis] running analysis passes on this crate -- label +F-extern_types
Regression in nightly-2024-05-23 cc :thinking:
Anyway it doesn't seem to affect the test.
This is not a recent regression, here's a reproducer on stable:
But why?^^ lol XD its just side effect of the fuzzing I guess :D


<!-- ICE: Rustc '' '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: [evaluateobligation] evaluating trait selection obligation [typeck] type-checking -- label +F-transmutability <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Ah, it's an uninhabited non-ZST!
claim
I guess that answers my ;)


I worked out this minimal reproducible example from some code I've been working on. Changing almost anything about this causes the compiler crash to go away, which probably makes it a little hard to figure out what's going on here. I've checked and performing a release build, or a debug build with an opt level = 1 will cause the compiler to SIGSEGV. Clearing the target dir, switching between stable/nightly, reinstalling toolchains, updating my system etc. didn't have an effect. Occurs in both Stable and Nightly. : : No backtrace was output. Also attempted to enable LLVM assertions and saw no change in output. Increasing stack size, as per advice, had no effect.
rustc 1.77.0 compiles OK. rustc 1.78.0+ crashes.
Crash in TwoAddressInstructionPass, appears to still occur on LLVM main.
Upstream issue:


<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'', 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'' 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: [resolverforlowering_raw] getting the resolver for lowering --
I suspect this could be cc
what's the command line to reproduce it? I build nightly version and cannot reproduce it by only compiling the code. also I checked playground:
Ok, got it, we can not use 2021 edition in the command line.


The struct is meant to not be constructible. Also the behavior is incoherent between tuple structs (correct behavior) and named structs (incorrect behavior). Also, this is a regression, this didn't use to be the case. No response No response
label +F-never_Type +D-inconsistent
We will also get such warnings for private structs with fields of never type (): The struct is never constructed although it is not constructible. This behavior is expected and is not a regression. Did you meet any cases using this way in real world? For the incoherent behavior, we also have: This because we only skip positional ZST (PhantomData and generics), this policy is also applied for never read fields:
Can you elaborate in which sense it is expected? I can understand that it is expected given the current implementation of Rust. It seems between stable and nightly a new lint was implemented. This lint is expected for inhabited types. However it has false positives on inhabited types, i.e. types that are only meant for type-level usage (for example to implement a trait). I agree we should probably categorize this issue as a false positive of a new lint rather than a regression (technically). Thanks, I can see the idea behind it. I'm not convinced about it though, but it doesn't bother me either. So let's just keep this issue focused on the false positive rather than the inconsistent behavior.
How do you think about private structs with fields of never type?
I would consider it the same as public structs, because they can still be "constructed" at the type-level. So they are dynamic dead--code but not dead-code since they are used statically. It would be dead-code though if the type is never used (both in dynamic code and static code, i.e. types).
Actually, thinking about this issue, I don't think this is a false positive only for the never type. I think the whole lint is wrong. The fact that the type is empty is just a proof that constructing it at term-level is not necessary for the type to be "alive" (aka usable). This could also be the case with non-empty types. A lot of people just use unit types for type-level usage only (instead of empty types). So my conclusion would be that linting a type to be dead-code because it is never constructed is brittle as it can't be sure that the type is not meant to be constructed at term-level (and thus only used at type-level). Adding is not a solution because if the type is actually not used at all (including in types) then we actually want the warning. Here is an example: The same thing with a private struct: And now actual dead code:
I think a better way is: is usually used to do such things like just a proof. Maybe we can add a help for this case.
But I agree that we shouldn't emit warnings for pub structs with any fields of never type (and also unit type), this is an intentional behavior.
Oh yes good point. So all good to proceed with adding never type to the list of special types.
Thanks a lot for the quick fix! Once it hits nightly, I'll give it a try. I'm a bit afraid though that this won't fix the underlying problem of understanding which types are not meant to exist at runtime. For example, sometimes instead of using the never type, I also use empty enums such that I can give a name and separate identity to that type. Let's see if it's an issue. If yes, I guess ultimately there would be 2 options: Just use in those cases. Introduce a trait (or better name) for types that are not meant to exist at runtime like unit, never, and phantom types, but could be extended with user types like empty enums. I'll ping this thread again if I actually hit this issue.
I could test it (using nightly-2024-08-01) and . I just had to change a to in a crate where I didn't have already. Ultimately, is going to be a type alias for so maybe it's not worth supporting it. And thinking about empty enums, this should never be an issue for my particular usage, which is to build empty types. Because either the type takes no parameters in which case I use an empty enum directly. Or it takes parameters and I have to use a struct with fields, and to make the struct empty I also have to add a never field. So my concern in the previous message is not an issue for me.


I do not have minimised code. This was a sudden CI build failure on nightly for aarch64-unknown-linux-musl () Note that this is a cross compile using cross-rs. It fails on rust version 1.82.0-nightly ( 2024-07-29) but works on 1.82.0-nightly ( 2024-07-28). Needless to say it also works perfectly fine on stable. The error is reproducible on rebuild and locally with cross-rs. It is not reproducible with cargo-zigbuild interestingly enough. I also checked that the version of cross-rs didn't change between the successful and failing builds (no new releases of that project since february). The only change between the successful and failing CI runs were a typo fix to an unrelated CI pipeline (the release one, so it didn't even run yet). As such I'm forced to conclude that the blame lies with Rustc. Steps to reproduce: I expected to see this happen: Compilation successful (as it is with stable for same target, or with -gnu and nightly) Instead, this happened () It most recently worked on: 1.82.0-nightly ( 2024-07-28) (or stable 1.80.0 or beta 1.81.0, take your pick for triaging) :
cc (of cross-rs fame) in case he has any insight on this regression
I have hit the same issue in a similar situation. Cross compiling to aarch64-unknown-linux-musl from x86_64 linux in a Github CI pipeline using cross-rs. Link to pipeline failing logs:
Seems rune isn't needed based on the comment by Updated the title.
This is probably
WG-prioritization assigning priority (). label -I-prioritize +P-high
Yeah that's probably it. We used to build the C version of those symbols but switched to Rust versions with the compiler builtins update. Unfortunately we can't enable them on all platforms because LLVM has crashes, and the logic that would allow optional configuration is apparently not working. After that part is fixed, we will need to enable the symbols on all platforms where is f128 (which includes aarch64), since these errors probably come from here I think anyone who needs a quick workaround can add to their dependencies to get the symbols directly, as described near the top of Note that this requires nightly.
Is it possible to add a dependency conditionally based on if it is nightly? (In a specific range of dates even?) I cannot and will not depend on nightly, but I do test my code on nightly in CI (in order to find breakages like this early). For now I just disabled that nightly build on aarch64 musl.
Same for me. Not using cross-rs though. Logs are here:
Same for me, both using as host toolchain and cross compiling.
Looks like it is happening now too for x86_64.
Not for my projects, so you should probably provide a reproducer on x86-64 GNU if possible, since that is a tier 1 platform (unlike Aarch64 on Musl). Or is this about some other x8664 variation that is also tier 2?
Woops, sorry, the x86_64 build failed too, but then i looked at the aarch64 build logs :) which still fail.


Found by grepping through the compiler via while reviewing an unrelated PR. File : File : : . or move source file . : . <details<summaryFull compiler output</summary</details:
Solution: Get rid of altogether and use a multi-part suggestion (, ).


<!-- ICE: Rustc '-Zpolymorphize=on -Zinline-mir=yes -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'mentioneditems for DefId(0:15 ~ a[1172]::unsound) have not yet been set'', 'thread 'rustc' panicked at 'mentioneditems for DefId(0:15 ~ a[1172]::unsound) have not yet been set'' 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: [optimizedmir] optimizing MIR for [unusedgenericparams] determining which generic parameters are unused by -- label +F-traitupcasting
Regression in nightly-2024-08-03 Regression in cc
Looks like another tainting issue to me -- we shouldn't be inlining MIR bodies that don't even pass type-checking... Cc


Right now using to manage the rust-lang/rust repo locally causes to fail: This is a result of which is responsible for adding the character to the failing test. While I would love to get that support to jj upstream I'm assuming it is non-trivial and I'd like a better solution in the short term so I can continue to use while contributing to the compiler. suggested I use in the meantime which I'm fine with but I'd like a way to set this in my or some equivalent mechanism doesn't require manually adding this set of arguments to every invocation of I make.
note this is essentially the same as i actually would like an even more general solution, where the flags and configs are completely interchangable and you can specify either in either place, but a solution just for seems ok too. label T-bootstrap A-contributor-roadblock
So it turns out that won't work as a short term fix even because does not work with tidy atm. For now I'm going with but I expect this to break frequently and be a source of annoyance so I'll be looking towards fixing this soon if it does in fact end up being a problem.
re crlf, as a source control expert I'd recommend never using any kind of autoconversion -- it is a bit of a nightmare to work with in too many cases. Rather, I'd consider checking in the file with CRLFs, and disabling autoconversion so files are always checked out as-is. (Another option is to effectively treat the file as binary content, e.g. use some other means of encoding the file, such as base64 or putting it in a tarball. But I don't know how practical that is)


<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: 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: 536 | Err(#[stable(feature = "rust1", since = "1.0.0")] E), [typeck] type-checking [analysis] running analysis passes on this crate --
Probably one of those cases... We should almost have an internal deny lint that bans explicit manipulations for suggestions. Possibly
Strongly agree. It's so easy to find these kinds of ICEs: simply needs to look for inside , out which ASCII character is meant to one's favorite Unicode table website that can list Confusables a Confusable whose is 1 and :boom:
For example, here's another one which I organically found while reviewing an unrelated PR: This code uses a Medium Right Parenthesis Ornament (U+2769) which is confusable with Right Parenthesis
I'll open an issue for the internal lint.


<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' 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: --
Can you start pingbacking at least for all of these?
ice since
can you add a filter for is:issue is:open label:I-ICE "bpos.to_u32" into the ticket you mentioned? That should find all relevant past an future issues automatically I think.
A filter? How do I do that?
oh, you mean a link
I a label , I'll go back and tag some of them later.


Since GDB used on CI is recent enough to run the new tests. However, there are three failures that have been ignored in : <details<summary<codetestsdebuginfomethod-on-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfooption-like-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfoby-value-non-immediate-argument</code</summary</details
modify labels: +O-windows-gnu +A-debuginfo
The by-value-non-immediate-argument is Upon further inspection, I am now confident that the enums test failures are actually a change in layout with targets. Such nonsense is typical of the debuginfo tests. Take this example program, using the enum extracted from the test: Which we can run on any target that can print using Miri x8664-pc-windows-msvc, x86-64-pc-windows-gnu, and x8664-unknonw-linux-gnu all print 1. s390x-unknown-linux-gnu and i686-pc-windows-gnu print 0 i686-unknown-linux-gnu reports UB, didn't bother figuring out where its discriminant is at but uh that's sus So I think the debuggers in the tests are correctly reporting that the discriminant value for change between platforms.
Oh I see! says this: As far as I can tell, this test has been broken since it was written. You can't rely on field order like this, and indeed as I demonstrated above, fields get reordered differently across targets. The structs and enums also have different field ordering on a single target.


<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: The warning fires on all three lines of , and the suggestions should only suggest removing the parentheses, not the attribute also. Instead, this happened: The fires on the first and last lines of , and the suggestion also removes the . No warning fires on the second line (but this is probably a separate issue, unrelated to attributes; it happens even when the attribute is removed; maybe overrides it or something). <!-- 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. --: Requires use of , otherwise the is not legal in that position (though note that the warning and suggestion is the same on stable, there's just an first). The issue is not specific to closures and , but that was the simplest example of a reasonable attribute-on-expression I thought of. label +A-diagnostics +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim


Ferrocene CI has detected that this test was broken by rust-lang/rust . Specifically, by the change in , shown below: Test output: Reverting that single line diff fixes the test for the QNX7.1 targets, e.g. and can the change be reverted or does QNX7.0 need to use , instead of , here? from looking at libc, it appears that both and are available on QNX7.0 so reverting the change should at least not cause compilation or linking errors. if the case is the latter, then we should use in addition to .
thanks for the report! I will need to re-test it for QNX 7.0, to see if it is a 7.0 requirement (i don't recall why this was required initially, but clearly I ran into some issues with it). I also plan to do a similar automation to ensure 7.0 builds run without problems on our hardware. Is there a list of tests you see failing on 7.1 that are OK to ignore? I see a list - is this the most relevant one? Thx!
we do not ignore any single unit test at the moment and we run library (e.g. libstd) tests as well as (cross) compilation tests using . we don't pass to but instead pass the list of test suites as arguments. we currently run these test suites:
WG-prioritization assigning priority (). label -I-prioritize +P-low
fixed in


<!-- 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. --After adding to , I get the ICE. The resulting : The full project: <!-- 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. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?


() Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly


The error message doesn't say that the problem is mismatching mutability.
Looks like this can be closed, this is now: Edit: though now the complaint might be that it doesn't single out 'other'
Flagging as needstest (just in case a test doesn't already exist)


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


The crater run for merged doctests () detected a large number of regressions due to tests examining the process arguments. (I don't have an exact number, but let's say ~50 projects.) Previously, there were no arguments, but now it gets arguments like which the user's CLI parsing code isn't expecting. For example, using something like  will now fail. It seems to be fairly common to have objects whose default constructor will parse the arguments from the command line. I'm not sure if or how we should resolve that. One idea is to use a different mechanism for passing in the test information (like via an environment variable).
I vaguely remember that using environment variables was discussed but can't find anything except mentioning it . Maybe it'd be a better approach indeed. Let me send a PR so we can make a crater run on it.