I am attempting to use the () syntax to control how my test binary is compiled. I have created a repro at In , I tell to link 2 static libraries, one with (+whole-archive) and one without (-whole-archive). I add a nonsense link argument so I can inspect the produced link line. I expect to see linked without whole archive. Instead, I see both and libraries linked with --whole-archive: This may be related to the default documented . When I use nightly and specify it works as expected: However, I cannot use the nightly toolchain, so I cannot use , and seems inappropriate for a final binary crate types like cdylib, staticlib, and executables anyway. Tested with 1.62.1 stable and 1.64 nightly. Possibly related issues: ,
This is a bug introduced in The backward compatibility condition should look like and not .
Could you submit a PR with this fix? (We can backport it to beta if it's done in time.)
Sure, I'll create a PR. I'm not sure what tests to include, however. I had been looking at that exact code and almost submitted a PR earlier, but I wasn't sure about the whole context of that code and all the compatibility needs.
You can try adding a test case with to . One with and , and another with and without any (the compatibility case).


: and then if I increase the recursion limit enough... adding a backtrace gives nothing new, however, compiling on nightly gives the following: </p</detailsI strongly suspect this is related to , but that issue is now old and should have been solved. Perhaps a regression?
can you provide the you compiled that code snippet with? The provided code doesn't seem complete.
I can reproduce it with in the section of a , but this is not an ICE.


Currently we have , should and also be implemented for where ? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Can you help me with runnable code to understand why the will be useful and what can be a use case for it? label +T-libs-api
Ah ok, maybe I understand what do you mean, currently we can do And your proposal is to support
I don’t have a use case for , adding it is just for matching existing . But for , I want to be able to write: instead of


<!-- 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 compiler giving an error and showing a hint that order of the argument are not correct. Instead, this happened: it stucks, waits forever. It happens on both stable and nightly. Might be related to this:
Yeah, this is probably a dupe of that other one. cc
Yes, it's another bug in the same function, but the root cause is different. I will working on the same PR for this issue.


produces: But I think it should be. For the HTML backend, rustdoc "resugars" the return type to get the from I think we should move this to a pass. cc does this change seem like a good idea. modify labels: +T-rustdoc +A-rustdoc-json
I'm not sure if it's worth adding a pass for this... Maybe handling this into a specific function shared between both formats could be a better idea?
We could call in . Or we could move this to when constructing . I'm not sure which makes most sense.
In directly seems like a good approach.


I tried -ing this proc macro crate: rust /// pub extern crate procmacrocrate; /// /// #[macroexport] /// macrorules! foo { /// (path:ident)::) =( /// $crate::procmacrocrate::identity!{ /// path):: /// } /// ) /// } /// /// #[macroexport] /// macrorules! baz { /// () =( /// crate::BAR) /// ) /// } /// /// pub const BAR: u32 = 19; /// /// fn main(){ /// println!("{}", crate::baz!()); /// } /// /// I expected to see this happen: The test completes successfully Instead, this happened: The test fails compilation with this error: It most recently worked on: : This also fails in 1.62 and 1.63. This appears to be fixed in the beta channel, but I could not find a mention of this bug or a related one. It's entirely possible that the bug will trigger again in future versions if this code isn't used in tests. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bisection shows it regressed in and got fixed in . Looks like this issue wasn’t deliberately fixed, since doesn’t call out any issue being fixed. Also did involve minor breakage, as discussed in its thread, but I haven’t looked into it enough to tell whether those cases of breakage were similar to this issue or different.
label A-macros, A-proc-macros
cc (author of ) and (author of ) (read above to see how these PRs are relevant)
Looking at the code changes from it makes sense that this regressed, as the call to () would have done a check and rejected creating . The code (which was originally introduced in : ), should've probably avoided the constructor from the get-go, but it wasn't an issue because wasn't a possible identifier in that case previously. In , I changed the logic there to avoid going through that constructor when re-building the tokens internally, so we don't do the broken validation on that side anymore, and the problem wouldn't happen anymore. I don't think there's much more to be done here, as it's fixed already on beta, and isn't likely to regress with the new design.
Thanks a lot for your insights!
label E-easy. (We only need a test to close this issue.)
For someone wanting to add a test for this, you should be able to add the use code in . You can see for an idea of what the test might look like.
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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output on stable 1.63.0: The current output on Beta version 1.64.0-beta.6 (2022-09-09 ): The current output on Nightly version 1.65.0-nightly (2022-09-09 ): Since ( cc ) is somewhat recent the help diagnostics improvement currently is only on beta. However, the latest nightly has regressions regarding the suggestion as shown above. Hence, the output should suggest changing with as that is the desired output. Note: base issue for improved diagnostics ( -): Note: since this is technically a regression from beta to nightly, what should be the appropriate label to add? The one below this? label +regression-untriaged <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Can you please add the Rustc versions?
[Note that I don't think this should have happened at all, I wrote tests for the changed diagnostic suggestions]
I have retested the above code snippet against the current stable, beta and nightly version (I have the version numbers above) of the compiler in the official rust playground and the regression still persist. Not sure if this only occurs on the rust playground although I highly doubt it. Maybe you could look into this as the implementation of that diagnostics improvement is written by you. If you have any evidence that this regression issue is misinformed do let me know and I will happily close the issue. Thanks a lot.
Not sure if this is the cause but maybe the test you wrote in is slightly different to the above code snippet as the test uses the wrong keyword in the top-level. However, the above code snippet uses the incorrect keyword inside of a user-defined module. Hence, this may lead to a PR that potentially causes a regression in the recovery of -to not trip off a CI fail. Therefore, undetected. That being said, all those are just my guess and it may be wrong. label +E-needs-bisection
This may related to my PR:
claim
label -E-needs-bisection


<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --should suggest if the argument is a closure instead of suggesting to call the closure Given the following code: <!-- Please provide a link to -- The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This probably can be generalized if the code is written carefully enough.
Do you mean, we should handle other types like which may use with a closure?
I know nothing about the internals of rustc diagnostics but a general way would be to check if a similar method in name accepts a closure and suggest that first, if nothing similar can be found then suggest calling the closure
I mean something more like what is suggesting, where you check if exists whose signature is compatible with a closure. But that requires doing a method probe, then doing some delicate logic to check argument compatibility.


with synchronization assumes that does not panic. This assumption is however not correct. For instance, a panic occurs if the TLS key used to store the thread info , , , and . The code examples above all use intrusive lists and have to wait on a condition to before destroying the list nodes. If panics, the nodes will be dropped during stack unwinding without checking that condition, leading to undefined behaviour (some of these cases are in , so I'm marking this as a soundness problem with ). Fixing this would either require guarding against panics in each of these cases or ensuring that never panics. label +I-unsound +A-atomic +T-libs +T-libs-api
Thanks for bringing this up! I agree this is a problem. In general, the pattern with parking is: Unwinding would mean leaving that loop even though the condition isn't true. While code right after the loop isn't executed, there are many cases where leaving the current frame before the condition is true is problematic, as all your examples show. I think it's not reasonable to expect every user of to take this subtle pitfall into account. Instead, I believe we should guarantee that never unwinds.
All the situations in which can currently panic are very unusual things that are most likely unrecoverable errors. So I think it'd be fine to just never let unwind, and instead always on panic.
I think Rust should allocate the needed resources eagerly when creating a new thread, to avoid this problem.
It actually does most of the time, as always creates a . However, if the thread is created through other means, the struct needs to be lazily allocated, which can of course fail. Either way, we also need to protect against the case where fails - it should not, but who knows what some obscure system might do (the UNIX parking implementation is used on systems like L4RE and 3DS/Horizon). In general, I think it is easier for maintainability if we just always convert panics to aborts in / rather than going through every system and abstraction to ensure no panics are caused. Still, this is possible to do in the future (as is returning instantly).
I just tripped over an issue in this area. I'm trying to put together a userspace mutex for learning and it works fine apart from when there is a panic. If there has been a panic, then I get a panic when handling panic and fall over with this stack trace: Note that at 18, some destructors are run, that appear to be releasing Thread local storage. By the time I try to run , at 7, the thread is already invalid (although , I don't know that). I tried: But, I get the same problem. I presume because of raciness between the check for panicking and the panic actually starting.
It looks like you're implementing a global allocator using your thread::park_timeout-based mutex? That's going to be problematic, since the thread parking data is stored in a heap allocation (an ) that gets deallocated on thread destruction.
Thank you. I have an approach to the problem which works as a spinlock, but I was experimenting to see if I could do something more efficient using . It's one of those where I wasn't sure if it was interesting to report, but I thought I'd mention it.


Since the nightly 2022-09-11, the following code doesn't compile anymore. <!-- 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
Minimized it a little
searched nightlies: from nightly-2022-01-01 to nightly-2022-09-30 regressed nightly: nightly-2022-09-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
cc
cc
I get the same ICE when using the current nightly in a complex Codebase. The works fine.
I think I minimized this to:


While working on an experimental runtime and using a couple of experimental features I found that the compiler while in resolving the async call on a trait crash badly. This is a minimal reproducible example and this is the stacktrace generated N.B: I guess this happens with any runtime? BTW also if happens only with rio the compiler should not crash, but I do not think this is related to a specific runtime, but I guess instead, the runtime triggers the resolution of the futures <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-async-await +T-compiler
In the meanwhile, I will try to swim inside the codebase to catch the problem! claim
this is fixed by .
Minimized so it doesn't depend on rio:
Cool great work :)


Similar to how deny(unsafecode) prevents from being used, it should also prevent blocks from being allowed. If misused, they can do any number of strange and horrible thing simply by being within the crate. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
label +C-bug +T-compiler
I suppose it's probably too late to actually make it require ?
that isn't even currently possible from a syntax perspective because blocks only work as expressions, you can't just put them around a top level item. It would take a whole RFC thing, even separately from global_asm already being stable.


This malformed code () hangs the compiler: Found by fuzzing with a . must be defined as a named-field struct (not a tuple struct or unit struct), although it can have 0 fields. must be the last token to produce the hang: No opening brace (note that braces are required for literals of named-field structs) No closing delimiters Not even a comment If I understand correctly, the hang occurs in LateResolutionVisitor, with never finishing (while calling various functions such as and ) This also hangs. I'm guessing it's the same bug. : with: <details</summary<p</p</detailsregressed nightly: nightly-2022-10-21 regressed commit: (PR ) label +regression-from-stable-to-nightly +I-hang <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
I can not reproduce it with latest code, did I missed anything?
Great cactch Confirmed the error is only triggered by commit: The root cause is I changed the edge corner case in : We think won't return a span which outside of source file, so is a valid one, then will always return a valid span, and we get from when reaching the end of source. So, there is a loop in previous , which will run infinitely loop: Lucky, my another PR merged at last day, this PR refactored this function:
Verif, I no longer get a hang after rollup Do you want to add one or two of these as tests?
Yes, we'd better add a testcase for it. I'm thinking whether we sould in when reaching to the end of source, so that may get an error.
This testcase seems not easy to be : If so, the trigger point will do not exist,
label -I-prioritize
There's an alternative kind of annotation for patterns that should work for this case:


The following code: currently produces a heap of semi-helpful diagnostics: <details<summary<bstderr (7 errors)</b</summary</detailswhen instead we could special-case this and emit a single (or at least fewer) diagnostic that suggests the following: If the bound in not inside , like in: we currently emit the following: which is less verbose for sure but still, we should provide the same suggestion I propose above. Related issue: . label A-parser A-suggestion-diagnostics D-newcomer-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Error: Parsing ping command in failed: ...'stbot ping' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I'd like to take a look. claim
I'm wondering if taking an approach that suggests using higher-rank trait bounds () for an Fn-family trait with a lifetime parameter. Is it appropriate? I'm concerned that it may not a comprehensive solution because HRTB can be used outside of the Fn-family traits (as I understand). Or is it okay only for the Fn-family traits for now?
I am not sure I fully understand what you mean. As you probably know, none of , , take a lifetime parameter and probably never will. Of course, you could define such a trait with unstable features but there is no way to use them, so it's not relevant: Yes, I'd say so. I wouldn't look for names however (like , , …) but just look for an opening parenthesis after a generic parameter list. This way, we can emit the same suggestion for the following case (where the name is ):
Ah, definitely. Thank you!


Today for no reason in particular I was curious about the behaviour of arrays when zipped together and then mapped into a single array, roughly: I wrote some tests for this and disassembled them in Godbolt to see what was going on behind the scenes and wow was a whole lot going on that seemed like it didn't need to be. So I wrote something kinda like what's in the stdlib for mapping and zipping arrays, just without the iterators, to see if I could do any better. Turns out I absolutely can: Maybe the design isn't as optimal (or as safe) as it could be, but it performs perfectly well in benchmarks (read: as fast as an unguarded version and anywhere between 3-25 times faster than the definition shown at the top of this issue. Here's a rough table of execution times averaged over the primitive ops (, , &|^`): ! Not really liking how things are looking for . So, question then is: is there something in Rust that needs to change to let these optimisations happen, or do I need to look at putting this in a library somewhere (or maybe stdlib wink wink nudge nudge?)? *The 25x comes from the benchmarks. benches at 11.230ns, and benches at 452.593ps, which seems suspicious but I can't seem to find anything wrong with the result.
I suspect the issue here is that has the wrong shape. It returns but vector instructions generally want . isn't an iterator type that describes the desired iteration and then performs it once, rather it's one loop that creates an intermediate result and then a second loop that produces the final output. Perhaps we could massage the code into a shape that the optimizer can disentangle, but I think it would be better to offer something like your , albeit with a nicer name.
This is missing an actual reproducer... Tried a few sizes here: I assume the report is about the case where this doesn't get unrolled, like with N=128?
I'm not entirely sure what you're looking for in a reproducer, but I have a benchmark program set up using to check out the performance of the various functions (see the "Benchmark" section at the bottom of this post). More or less I have as shown above (renamed to ), and both of these: Then I set up a lot of benchmarks. These test the speed of some primitive operations (, , , , , ) on arrays of lengths 8, 16, 32, 64, 128, 256, and 512 for types u8, u16, u32, and u64. This gives a total of 168 benchmarks per function, which reduces down to 28 per test after the primitive tests are averaged for each function, length, and type. The results of this are: ! This was run on the latest nightly as of 2022-12-21. I think this is pretty hard evidence that performance using is not where it should be. and are grouped so close together in the bottom section of the graph you can't visually see the difference. But for ? It's very obviously slower than the other two. Notice how it takes more time to map together two than it takes the other methods to map together two . Even if we just look at shorter inputs like was suggested, it doesn't look good for : ! These are just the results for lengths up through 64, and we can pretty clearly see that is just always slower. <details<summary<strongBenchmark</strong</summary<p: </p</details
Part of this is the classic "too many copies" trio But some of it is probably just that, being eager, it won't optimize unless it fully unrolls.


I tried this: I expected to see this happen: The second invocation takes essentially no time. Instead, this happened: The docs were completely rebuilt. The problem is that we remove the docs between each invocation: this is a regression from - do you think you'll have time to follow up? I think we can either add a stamp file to avoid rebuilding, or find some other way to avoid removing the whole directory - maybe we can only remove/copy the files, rather than everything? <!-- 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. --HEAD is branched from . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Ok, I confirmed that rustdoc only creates JSON files with --output-format json: So it should be enough to only copy .json files when passed --json, and only non-json files when it's not passed. We should also add a test that produces the same output in json-doc as , to avoid a regression if rustdoc starts emitting JSON files in the default HTML format.
I can't jump on it immediately, but I should be able to follow up in a couple of weeks
claim
We can do this validation for dir, but I am not sure if this is possible for dir since each time json output changes. The layout of json context is getting change even if you don't change anyhing on the source code. I print sha2 sums below to demonstrate the situation. 1st attempt: 2nd attempt right after the first attempt The demonstration is from
thanks for investigating; sounds like we should report that as a separate bug in rustdoc. But for now it's ok if the files don't match exactly as long as the file names are the same between runs.


The following code compiles on nightly (): But if the wrapper type is moved into a module to make the field private, then it does not: (): Making the field makes it compile again. Is this expected? I suppose I could understand if it is; the private fields could change to make actually be constructable and therefore make the pattern refutable. But if that's the case, then I think the compiler should point this out, like . If indeed this is expected, is there any way for me as a library author to somehow convince the compiler that I will never change the fields to make the type constructable? I want users of my library to be able to elide match arms when I give them an . label +T-compiler +F-never_type +D-confusing +requires-nightly +S-bug-has-mcve
label +F-exhaustive_patterns
are we sure this is actually a bug? As I said, I could understand how it's not:
I'm not sure either way - however at the very least, as you point out, it makes sense to have some better diagnostics
This is definitely intentional. But yeah, it should have a better error message. Not currently I don't think. It would probably require us to add an trait, eg. something like: This trait would then need to be a lang item so that the exhaustiveness check could make use of it. Adding this trait would require an RFC but I doubt there'll be much enthusiasm for adding another special trait for such a niche use-case. Alternatively, you could give an or method to expose the uninhabitedness of the inner value. It's not quite what you're asking for but it's still concise-ish:
Is supposed to be “injected” where an otherwise required match arm was omitted? Wouldn't that run into the same discussions project-deref-patterns had about impure code (code with side effects) inside patterns? Their existence would heavily hinder optimizations of match expressions (like translation to jump tables or reordering).
If the type implementing really is uninhabited then there won't actually be any impure code in the match. The call to would only need to be injected for types that fake uninhabitedness with an impl that panics/aborts. We could also rule that out be instead making -only like .
Making a trait isn't straightforward exactly because inhabitedness depends on visibility questions. It would probably have to mean "Uninhabited as far as the outside world is concerned", or it could use a trick like the in to make it depend on the module.


Found with a <details<summary<strongFull output including backtrace</strong</summary<p</p</detailsRegression in nightly-2022-09-18 from ( <details<summaryBisect info</summarysearched nightlies: from nightly-2022-09-04 to nightly-2022-11-07 regressed nightly: nightly-2022-09-18 searched commit range: regressed commit: bisected with <a href=''cargo-bisect-rustc</av0.6.4 Host triple: x86_64-apple-darwin </details
For the record, this isn't dependent on return type, which is a separate error. This also ICEs:
This don't ICE: I guess it's because terminated because the error type error.
Yeah, still needs to implement the trait in the -- this ICEs, for example:
I can take a look at this, unless you're already working on this
I think compiler-errors already submitted a PR to fix this, PR linked above, but he did not claim this issue.
Oh thanks, didn't see this.


To reproduce, navigate to and click the the "source" link for any of the methods. Nothing at all happens when I do that. I tried Firefox and Chromium. This seems to be a fairly recent regression.
It's because it's under the for some reason. Let's see what changed in the last few days.
I think it's because of I'll try to send a fix today.
It's because a to have a correct positioning of the tooltip on mobile devices.


Currently all of its functions immediately . We need to either remove this or implement it. I vote for implementing it.


<!-- 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. --: : <!-- 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 --
The real error isn't the unemitted diagnostic, it's the unwrap. The unemitted diagnostic only happens bc this unwrap occurs during diagnostics code, I think.
cc I think this might be and we try to suggest .clone() which is not available for the type though?
If you add ... to the example you no longer ICE and just hit the normalerror[E0382]: use of moved value: 'x' `
claim
Please use this minimized repro:

Every time I think "surely this will be fine", it bites me in the read as sure as the sun coming up.
Are we fixing ICEs? Not so sure we should bother...
This one was particularly easy to fix () and probably shouldn't've have been an in the first place (unwraps in diagnostics code are generally a code smell, since they should fail gracefully in strange situations) -- but I generally agree, had this fix required some large refactoring or implemented extra checks on a performance-sensitive path, then I think this should've been closed w/ a wontfix.


Given the following code: current output is: The last part of the suggestion is not valid Rust code and therefore should not be suggested like this. This problem occurs on the Playground on both stable and nightly with basically identical error messages. serde v1.0.147 requires such that will be . Otherwise the problem does not seem serde specific. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
do you know how to create a minimal case without ? so we may add it to unit testing. I give a fix and verified it's OK with my local testing, but I'm struggle to construct a minimal case without to reproduce it.
I assume this reproduces when using the same setup of derive macro implementing a trait while the implementation is missing bounds. I don't know if it is relevant that the derive macro produces a trait. Something along these lines, with the proc macro crate omitted.
yes, it's caused by derive macro.
emmmet this error


Any ideas?
Regressed with
cc
Is there more information available from the error? The module should not be part of the FreeBSD build. Also, an error in resolving doesn't make much sense to me because that module should exist regardless of whether the feature is enabled. Is it possible that there's either (1) another error further up in the build log, or (2) an existing incorrect dependency that's been exposed by the recent change?
The full log is available here:
It only happens if I build the documentation. Is it possible to fix this problem before rust 1.67 lands?
Reproduced with the following command: could you please see if the patch in fixes the build for you?
Your patch fixes the issue. Many thanks!


I tried this code (): I expected to see this happen: Instead, this happened: This is just a very specific instance where the suggestion to add some code, while "technically correct", is less useful than the better suggestion to remove some code. <!-- 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<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +A-diagnostics
it seems that given an expression, you can generically check if removing the last method call if present would give you the right type, so this could be implemented in a very generic way instead of special casing &str/String.
This looks awesome, thank you so much!
This is how it looks now . Very cool.


In debug mode, this prints But with optimizations, this prints: With optimizations and , this prints: This check in the MIR inliner is hiding this problem from the track-caller UI tests: label +A-mir-opt +A-mir-opt-inlining :
Nevermind that, the panic here is correct actually :D
Ignoring changes in the standard library and optimization level at which MIR inliner is enabled, bisection points to cc
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Given the following The current output is: The second error is not reasonable, since we don't allow associated items in auto trait. Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I spent some time to investigate it, I tried to filter the candidates from auto trait. But seems here have two predicates, and the message for the second error comes from the first : I'm still trying to understand the code.
claim


Spawned off of I tried this code: I expected to see this happen: I expected the to be mapped to the local paths in the installed component, rather than being left as raw Instead, this happened: is showing up in the output. <!-- 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. --:
see related discussion from wg-debugging triage
in particular, pointed out that that this remapping should be happening if one has the component installed, and that the code doing the remapping should be executed here: and there is corresponding code in bootstrap dist code: There's some useful statements mixed in there, I bet we might be able to figure out what's going on here without too much trickery...
But this is currently a remapping at runtime only when using like in UI tests, right ? Otherwise it's optionally done at compile-time on the dist builders if they set .
is , right? That is what it is mapped from, not what it is mapped to.
Its and 's presence seem to control (at rustc build-time and at runtime respectively) whether the remapping happens in the code you listed above (otherwise would be "empty" and would be a no-op), so I may be missing how this could already remap to the local component according to Felix's comment above ?
I believe these are not being remapped on purpose (based on ). I think currently the remapping only happens for diagnostics (and not things that end up in the binary). There's some more discussion in (and and to some degree). There's also concerns about how it can affect binary size (). also discusses it some.
These paths are also not being remapped even when explicitly requested with


we should suggest cloning. Also, we should suggest <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
If we suggest add bound, we don't need dervie , This code will compile:


There is a latent bug in rustdoc that hangs in when is enabled.
From the thread on :
Interestingly, also gets stuck. I believe that runs the beta (non-parallel) rustdoc. So that'd mean that rustdoc gets stuck when documenting parallel rustc, not that parallel rustdoc gets stuck when documenting rustc.
Both of the PRs that are blocked by this issue are changes that change the ast.
It seems it's not an infinite loop, but just bad (exponential?) time complexity somewhere. suggested trying out what happens when explicitly implementing Send and Sync for the new ast node, and that indeed 'fixes' the problem in So this issue has almost nothing to do with parallel compiler. It occurs in regular non-parallel rustdoc. It's just that with , the ast is Send and Sync, and apparently that takes a huge amount of time to prove when documenting rustcmiddle. (Oli is investigating.)
Data point: Adding the following snippet to will not stop it from compiling successfully, even though documenting the crate will never stop. This makes me think the issue is very much rustdoc related, as it appears to get stuck on proving .
WG-prioritization assigning priority () (note: seems not a regression) label -I-prioritize +P-high
cc
and , https://rust-
[Edit] I'm trying to solve this problem and what I'm currently observing is that the does not store all the information when using rustdoc. This causes rustdoc to recalculate many times when collecting auto trait impl and blanket trait impl. I guess it may be that rustdoc does not calculate the trait implementation on some data structures (such as ) in advance, which resulting in too deep recursion
A revealing phenomenon: The following struct in will cause rustdoc to block while proving that is : But when the generics are instantiated, it will not cause blocking: So I guess it is that causes the values in to not be reused. Because this cache needs inserting (predictions, ).
does this happen even with disabled?
If so, this is probably related to . This is how we determine the paramenv:
I can't reproduce this issue , including my local test Have there been any recent changes?


This is one of those ICEs that are terribly hard to minimize because they happen cache-dependently, [update: see below for repro instructions]. If nothing else, notice that there is a panic while trying to print the query stack; it might be desirable to look into making that not happen so as to be able to get more information. <!-- 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. --Occurred while running or . : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +A-incr-comp
On looking more closely at the backtrace, it seems that this error results from attempting to load corrupted (truncated) query cache files, and therefore it would be valuable to obtain a trace from the file having been written (assuming that they are truncated due to a panic during write; if they're silently corrupted that's even harder to notice). I will update this issue if I manage to catch such a case.
Looking at the first panic observed since a and it is still the above in , so it's not that I missed the writing event but that it didn't panic.
I have made some progress on reproducing the problem with a minimal incremental change (but not yet a minimal standalone code sample), and expressed some interest in looking at the problem, so I've published branches with the work I have so far. Repro steps: The second build will ICE. The differences between the two branches are shuffling code between modules, adding a module, and deleting a module; the code in them is as identical as it can be.
Note: I cannot reproduce this ICE on x86_64-unknown-linux-gnu with the latest nightly by default, but makes it ICE. <details<summarybacktrace</summary</details
I've created a new branch which slighly simplifies the diff application: ( at the time of writing).
I've tried to find out a bit more about this, but didn't get very far. From what I can tell: In the second session refers to the derived impl for . And refers to the const generic of that impl. It has the span of the CHUNKSIZE const generic of the type definition. In the first session, as far as I can tell, the def-path refers to the , which also has a generic const. The query should not evaluate to green, but for some reason all of its dependencies are marked as green.
Maybe is too broken (it needed some fixing to show more than just DepKinds), but is it possible that has no dependencies at all during the first session?
It does indeed have no dependencies. I imagine that this is the culprit: I'm not really up-to-date with query feeding but this looks fishy. When a dep-node has no dependencies, it will trivially evaluate to green. Don't we need at least a dependency on the query that does the feeding? cc &
Given what we've learned about this bug, it's likely that this is purely about incremental compilation cache keying, i.e. neither state of the code is more likely to be miscompiled than the other, right? In other words, I as the author of the original code probably don't need to worry that I'm making my compiled code less reliable if I make the change that caused the ICE, as long as I after that point?
Yes, as far as I can tell, this is a bug in incremental compilation's dependency tracking and does not affect non-incremental builds.
Hey, I'm back with a repro! Thanks go out to , without which I would have never been able to minimize this. A one-command minimization is available at with . Basically: must be enabled. Running . Then applying Then running again panics. <details</detailsFor some strange reason I am unable to reproduce the changes when applying the diff in vscode via WSL. and work though.
I will unassign myself as I mostly assigned myself for the MCVE.
It looks like some things, like lowering to HIR, are run within a context, which leads to this call being ignored too -- and thus never making it into the we are trying to duplicate during . As a consequence, the feed queries in question go from explicitly "re-compute unconditionally" to effectively "re-use unconditionally" The reason seems to be that we . That's fine for those queries themselves because we make sure to re-compute those explicitly. But we fail to "inherit" the eval-always-ness to nested feed-queries. I'll look into fixing this some time this week.


The bug is in the help section of the "missing lifetime specifier" error (E0106). When the method head is formatted over multiple lines, then green highlighting will be misaligned. I tried this code: I expected to see this happen: For the function it looks like this, which is fine <img width="417" alt="image" src="https://user-"Instead, this happened: But for the function the highlight is misaligned <img width="564" alt="image" src="https://user-"


When running with the above code, the docs list the following items: <details<summaryDocs</summary </detailsI would expect to be listed as a reexport, not a struct. The way it is now, it looks like and are different types, which is not the case. If is made , everything looks as it's supposed to. label +T-rustdoc
It's the intended behaviour. Since the module is private, is inlining the item into .
Yes, but is public, so should it really be inlined a second time?
Ok sorry I misunderstood what you meant. No, it shouldn't be inlined a second time.


No response No response It could also recommend using <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seems like a good first issue am I missing something? I am happy to claim it. The write! docs say that write! should accept a writer, a format string, and a list of arguments, so the error output should probably remind that
claim
That's great, let us know if you're having any trouble
Ok! So this is where I am with it: the macro for write! is the following: The issue being that if a writer is forgotten, the macro gets expanded with .writefmt() being called on the formatting string, and the rest of the arguments get passed into formatargs!, which then returns an error that the formatting string maybe was forgotten. In most other erroneous cases, .writefmt() will get called on something that is not a writer and will return a more helpful error that whatever first argument was passed to write! does not have a method writefmt. I had two ideas, the first being to modify the error from , which is where the missing string literal to format with error originates. My idea is that if a string literal is missing AND the formatargs was called from a write! then there probably is a missing writer. My second idea is to add another pattern match to the write! macro itself like: I am not sure which approach is more appropriate, or how exactly to determine the macro that called formatargs! to clarify the error. Do either of these approaches seem worthwhile? I think the write! macro should be the parent of format_args in AST and that is how I would access it? Thanks :) James
You will have to determine whether you are in an expansion of the macro. See for an example of how you could do that and check that it's write/writeln/etc. Most likely you can use and/or to do that. I think this is not a good idea that arm will show up in the documentation, and probably confuse people it also isn't helpful when it's used on something other than a literal. I think I would have the following approach: If the method is named and if we're in a write macro expansion don't emit the "no method named x found for ..." error at , but instead emit an error like... being more specific if it's a string literal...
Got it, thank you so much for pointing me in the right direction As far as the writefmt, this is where I am so far: Which gives the following output: Where I am checking to see if the function is writefmt and the macro is write! and then creating the relevant error message. I still need to create the recommended substitution from your example, I think that would be from rustcerrors::CodeSuggestions, is that correct? Then for the error about the missing format string, using ecx.expansioncause() gives me the whole line of the write! macro , I can think of some hacky ways to pull write! out of the outer span, is there a better way to extract the outer macro or should I just focus on improving the portion of the diagnostic? Thanks again! James
I suggest posting on https://rust- so more people see your message and can help you.
first of all, I would suggest using the fact that the macro has so you can match on the def id like this for example: This will be more reliable than matching on the name, as it won't fire on user provided macros with the same name, for example. Secondly I wouldn't suggest using , currently it is seen more as an anti-pattern. Instead you could probably use to highlight the argument and say (there are other alternatives like printing the type instead, but using is a good idea anyway, I think). Thirdly about your question about suggestions: the easiest way is to use to get the span just before the literal, to add there. However, I'm not sure if such suggestion is a good idea, after all may not be present, or may be named differently, etc; a suggestion that is almost always wrong seems awkward (this reminds me that suggestions should be more powerful than they are currently in rustc…).
Thanks for the tip , I've been lurking on Zulip for a little bit but wasn't sure if it was the right place for questions once there was already an issue on github Amazing thank you so much! I get what you're saying about the suggestion being unclear since the writer name will almost always be different... I also was thinking it might be a little awkward. Anyway I implemented the changes as you suggested and now I think the error message makes it pretty clear that a writer is missing: Otherwise is there anything that could be improved with the message? I am not sure if E0599 is still the correct error code but I think that it is because the error is still technically no method found?
looks good :) I think at this point you can open a PR, if any tweaks are needed we'll tell you in the review process. Feel free to , if you want me to review it.
Ok awesome thanks, just submitted PR


<!-- 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 --
searched nightlies: from nightly-2023-01-01 to nightly-2023-03-11 regressed nightly: nightly-2023-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
This is "due" to , but probably needs to be passed through silently in the canonicalization code.
reduced via treereduce `
I'd argue that repro is worse than the one provided at the top of the issue, even if it's a few bytes shorter. It introduces a bit of superfluous syntax/unnecessary syntax errors. Here's a denser minimization that avoids the syntax errors (except for the one that actually is the root-cause of the issue):
haha, the original snipped looked like this but I though it looked a little too weird :)
claim
Sorry for the off-topic comment: In response to this feedback I made a wrapper for treereduce that avoids introducing unrelated issues. It also runs for you (when it doesn't remove the ICE), and can output a nice Markdown comment with the reduced program.


or perhaps The bad help isn't related to the choice of or (even though the former needs to be followed by to be a statement and the latter doesn't, which could explain the source of the hint); also generates the help to add . %20%3D%3E%20%7B%3B%7D%3B%0A%7D%0A%0Afn%20main()%20%7B%0A%20%20%20%20let%20%20%3D%20statement!()%3B%0A%7D%0A) No response modify labels +D-incorrect <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-02-17 to nightly-2023-03-18 regressed nightly: nightly-2023-02-21 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
cc is this fixed by your branch?
No, it's not. The stacktrace does indeed contain but that's not the root cause of the problem. It just calls which ices (changing it to doesn't help either). The actual (?) bug is probably inside of the code I assume.
Ah, wait. If it's a bug to pass s to the type relating functions then it is the fault of and it should probably return early if a type . Edit: But it that case?
Hm, actually I think we should just fix the relate code instead.
Sure. I also feel like I've seen this ICE message pop up several times already on this issue tracker. I might be mistaken tho.
More minimal:
Reassigning to myself since the approach involving region erasure during selection we talked about fixes this issue (obviously) and since I'd like to integrate this into my PR to be able to write UI tests that exercise the bound region code used during IAT confirmation (otherwise we would never go past selection in those cases). claim label F-inherentassociatedtypes


Given Rustdoc does not escape the ASCII angle brackets for the generic argument list of the generic associated type projection leading to the following butchered HTML output: I've noticed this while working on rustdoc integration for in . It's possible that the refactoring PR will fix this (need to check) or at least make it more pleasant to fix. Assigning myself for now since I'm gonna fix this otherwise. claim label T-rustdoc A-rustdoc-ui F-genericassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Copying my comment from : is requesting alternate formatting (i.e. plaintext), but in this branch of things, alternate formatting hasn't been requested by the caller. So this is likely emitting into an HTML context. If you change it to in your branch I'm guessing that will fix things.
Here's a live example: As it turns out, this bug does appear to be what's crashing rustdoc in . So I will wind up fixing it. But feel free to investigate and fix if you prefer not to wait.
This wound up being the fix:
On at least I cannot reproduce your fix that involves adding in branch (maybe that only works on your branch). In any case, the lines in are definitely the culprit. I've already fixed it that way in but I've now also opened a separate PR. Thanks for the live example!


I tried this code: I expected this to happen: Bootstrap builds cranelift, since I named it explicitly. Instead, this happened: Nothing, since I didn't have cranelift configured in : At a minimum, I would expect this to give an error or warning that I need to configure codegen-backends. It would be even nicer if we could treat as only controlling the defaults, instead of as a hard-off switch, like how works. That should be possible to do by looking at the we're passed. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The first element in codegen-backends is used as default backend. In addition even if the CodegenBackend step were to directly use the passed in paths, assembling the toolchain did still only add the backends in codegen-backends to the sysroot. Having path specifiers for one step affect another step doesn't feel right. For check builds I do agree this is an improvement. Although I personally actually use this behavior to have build all backends, not just cranelift (by enabling all in codegen-backends) It did be nice to have a replacement for this. In addition for at the very least a warning makes sense.
Does it make sense to separate cgclif and cggcc into different steps in that case? cc
That doesn't have any effect on if specifying a backend as path will add it to the sysroot.


<!-- 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. --Since nightly release , we've had build failures for () with message when lto is enabled. If I disable LTO, the build succeeds and the test passes. There are many similar tests which do currently build and run successfully with this version, it is only one specific test we have which is causing the issue. You can reproduce the issue if you build the test in release mode: I haven't been able to work out what actually causes this, and it seems to require a reasonable amount of code before the issue gets triggered. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust nightly 2023-03-23 <!-- Provide the version you are using that has the regression. --: The error message isn't particularly helpful here, but here is the full output from our github action: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
here probably more info on how to reproduce could help. If I read the , the test alone compiles but it fails when enabling the flag, thus the label. label E-needs-mcve
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Probably related to the LLVM upgrade, but I was unable to reduce this to a pure LLVM reproducer.
We just got this error building Firefox on Fedora 38, with Rust 1.69.0 and LLVM 16.0.1:
See /
I'll try a build with that patch. One thing to note though, regarding: The Firefox build got this message on aarch64, ppc64le, and x86_64. (Only s390x succeeded.)
D147620 worked locally for me, building LLVM 16 with that patch and then Firefox built fine. But it looks like that review is not settled yet. Whether the ultimate fix is in LLVM or rustc, I hope we can get that into beta for the 1.70.0 release.
I have a patch for rustc that passes the test case in -- I'll try with Firefox later today. claim


There is no such thing as boxsyntax anymore :D <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
does the same.
It probably makes sense to search across the repository (including submodules) any references to this removed feature and remove them
claim


The unbounded channel implementation from can segfault due to what looks like a race condition when dropping channel senders and receivers. You can find a repro at Unfortunately it is not minimal at all, since it depends on the timely-dataflow crate, which is the actual channel user. I hope it is still self-contained enough that people familiar with the channel implementation can run it and use it as a starting point for debugging. Run the example like this: On some machines it will segfault after some time, e.g.: The segfault happens inside , as visible in the gdb backtrace below. The same segfault also happens with . You can reproduce this by reverting the second-to-last commit on the repro branch. I understand that is a port of , so that's not surprising. : I can reproduce the segfault on nightly as well. The segfault is not reproducible on all machines! We were able to reproduce it on: a c5.2xlarge EC2 instance running Ubuntu an AMD Threadripper Thinkpad running Debian an Intel i5-8250U Dell XPS 13 running Arch Linux It doesn't seem to reproduce on: an M1 MacBook Pro Also note that the repro is using more and more memory over time. That is because the different worker threads create and drop dataflows at different speeds and timely-dataflow keeps per-dataflow communication state (including channels) around until the last worker has dropped the dataflow. It is possible to avoid that by adding a that lets late workers catch up, but in my experience that also stops the segfault from happening. <details<summaryBacktrace</summary<p</p</details
Here are the results of some initial investigation I have been doing. I used , but I assume the results will apply to the std port as well: The segfault happens in . In the linked line, is a null pointer, and so is . It seems like there is an inconsistency between the channel's and . is pointing to nothing while points to a block. I observed the following variable assignments at the time of the segfault: If I change all the atomic orderings in to , the segfault still occurs. This suggests that the issue is not caused by the usage of too-weak orderings. If I add an after , it is triggered under the repro. This is where the sender is advancing and it seems plausible that this is the place where the inconsistency between and described above is introduced. I couldn't figure out why becomes a null pointer. The same method makes sure that the head is allocated previously, so some other thread must set it to null after the check.
cc
This suggests that the issue is not caused by the usage of too-weak orderings. I wouldn't be so quick to write off an ordering issue, the race condition could require stronger synchronization to fix (e.g. fences).
The segfault did occur (after about 5 minutes of runtime) on my Macbook Pro with an Intel Core i7 processor running macOS 13.3 and rustc 1.68.2. So whatever is causing this, it's not exclusive to Linux.
I have a feeling the issue is to do with a CAS failure when updating the tail not synchronizing with the update to head. If the thread that actually makes the update is preempted, the second thread might continue with the assumption that head has been updated, which might matter if it quickly writes to the entire block and the channel is disconnected before the head is ever touched. I haven't verified if this is possible, but it would be extremely rare if it is, which explains why this issue hasn't been hit before.


As the title says - Miri UI tests aren't run when invoked through x.py, or on CI: The actual issue appears to be that in the miri directory expects no non-filter args to be passed to it when being run, but the args are getting passed. I was trying to test miri locally, and I ran the command . I expected the miri UI tests to get run, but instead, they were all always getting filtered out, despite not passing a filter. After looking into it a bit, I discovered the filter vector was always , and decided to check whether bors was running them.
This seems ... pretty unfortunate :sweat: cc I know miri is nightly only but it makes me pretty uncomfortable to be shipping tools that aren't running tests, even if rust-lang/miri is still running the tests.
If my shell history is anything to go by, this is recent breakage, and used to run all of Miri's tests.
Yea, this is not breakage on the miri side afaict, but must be a change on the cargo or bootstrap side. I'm fine fixing this on our side tho. I can replicate the behaviour of the default test runner and adjust the wrappers in the miri repo to insert that
For making it follow normal behavior, I'm just replacing the in compiletest with for now. I'd be willing to PR this change as a standalone if desired.
Thanks! That would be great
Yeah I am pretty sure I tested this when we changed Miri to a subtree, and it worked back then. How does looking for help? Looks to me like we'd have to know exactly which flags the regular test runner understands and parse them all the same way. E.g. should apply the filer but should not. Which is of course ridiculous. Can we stop bootstrap from passing wrong flags to test runners?
I suggest that we change the test runner argument parsing to error out if there is any filter starting with -- except after a . So, something like:
The source of the regression is Meanwhile should fix bootstrap invoking the Miri test suite.


<!-- 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
related. label F-inherentassociatedtypes
It caused by a cycle query:
There's a related bug to this (I believe by involving some traits with associated types) that I would like to report, though I was able to raise mine on Stable (1.70.0) without using the feature flag. Should I make a separate bug report or attach it here?
Regression in nightly-2023-02-21 found 9 bors merge commits in the specified range commit[0] 2023-02-19: Auto merge of - cjgillot:codegen-overflow-check, r=tmiasko commit[1] 2023-02-19: Auto merge of - clubby789:builtin-derived-attr, r=jackh726 commit[2] 2023-02-20: Auto merge of - fmease:iat-type-directed-probing, r=jackh726 commit[3] 2023-02-20: Auto merge of - tmiasko:read-buf, r=the8472 commit[4] 2023-02-20: Auto merge of - camelid:rustdoc-all-only-stable, r=GuillaumeGomez commit[5] 2023-02-20: Auto merge of - b-naber:proj-relate-variance, r=lcnr commit[6] 2023-02-20: Auto merge of - megakorre:issue_105700, r=petrochenkov commit[7] 2023-02-20: Auto merge of - matthiaskrgr:rollup-4tdvnx6, r=matthiaskrgr commit[8] 2023-02-20: Auto merge of - lnicola:rust-analyzer-2023-02-20, r=lnicola ERROR: no CI builds available between and within last 167 days I guess ?
Seems this has been fixed on the latest nightly, marked as E-needs-test. labels: +E-needs-test
this regressed again in


I tried this code (): I expected to see this happen: rustc outputs an error saying that I need to add the and traits on . Instead, this happened: which is jarring to see, and unhelpful, because HashMap does support Index, but only with particular trait bounds on . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reduced case: works as expected, perhaps it is caused when the implementer is not from the local crate?
claim


<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
almost exactly 3 years old :cake: :partying_face: :pinata: searched toolchains nightly-2020-04-17 through nightly-2023-04-22 Regression in nightly-2020-04-23 found 7 bors merge commits in the specified range commit[0] 2020-04-21: Auto merge of - spastorino:dyn-fnonce-alignment, r=nikomatsakis commit[1] 2020-04-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[2] 2020-04-22: Auto merge of - JohnTitor:rollup-vh6dut5, r=JohnTitor commit[3] 2020-04-22: Auto merge of - nnethercote:bitcode-in-rlib, r=alexcrichton commit[4] 2020-04-22: Auto merge of - Dylan-DPC:rollup-iunh61a, r=Dylan-DPC commit[5] 2020-04-22: Auto merge of - nnethercote:alphabetize-C-and-Z-options, r=petrochenkov commit[6] 2020-04-22: Auto merge of - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC probably ? cc
I feel like i've seen this before -- probably a dupe? Or at least I think I've chatted with about this.
Could be :D probably 90% of the ICEs I am seeing are already reported in some way or another and sometimes one might slip through
different stacktrace with debug assertions: `


All existing standard library documentation implicitly assumes that the APIs are being used between the start of a Rust and end of . For example  does not document any indication that the function would panic. It does not need to document that, because the function cannot panic, as long as the call occurs within the duration of . However it's possible to observe a panic like this: (Related PR and discussion: ) In general using the standard library from an callback, or before through a static constructor, is UB: according to "we can't really guarantee anything specific happens [...]; at least not in a cross-platform way." Is this worth calling out centrally as a caveat to all other documentation of the standard library? At the top level of the whole crate (it would perhaps be more prominent than it deserves), at the module level, or in the Reference? Certainly for , , , the expectation users need to have is that nothing in there will work outside of . Are there APIs it makes sense to carve out as being permissible outside of ? Stuff like , , , , etc. We'd maybe need to do research into how constructors and atexit are being used in the wild. For example the crate relies on , , and to be usable before : It seems obvious that those things should work but there isn't documentation which guarantees it. I assume that makes the crate technically unsound as written.
IMHO, core types should work in whatever context but libstd is more dicey. It more explicitly has a runtime or three (e.g. Rust's, libc's and the OS's). So at a minimum anything in the modules , , , , , , , etc should be regarded with suspicion unless documented otherwise. In summary, my thoughts are: is fine depends on the allocator used assumes code is running in main (except for the and possibly stuff)
Core types can still panic and panics do IO.
Hm... how much of an issue is that? Panics don't have to do I/O (e.g. if stderr is closed) so if platforms don't support that before or after main then it can be silently skipped, no?
But do we do that properly today? And it's not just IO but also panic hooks which in turn can rely on various other parts of std.
I think it would be fine to document that e.g. after main they may want to set an empty (or aborting) panic hook if panicking is possible. I really don't want to be in a situation where the user is in a worse place than if they'd just used .
Could we turn panics into immediate aborts after main? That would also avoid the backtrace printing and symbolication.
I looked through the standard library, and is the only function that has limitation on usage before/after main (in this case, this is only a problem during TLS destruction). This function is also called from , and , which can therefore panic when called during TLS destruction. and might be able to be reworked to avoid this, but this is fundamentally a limitation of since it requires a reference to the current to work. The stack guard used by the stack overflow handler also accesses the same TLS slot as , but since the stack bounds don't have a this could be moved to a separate to properly support stack overflow handling during TLS destruction.
If we're going to make a statement at all then imo we should start out with something more cautious than making solid guarantees since this would be a pretty wide-ranging promise. before/after main behavior is not tested. It is best-effort and if someone relies on it they should have their own tests core and alloc are expected to work because they don't touch OS APIs or global state caveat: user code in any hookable API like panic handlers, global allocators, OOM handler or any future hooks. Especially panics affect a lot of code. we might replace hooks after main? most existing parts of std, backtrace and other things interacting with the OS are expected to work but there may be platform-specific edge-cases and the behavior may change in the future due to changing implementation details or new features that depend more runtime state (e.g. a std threadpool or async runtime) then finally a list of known limitations
Proposed documentation based on my previous comment:


Tello-edu The says use my build failed with error <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc could you provide some input here? Thanks!
The rustdoc book documents rustdoc flags. You are passing this flag to cargo. I don't remember how to configure cargo for this argument off the top of my head, but you should look in the cargo book for how.
Oh wait, apparently the rustdoc book directly documents using this with it's probably just outdated then - I'll transfer this to rust-lang/rust.
Btw it works fine after taking out the "=examples"
claim


Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details


Inlining introduces unsized temporaries. This is problematic since unsized temporaries fail to uphold alignment requirements as described in . For example:
The unsized locals alignment issue itself was fixed in .


OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:


This is with Rust 1.69 but was probably always the case. Example: Compiling with prints Similarly when providing nothing changes. I didn't really follow how collects the libraries but I think it's via the query in which claims so this should be included AFAIU. Also the rationale of was to provide all libraries needed to link to the resulting , which is not the case in the above example. CC who originally implemented this feature.
It works as expected if the attribute is used in a dependencies. It seems to me that the function, is forgetting to add the current native libs. Doing something like this correctly adds to the output (even when passed via the command line) but I don't know if it's the right thing to do (cc
Yeah, I think adding is the correct fix. That adds the same information as does for dependencies.
Beware that is rather quirky. Originally Rust printed lines during build with information which link flags need to be to use the static library it builds, and is a blunt way of redirecting these "warnings". I don't know whether omission of is a bug or the old warnings just weren't meant to print them.
I can't imagine it to be a deliberate omission as is the only way to know how to correctly link any arbitrary staticlib afaik.


<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc is this fixed by one of your PRs? This looked like it might be , but while was bisected to this one was bisected to , not sure what to make of it :thinking:
Yes, this issue is fixed in (ice → errors): <details<summarystderr</summary</detailsI'm not sure why the bisection points differ, they all share the same root cause. It doesn't really matter though. Btw, I saw about another new reproducer but I dismissed it as irrelevant since I assumed it required , too (I did run it but didn't notice I could omit that flag). Sorry about that. Thanks for opening a separate issue because now we actually have 2 beautiful regression tests for the bug fixed in ! So let's not close this issue then but wait for to get merged and then I will open a separate PR with the regression tests & assign you. claim


<!-- 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. --My code does not compile any more after updating to 1.70.0. The project can be found I tried to create a minimal reproducer. It has something to do with glib's clone macro, which I use. Here is the reproducer that compiles fine on 1.69 but not on 1.70.0. I left some comments in the code describing what I observed so far. It needs and dependency): Output I expected to see this happen: The type is correctly inferred Instead, this happened: The compiler tells me that it doesn't know the type, although the type can be inferred <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.69.0 <!-- Provide the version you are using that has the regression. --:
regressed in cc slightly minimized and removed dependencies: Putting the identity function back (or wrapping the async block in a block) seems to "fix" the error: <details<summarybisector output</summarysearched nightlies: from nightly-2023-03-01 to nightly-2023-06-01 regressed nightly: nightly-2023-03-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details</details label -regression-untriaged +regression-from-stable-to-stable +A-inference +A-async-await
It is not only an identity function that makes this suddenly work, but putting the async block in a block works as well. Permuting what to wrap in a block, only a single case out of the four fails: Out of curiousity I tried the patch in thats supposed to fix to make async blocks "provide inference guidance", but that doesn’t work either.
This happens due to a hack in typeck, where function arguments that aren't closures, including block expressions that return closures, are typechecked before function parameters that are closures. Note that async blocks are desugared to closures. This basically means that closures and async blocks in function arguments behave as if they were ordered after all non-closure non-async-block arguments and you now get the same inference error that you would get on older compilers if you manually swapped the function arguments. (Also, looks like this hack has existed .)
Wow, that is a very good catch! And also good news, as it means "fixing" the regression should be a oneliner, which I will try tomorrow. However that does smell like a very gross hack, and I wonder if there will eventually be a better way altogether. But that is for a different day.
Note that just excluding desugared async block closures from this hack breaks inference for different programs that are now accepted on stable, for example:
you mean which are only accepted as of 1.70?
Yeah, I mean stable 1.70. But I guess it's better to break a constructed program that compiled for one stable version instead of breaking a real codebase that compiled for several stable versions.
I'd be fine landing a PR that excludes future-desugared async blocks from this hack.
I opened with a fix and regression test. Thanks so much for finding the code responsible for this, I sure would have gone crazy with this :-D As both the culprit PR and the 1.70 beta went through a crater run, we are wondering why this was never caught earlier? Is it correct to assume your code exhibiting this problem is closed source? Or is it in some public repo that is not yet scraped by crater?
My code is GPLv3 and can be found on GitHub. I've never heard of and I don't think it is scraped. But it would really cool if it could scrape my project, too. To actually build it, you also need some system libraries installed like glib2, gtk4, libadwaita, etc. No idea whether can handle this special case.
Crater should automatically pick up any public Rust project on github. But I’m not an expert on it by any means. Its quite possible that it ignores certain crates that depend on specific system libraries.
Your repo is on crater under the name "symphony", but it's failing to build due to outdated system libraries. <details<summarycrater log</summary</details
WG-prioritization assigning priority (). label -I-prioritize +P-high Note: unsure if we wanted to keep issues open when the fix is nominated for a backport


Sometimes when changing compiler internals, I run to make sure I didn't break tools and codegen backends. This also checks rust-analyzer by default, which is not very useful, I cannot break that. If we want to keep that, it would at least be useful to put it last so I can Ctrl-C out of it. Currently, rustfmt is checked after rust-analyzer. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
mentoring instructions: switch the order of these two lines:
points out that Cargo also isn't checked by default, so for consistency it would be nice for RustAnalyzer not to be either:
claim


I tried to enable vendoring in and then following the instructions given by . I expected to see this happen: All dependencies are vendored. Instead, this happened: To work around this, I need to explicitly use a nightly cargo. Caused by enabling the unstable cargo feature.
This also broke the rust-analyzer config as rust-analyzer fetches the workspace layout using the default toolchain which for most users is stable.
can we override the cargo that rust-analyzer uses? we should use the beta toolchain for consistency.
I can't find any configuration for that.
ok. i think we should consider reverting . why did you need a new cargo feature to make that PR work?
So, how are people going to dogfood unstable Cargo features before they get stabilized if rust-analyzer breaks on it? In any case, I used an unstable Cargo feature because I wanted to use the private dependency metadata in the rlib, and that means Cargo needs to actually mark the dependency as private, and that means needs to communicate this information to Cargo.
As a hack you could handle marking deps as private and public in .
I am stumbling over this too. So is the only workaround ?
You can also put between and to override the toolchain to use for just a single call. I'm not aware of any other workaround than using nightly or using the unstable with a recent enough stable/beta cargo.
This is no longer a problem since I think?
Does that also add RUSTC_BOOTSTRAP=1 to the vendor command shown by x.py?
Oh wait, I didn't see the manually invoked part.


<!-- 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. --Hello! :wave: I tried this code on Windows: I expected to see this happen: Success for an available address like and blocking forever (or until TCP timeout) for just like on Linux. Instead, this happened: the call never succeeds, not even for on Windows. Related: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Thanks for the report! My best guess from quickly glancing at the code is that the problem is here: This is using to convert seconds into an (aka ). Which means that it can become a negative timeout. If I'm right then the fix here would be to limit the timeout to or less.
claim
thanks for your work on this and pushing it over the finish line! :+1: :pray:


<!-- 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 --
Regressed in 1.58:
This was , whoops. I can work on this. claim


This code previously compiled fine, but as of ~2 weeks ago it began to fail on nightly and has continued to do so since. p.s. Is the output of suppose to be one day behind compared to the toolchain name? In any case, was the last working version, and onward trigger the error. modify labels: +regression-from-stable-to-nightly -regression-untriaged
cc
I can put up a fix for this. I suspected this might cause an issue but couldn't think how.


<!-- 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. --The generated page HTML contains , which is not valid as per the (which only allows ). This has been the case since , which moved this div from the body to the header. I believe browsers will open the body if an invalid tag is encountered in the header (which you can see in inspect elements, where every item in between are inside of ), or something like that. This causes at least one bug: the attribute, which expands into a , is not displayed on Chrome and Chromium-based browsers. You can see this in the  crate on Chrome ! Firefox ! Generated HTML: vs : Manually moving the tag to the header correctly displays the favicon: ! !
label A-rustdoc-ui T-rustdoc
Thanks for the detailed report! Fixing it tomorrow.


<!-- 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</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. 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
cc
Thanks for the ping. It seems to be that here it's not always the parent which has , sometimes its on the as-is. I'm not entirely sure when we need the (IIRC it doesn't work for my test case if I don't add ).
Now if I stick to only using and not its parent, the line ICEs on my PR's test case because it can't find the param index for the . cc sorry for the ping, but do you know if here is special somehow? The debug path for my PR's test case seems to have another layer compared to this issue's ICE example, namely . I think this is why getting for my PR test case's parent worked but not for this ICE?
going to look into this, I think using is correct and the bug is somewhere else :sweat_smile:


Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)


I'm basing this suggestion on two things. One, that if you follow it, the code compiles: and two, that the diagnostic help you get when you try to use a in the repeat position suggests something very similar, see "other cases." It would require the compiler to know that a value that is attempted to be repeated is able though, which I don't know whether it can, but I figured I'd suggest this, and you can reject it if it isn't possible to do. Alternatively, the help text could say something like "if the value can be made , consider creating [...]" I was inspired to make this issue based on the output you get when you try to use a as an array initializer. For instance, the code produces the output No response
hey why im getting this error message all over my github repository ! whenever i commit some changes, The first changes i able to create pull request but after some other changes im not able to do that why im getting these error ! Please help
I don't think your comment is related to this issue? If this is a problem you've encountered while trying to fix this issue, please reach out on instead.


<!-- 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
This one works okay:
This one also (Just proxying a type, that means that something strange with struct's generics):
Bisected to but it probably just bubbles up a pre-existing issue that the OP could be massaged to emit without this PR, cc author just in case.
This worked fine before 1.70.0 so it's a regression.
minimized
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Once this will be fixed.


's documentation says: However, is also specified to call the hook set with (unstable) which per its example is permitted to panic and thereby potentially unwind, and , a “likely” future version of might choose to panic on allocation failure instead. Therefore, the documentation should be changed to not imply that this function will always abort, which could be taken as a promise that it will never unwind. It also might be useful to expand the documentation of so that the text and not only the example code specifies that it's okay to unwind from the hook (and what happens if you don't). (See also which is broader but doesn't mention this aspect.) cc from label +A-allocators +T-libs-api <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim


Hashbrown crate starts fail when running: , , with: <details<summaryBacktrace</summary<pFor : </p</details
Could this be related to cc
I'm also seeing this on x86_64 with the recent nightlies: Update 1: It seems like in both cases it's related to cross. The original PR mentions problems with old versions. Could it be that cross needs to update their docker images? (Though they seem to be based on Ubuntu 20, which doesn't seem THAT old) Update 2: cross runs
Centos 7 used by i686-dist builder seems to use Binutils 2.27, dist-armv7 uses Binutils 2.32 and dist-various1 (so thumbv6m-none-eabi) uses Binutils 2.38. They all are indeed newer than:
hashbrown ci uses cross 0.2.5, which is the latest stable release for cross. To fix this issue with cross specifically, one can set the image used by cross to be a newer version, cross 0.2.5 images use ubuntu 16.04, we can change that with the env vars or config (see ) (make sure to set the correct env-var and image for the specific target)
The diagnostic looks similar to a binutils 2.41 change I made to fix ld: Allow RX8664GOTPCREL for call *_tlsgetaddr Threadlocal int a; int main() { return a; } % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no /tmp/ccSSBgrg.o: TLS transition from RX8664TLSGD to RX8664_GOTTPOFF against .text' failed failed to set dynamic section sizes: bad value collect2: error: ld returned 1 exit status There is incompatibility between  and with GNU ld<2.41. You may need to figure out where similar semantics are used.
Ran into this in github CI today as well (e.g. ). Works fine locally on Arch though when I try to recreate it. EDIT: Managed to reproduce it locally. I was mixing up -gnu and -musl targets, my bad.
Posted a revert at
This is really not a great solution for projects that build binaries for releases though (like I do). To target an old enough glibc to work on all systems (e.g. CentOS/RHEL, stable Debian, etc) you need to build on a fairly old distro. And then you also get older ld etc as well. It would be great if you could tell rust & gcc (for native dependencies) to target an older glibc than the system one, that would solve a lot of issues.
In GCC/Clang, can happen with . is to use modern GCC/Clang style . I am not sure why is related to the problem. I think I should keep arguing for for all targets, not just non-x86. is prone to cause such problems for GNU ld and possibly mold.
cc
I apologize to everyone, forgot about this issue. I can state that this issue is closed and no longer relevant. suggestion (as a workaround) and pull request fixed the issue.


<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --When using the syntax in the Display format in formatting macros, the is ignored and treated as a . I tried this code: I expected to see this happen: Getting an error that is out of the bounds for type . Instead, this happened: This function compiles and prints . <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I went and looked through the implementation and found where the issue comes from. The check at ignores the integer type, and it blindly calls on the value of the literal.
claim
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Did run a bisection on the reproducible provided (and duplicated ) Regression in nightly-2023-04-22, specifically I think commit or (as pointed out in PR ) found 11 bors merge commits in the specified range commit[0] 2023-04-20: Auto merge of - m-ou-se:fmt-lang-items, r=jyn514 commit[1] 2023-04-20: Auto merge of - m-ou-se:flatten-format-args, r=oli-obk commit[2] 2023-04-21: Auto merge of - c410-f3r:dqewdas, r=petrochenkov commit[3] 2023-04-21: Auto merge of - jsoref:spelling-src-etc, r=Mark-Simulacrum commit[4] 2023-04-21: Auto merge of - matthiaskrgr:rollup-, r=matthiaskrgr commit[5] 2023-04-21: Auto merge of - cjgillot:query-feed, r=oli-obk commit[6] 2023-04-21: Auto merge of - michaelvanstraten:master, r=petrochenkov commit[7] 2023-04-21: Auto merge of - petrochenkov:qcstore4, r=cjgillot commit[8] 2023-04-21: Auto merge of - saethlin:mir-pass-cooperation, r=cjgillot commit[9] 2023-04-21: Auto merge of - cjgillot:const-prop-lint-junk, r=oli-obk commit[10] 2023-04-21: Auto merge of - Dylan-DPC:rollup-em3ovcq, r=Dylan-DPC cc
Looks like it's not easy invoke the same integer-literal-range-checking code from the place where formatargs!() is expanded. So the easiest solution is probably to expand to something like when literals are removed, such that the literals are still be checked later.
Actually, looks like there is a much easier fix that mostly just involves removing code. ^^' Will send a PR soon, probably tomorrow.
Fix:


<!-- 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 this all to be fine. Instead, the final assertion fails, and the formatting is done like this in the final case: Not sure why 2 decimal places are returned, looks like a bug. This bug also exists in the beta or nightly versions, running in Rust Playground. Discussion: Edit: after looking around the compiler code for the first time I think the problem is somewhere in either or . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
No. The relevant code is actually the one for formatting integers in scientific notation, not floats. I. e. the relevant code is the code first introduced in As I mentioned in the linked URLO thread, I believe perhaps integer formatting in scientific notation should be fully identically behaving to the (seemingly "correct", and also historically older) formatting implementation for floats. This is a potential test we might want passing: but as of now, this kind of test fails in a lot of cases: In this test result, besides the behavior described in this issue, resulting in the wrong number of digits, there’s also the rounding behavior that is different between displaying floats and ints here. I’m not sure whether or not this difference is wanted. If it is_ wanted, it should be properly documented (on that note, I couldn’t easily find any documentation on the rounding used for floats, either), if it isn’t, it would be yet another issue or bug.
I would like to try and fix this bug claim


Reported on discord, using will fail on Windows if the file is hidden. This also affects methods like or that open the file the same way. The reason for this is that we use , which has : So to make it work the caller needs to match the requested attributes to the existing attributes at the time of opening. It was suggested we could instead use and then manually truncate the file using to zero.
Manually truncating would require also clearing the alternate data streams too, right? And it would presumably stop erroring if another process still has the file open and instead corrupt the file fron the view of the other process.
No? The proposed solution would work the same was as in the case where the file already exists. Which we use for .
Right, got confused with .


The documentation currently says But it also doesn't have an effect if the two lengths are equal, so I think it should say "greater or equal to the vector's current length". <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
yes, there is a trivial difference between and , but it's an internal implementation issue, I think we should update the doc since they are same from the user's view.
claim