For details see , opening an issue since PR was closed:
While this one particular test case was fixed, the transformation still suffers from issues hinted at earlier comment: assumes that terminator always switches on a local that was assigned last in the block. The assumption is false. moves a read of a discriminant from the second block into first without ensuring that it holds the same value still. some executions it introduces a read that would not have happen otherwise and could have an undefined behaviour. some executions it skips execution of statements from one the blocks without checking if they are side-effect free. cc
, EarlyOtherwiseBranch only applies to basic blocks of which the last statement is a discriminant (and the terminator is a switch): And, We could require the discriminant read in the second basic block to be the only statement within the block. Not sure by how much would the change affect optimization hit rate, but at least the example in would still be optimized. What makes me really concerned is this one: When would the first discriminant be safe but not the second? The example you constructed is a legit one: the second read assumes the value of the first read and does a downcast; that is the case my patch catches. The only other possible invalid case I could think of, is that when the second discriminant call's argument is an invalid pointer. Probably something like: But today the MIR that FE emits dodges the problem by accident: Because these two switch instructions have different blocks. So, my guess is, even though EarlyOtherwiseBranch is unsound, today the compiler FE is still unable to produce MIR that could trigger that.
If one considers shape of MIR immediately after it has been built, that is probably true. One thing to keep mind: this transformation runs on MIR that have been transformed already. In fact, the whole optimization pipeline might have run an arbitrary number of times as a result of inlining. Transformations shouldn't rely on any invariants that aren't preserved by all transformations. The might be unrelated to a local used in switch, since this is not checked anywhere. Last time out of curiosity I an assertion checking that, enabled the transform by default and bootstraped rustc, the assertion did fail.
Ah! I misunderstood your point , but now I get it. You are right. I think we could resolve your , , and by adding the following restrictions: discriminant read in the second block must be the only statement in there; switch must use the value of the discriminant read. But I found that the same effect of EarlyOtherwiseBranch could be achieved through a much easier change; we could provide a hint for LLVM optimizer to compare the discriminant values before entering the switch, e.g.: With this hint, (unfortunately, isn't enough) produces: IMO this is much more elegant than EarlyOtherwiseBranch; it should also be pretty easy to implement, so I will give it a try.


<!-- 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. --Playground stable: Playground nightly: Somewhat similar to Edit: Actually, it's identical except this is with two lifetimes. Edit 2: And this one crashes stable, while the other does not. Also crashes without enabling features, and complains that However, constraining removes this error, but not the crash. Two lifetimes are required for the crash. <!-- 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. --: Also crashes on Rust Playground with stable <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
glacier ""
Seems related to
No longer ICEs since


<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --from <!-- 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 is probably
Hm, the issue is already a couple of weeks old while I was not able to reproduce this one a few days ago.
This happens since :thinking:
modify labels: +requires-nightly
Yes, this is a duplicate of . The changes from fixed the validator, so the bug is now correctly identified when incorrect transform is enabled with .
Does it still ICE if you enable optimizations?
It does, looks like it's still an ICE
This (and ) no longer ICE since , seems to be the case for any opt level cc is that intentional or is still pending?
This is only the case because the changes to MIR make that opt completely broken and just never fire under any circumstances. needs to be revised because of that change, but the plan is still for it to fix these bugs for real


<!-- 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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by
Assigning and removing .
This ICEs since modify labels: +regression-from-stable-to-stable


When forgetting to include parenthesis around a tuple pattern in a for loop, the compiler gives a suggestion to use an or pattern. I would expect this, a. because it's not what most would expect if you use a comma to separate two values in a pattern, and b. because or patterns in for loops are still an unstable feature. I tried this code: As expected, the compiler gives an , error, because I forgot the parenthesis around . However, the compiler also suggests that I add a "vertical bar to match on multiple alternatives". While it does provide the correct answer (adding parenthesis), it also provides the vertical bar option, which is an unstable feature in this . While the RFC does not explicitly single out for loops as a situation where this is necessary, I believe it does apply here, because in (credit /u/ehuss for the example, which is a situation where the or pattern syntax is being used correctly, I get a error, as expected, and including resolves the error. I tested this on stable, beta, and nightly in the rust playground. The output is identical for all 3 of them. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I would like to work on this, if possible Would it just be only giving if like ?
that seems like the right approach :)
claim
Looking at this more closely I'm not sure the fix is that simple, since and seems to (Which matches the comment for )
Looking at usages of GateOr::{Yes, No}, it looks like the only top level things (Which are the only ones that give the suggestion AIUI) that are GateOr::Yes are local variable declaration patterns and for patterns EDIT: I'm gonna try just propagating the GateOr into mayberecoverunexpected_comma


<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Compiler error on but ICE on label +regression-from-stable-to-stable
cc
A previous (now-fixed) ICE with the same error message is
Thanks for the report! Would be good to get a better backtrace; this one seems to be missing many frames and there are no line numbers.
, I updated the backtrace in my first post. I used rustup to get the latest trunk version, and the one I have been using does not have line numbers. If there is a flag or configuration for rustup to get rustc binaries with line numbers, I would be happy to change the settings on my testing machine.
I think getting line numbers requires a debug build of the compiler, so it's not quite as easy as installing something via rustup.
Labeling .
Here's a backtrace with debug info: <details</details
Unfortunately, this bottoms out ; more digging will be needed to determine the true underlying cause of the error.
Here is the actual backtrace of the underlying CTFE/Miri error: <details</detailsIt points to this line: can handle pointer values just fine, so I think what is happening is that we are reading parts of a pointer value here, which indeed is not supported in CTFE.
So... I guess the fix is to make this kind of error also be permitted during validation and turn it into a proper validation error?
Permitting it at the top-level is no good, since then we don't know "where in the value" it arose. We need a version of that catches this error and turns it into a validation error with the current "path".
Oh... right, we should fix this in general, and not just wrap in . Maybe we should not have any automatic way to bubble up errors and require all sites to use ?
I think we should wrap it but put the wrapped thing into a helper function sow e can also use it for the other places. So basically, you want to use a different error type for validation, one that excludes all the other errors? I am open to refactorings here.
Let's start out with wrapping, and then I can experiment with the refactoring so we can have a look at the usability effect of it Instructions: wrap the call at in a macro invocation and capture the error. Emit a validation message about the fact that reading parts of a pointer is not possible during CTFE. Don't forget to add a test (the failing example from this issue works great as a test) and run the test with
There are quite a few calls in that will all have this problem, so ideally they should all be treated this way. To avoid code duplication, it will probably make sense to move this into a helper function.
Reopening this to track that is still called unguarded a few times in , so e.g. the issue can still arise with .


is not actually allfalse - will return . It would be nice to rename it to at some point (and maybe add while we're at it). cc Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I'll either get to it before next week is over or when is merged, whichever comes first


The test in leaks memory, which makes a Miri run of the test suite fail: Running Miri on the test suite is helpful to find bugs, so we should avoid deliberate leaks to still be able to detect accidental ones. Can the test be changed to use some other means of ensuring that is not called, e.g. with a type? Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim I made the test I should fix it
thanks. :-) Let me know if you need any help.


I'm afraid I haven't minimised this test case. This doesn't seem to be a very serious problem as the compiler has correctly pointed out syntax errors; fixing those syntax errors makes the ICE go away. But since it suggested filing a bug I repro'd with today's nightly and have done so. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</details<detailsthread 'rustc' panicked at 'Stack should be empty: finalbuf=FrameData { open: 156:12 (), inner: [(Token(Token { kind: BinOp(And), span: 156:13 () }), Alone), (Token(Token { kind: Ident("self", false), span: 156:17 () }), Joint), (Token(Token { kind: Comma, span: 156:18 () }), Alone), (Token(Token { kind: Ident("s", false), span: 156:20 () }), Joint), (Token(Token { kind: Colon, span: 156:21 () }), Alone), (Token(Token { kind: BinOp(And), span: 156:23 () }), Alone), (Token(Token { kind: Ident("dyn", false), span: 156:26 () }), Alone), (Token(Token { kind: Ident("AsRef", false), span: 156:32 () }), Joint), (Token(Token { kind: Lt, span: 156:33 () }), Alone), (Token(Token { kind: Ident("str", false), span: 156:36 () }), Joint), (Token(Token { kind: Gt, span: 156:37 () }), Alone), (Token(Token { kind: RArrow, span: 156:40 () }), Alone), (Token(Token { kind: Ident("String", false), span: 156:47 () }), Alone), (Delimited(DelimSpan { open: 156:49 (), close: 178:4 () }, Brace, TokenStream([(Token(Token { kind: Pound, span: 157:6 () }), Alone), (Delimited(DelimSpan { open: 157:7 (), close: 157:18 () }, Bracket, TokenStream([(Token(Token { kind: Ident("throws", false), span: 157:13 () }), Alone), (Delimited(DelimSpan { open: 157:14 (), close: 157:17 () }, Paren, TokenStream([(Token(Token { kind: Ident("AE", false), span: 157:16 () }), Alone)])), Alone)])), Alone), (Token(Token { kind: Ident("fn", false), span: 158:7 () }), Alone), (Token(Token { kind: Ident("inner", false), span: 158:13 () }), Alone), (Delimited(DelimSpan { open: 158:14 (), close: 178:4 () }, Paren, TokenStream([(Token(Token { kind: Ident("self", false), span: 158:19 () }), Joint), (Token(Token { kind: Colon, span: 158:20 () }), Alone), (Token(Token { kind: BinOp(And), span: 158:22 () }), Alone), (Token(Token { kind: Ident("Self", false), span: 158:26 () }), Joint), (Token(Token { kind: Comma, span: 158:27 () }), Alone), (Token(Token { kind: Ident("s", false), span: 158:29 () }), Joint), (Token(Token { kind: Colon, span: 158:30 () }), Alone), (Token(Token { kind: BinOp(And), span: 158:32 () }), Alone), (Token(Token { kind: Ident("dyn", false), span: 158:35 () }), Alone), (Token(Token { kind: Ident("AsRef", false), span: 158:41 () }), Joint), (Token(Token { kind: Lt, span: 158:42 () }), Alone), (Token(Token { kind: Ident("str", false), span: 158:45 () }), Joint), (Token(Token { kind: Gt, span: 158:46 () }), Alone), (Token(Token { kind: RArrow, span: 158:49 () }), Alone), (Token(Token { kind: Ident("String", false), span: 158:56 () }), Alone), (Delimited(DelimSpan { open: 158:58 (), close: 176:6 () }, Brace, TokenStream([(Token(Token { kind: Ident("let", false), span: 159:10 () }), Alone), (Token(Token { kind: Ident("s", false), span: 159:12 () }), Alone), (Token(Token { kind: Eq, span: 159:14 () }), Alone), (Token(Token { kind: Ident("s", false), span: 159:16 () }), Joint), (Token(Token { kind: Dot, span: 159:17 () }), Alone), (Token(Token { kind: Ident("asref", false), span: 159:23 () }), Alone), (Delimited(DelimSpan { open: 159:24 (), close: 159:25 () }, Paren, TokenStream([])), Alone), (Token(Token { kind: Semi, span: 159:26 () }), Alone), (Token(Token { kind: Ident("let", false), span: 160:10 () }), Alone), (Token(Token { kind: Ident("re", false), span: 160:13 () }), Alone), (Token(Token { kind: Eq, span: 160:15 () }), Alone), (Token(Token { kind: Ident("Regex", false), span: 160:21 () }), Joint), (Token(Token { kind: ModSep, span: 160:23 () }), Alone), (Token(Token { kind: Ident("new", false), span: 160:26 () }), Alone), (Delimited(DelimSpan { open: 160:27 (), close: 160:38 () }, Paren, TokenStream([(Token(Token { kind: Literal(Lit { kind: StrRaw(0), symbol: " suffix: None }), span: 160:37 () }), Alone)])), Alone), (Token(Token { kind: Dot, span: 160:39 () }), Alone), (Token(Token { kind: Ident("expect", false), span: 160:45 () }), Alone), (Delimited(DelimSpan { open: 160:46 (), close: 160:56 () }, Paren, TokenStream([(Token(Token { kind: Literal(Lit { kind: Str, symbol: "bad re!", suffix: None }), span: 160:55 () }), Alone)])), Alone), (Token(Token { kind: Semi, span: 160:57 () }), Alone), (Token(Token { kind: Ident("let", false), span: 161:10 () }), Alone), (Token(Token { kind: Ident("mut", false), span: 161:14 () }), Alone), (Token(Token { kind: Ident("errs", false), span: 161:19 () }), Alone), (Token(Token { kind: Eq, span: 161:21 () }), Alone), (Token(Token { kind: Ident("vec", false), span: 161:25 () }), Joint), (Token(Token { kind: Not, span: 161:26 () }), Alone), (Delimited(DelimSpan { open: 161:27 (), close: 161:28 () }, Bracket, TokenStream([])), Alone), (Token(Token { kind: Semi, span: 161:29 () }), Alone), (Token(Token { kind: Ident("let", false), span: 162:10 () }), Alone), (Token(Token { kind: Ident("out", false), span: 162:14 () }), Alone), (Token(Token { kind: Eq, span: 162:16 () }), Alone), (Token(Token { kind: Ident("re", false), span: 162:19 () }), Joint), (Token(Token { kind: Dot, span: 162:20 () }), Alone), (Token(Token { kind: Ident("replaceall", false), span: 162:31 () }), Alone), (Delimited(DelimSpan { open: 162:32 (), close: 170:9 () }, Paren, TokenStream([(Token(Token { kind: Ident("s", false), span: 162:33 () }), Joint), (Token(Token { kind: Comma, span: 162:34 () }), Alone), (Token(Token { kind: BinOp(Or), span: 162:36 () }), Alone), (Token(Token { kind: Ident("caps", false), span: 162:40 () }), Joint), (Token(Token { kind: Colon, span: 162:41 () }), Alone), (Token(Token { kind: BinOp(And), span: 162:43 () }), Alone), (Token(Token { kind: Ident("regex", false), span: 162:48 () }), Joint), (Token(Token { kind: ModSep, span: 162:50 () }), Alone), (Token(Token { kind: Ident("Captures", false), span: 162:58 () }), Joint), (Token(Token { kind: BinOp(Or), span: 162:59 () }), Alone), (Delimited(DelimSpan { open: 162:61 (), close: 170:8 () }, Brace, TokenStream([(Token(Token { kind: Ident("let", false), span: 163:12 () }), Alone), (Token(Token { kind: Ident("kw", false), span: 163:15 () }), Alone), (Token(Token { kind: Eq, span: 163:17 () }), Alone), (Token(Token { kind: Ident("caps", false), span: 163:22 () }), Joint), (Token(Token { kind: Dot, span: 163:23 () }), Alone), (Token(Token { kind: Ident("get", false), span: 163:26 () }), Alone), (Delimited(DelimSpan { open: 163:27 (), close: 163:29 () }, Paren, TokenStream([(Token(Token { kind: Literal(Lit { kind: Integer, symbol: "1", suffix: None }), span: 163:28 () }), Alone)])), Alone), (Token(Token { kind: Dot, span: 163:30 () }), Alone), (Token(Token { kind: Ident("expect", false), span: 163:36 () }), Alone), (Delimited(DelimSpan { open: 163:37 (), close: 163:51 () }, Paren, TokenStream([(Token(Token { kind: Literal(Lit { kind: Str, symbol: "$1 missing!", suffix: None }), span: 163:50 () }), Alone)])), Alone), (Token(Token { kind: Dot, span: 163:52 () }), Alone), (Token(Token { kind: Ident("asstr", false), span: 163:58 () }), Alone), (Delimited(DelimSpan { open: 163:59 (), close: 163:60 () }, Paren, TokenStream([])), Alone), (Token(Token { kind: Semi, span: 163:61 () }), Alone), (Token(Token { kind: Ident("if", false), span: 164:11 () }), Alone), (Token(Token { kind: Ident("kw", false), span: 164:14 () }), Alone), (Token(Token { kind: EqEq, span: 164:17 () }), Alone), (Token(Token { kind: Literal(Lit { kind: Str, symbol: "", suffix: None }), span: 164:20 () }), Alone), (Delimited(DelimSpan { open: 164:22 (), close: 164:45 () }, Brace, TokenStream([(Token(Token { kind: Ident("return", false), span: 164:29 () }), Alone), (Token(Token { kind: Literal(Lit { kind: Str, symbol: "", suffix: None }), span: 164:32 () }), Joint), (Token(Token { kind: Dot, span: 164:33 () }), Alone), (Token(Token { kind: Ident("toowned", false), span: 164:41 () }), Alone), (Delimited(DelimSpan { open: 164:42 (), close: 164:43 () }, Paren, TokenStream([])), Alone)])), Alone), (Token(Token { kind: Ident("let", false), span: 165:12 () }), Alone), (Token(Token { kind: Ident("v", false), span: 165:14 () }), Alone), (Token(Token { kind: Eq, span: 165:16 () }), Alone), (Token(Token { kind: Ident("self", false), span: 165:21 () }), Joint), (Token(Token { kind: Dot, span: 165:22 () }), Alone), (Token(Token { kind: Ident("get", false), span: 165:25 () }), Alone), (Delimited(DelimSpan { open: 165:26 (), close: 165:29 () }, Paren, TokenStream([(Token(Token { kind: Ident("kw", false), span: 165:28 () }), Alone)])), Alone), (Token(Token { kind: Semi, span: 165:30 () }), Alone), (Token(Token { kind: Ident("v", false), span: 166:10 () }), Joint), (Token(Token { kind: Dot, span: 166:11 () }), Alone), (Token(Token { kind: Ident("unwraporelse", false), span: 166:25 () }), Alone), (Delimited(DelimSpan { open: 166:26 (), close: 169:11 () }, Paren, TokenStream([(Token(Token { kind: OrOr, span: 166:28 () }), Alone), (Delimited(DelimSpan { open: 166:29 (), close: 169:10 () }, Brace, TokenStream([(Token(Token { kind: Ident("errs", false), span: 167:15 () }), Joint), (Token(Token { kind: Dot, span: 167:16 () }), Alone), (Token(Token { kind: Ident("push", false), span: 167:20 () }), Alone), (Delimited(DelimSpan { open: 167:21 (), close: 167:35 () }, Paren, TokenStream([(Token(Token { kind: Ident("kw", false), span: 167:23 () }), Joint), (Token(Token { kind: Dot, span: 167:24 () }), Alone), (Token(Token { kind: Ident("toowned", false), span: 167:32 () }), Alone), (Delimited(DelimSpan { open: 167:33 (), close: 167:34 () }, Paren, TokenStream([])), Alone)])), Alone), (Token(Token { kind: Semi, span: 167:36 () }), Alone), (Token(Token { kind: Literal(Lit { kind: Str, symbol: "", suffix: None }), span: 168:13 () }), Joint), (Token(Token { kind: Dot, span: 168:14 () }), Alone), (Token(Token { kind: Ident("toowned", false), span: 168:22 () }), Alone), (Delimited(DelimSpan { open: 168:23 (), close: 168:24 () }, Paren, TokenStream([])), Alone)])), Alone)])), Alone)])), Alone)])), Alone), (Token(Token { kind: Semi, span: 170:10 () }), Alone), (Token(Token { kind: Ident("if", false), span: 171:9 () }), Alone), (Token(Token { kind: Not, span: 171:11 () }), Alone), (Token(Token { kind: Ident("errs", false), span: 171:16 () }), Joint), (Token(Token { kind: Dot, span: 171:17 () }), Alone), (Token(Token { kind: Ident("isempty", false), span: 171:25 () }), Alone), (Delimited(DelimSpan { open: 171:26 (), close: 171:27 () }, Paren, TokenStream([])), Alone), (Delimited(DelimSpan { open: 171:29 (), close: 174:8 () }, Brace, TokenStream([(Token(Token { kind: Ident("throw", false), span: 172:14 () }), Joint), (Token(Token { kind: Not, span: 172:15 () }), Alone), (Delimited(DelimSpan { open: 172:16 (), close: 173:34 () }, Paren, TokenStream([(Token(Token { kind: Ident("anyhow", false), span: 172:22 () }), Joint), (Token(Token { kind: Not, span: 172:23 () }), Alone), (Delimited(DelimSpan { open: 172:24 (), close: 173:33 () }, Paren, TokenStream([(Token(Token { kind: Literal(Lit { kind: Str, symbol: "bad substitution(s) {:?} in {:?}", suffix: None }), span: 172:58 () }), Joint), (Token(Token { kind: Comma, span: 172:59 () }), Alone), (Token(Token { kind: BinOp(And), span: 173:25 () }), Alone), (Token(Token { kind: Ident("errs", false), span: 173:29 () }), Joint), (Token(Token { kind: Comma, span: 173:30 () }), Alone), (Token(Token { kind: Ident("s", false), span: 173:32 () }), Alone)])), Alone)])), Alone), (Token(Token { kind: Semi, span: 173:35 () }), Alone)])), Alone), (Token(Token { kind: Ident("out", false), span: 175:10 () }), Joint), (Token(Token { kind: Dot, span: 175:11 () }), Alone), (Token(Token { kind: Ident("into", false), span: 175:15 () }), Alone), (Delimited(DelimSpan { open: 175:16 (), close: 175:17 () }, Paren, TokenStream([])), Alone)])), Alone), (Token(Token { kind: Ident("inner", false), span: 177:10 () }), Alone), (Delimited(DelimSpan { open: 177:11 (), close: 177:19 () }, Paren, TokenStream([(Token(Token { kind: Ident("self", false), span: 177:15 () }), Joint), (Token(Token { kind: Comma, span: 177:16 () }), Alone), (Token(Token { kind: Ident("s", false), span: 177:18 () }), Alone)])), Alone), (Token(Token { kind: Question, span: 177:20 () }), Alone)])), Alone)])), Alone)] } stack=[FrameData { open: 1:1 (), inner: [(Token(Token { kind: Ident("fn", false), span: 156:5 () }), Alone), (Token(Token { kind: Ident("subst", false), span: 156:11 () }), Alone)] }]', </details
Minimized: proc macro
modify labels -E-needs-mcve +A-proc-macros
Is the solution possibly to just remove the offending assertion? The token stream will be nonsense but some other error reporting should catch the mismatched delimiters, I'd assume?
I just quickly tried the suggestion above (removing the assertion) and this is the error I got without it: Note that I tried a slightly simpler version of the small repro above: This still fails with ICE with the assertion.
I think I'm seeing the same issue with code containing a similar syntax error: The error is the fn does not have the closing paren. I see this on both release and debug builds: stable: beta: Nightly: Here is the error and stack from Rust Playground:


Repro: As of current nightly: This is the unreachable line: The same crash reproduces back to 1.47.0. Older stable compilers do not crash:
Bisect: searched nightlies: from nightly-2020-07-10 to nightly-2020-08-27 regressed nightly: nightly-2020-07-22 searched commits: from to regressed commit: () Mentioning because appears the most relevant.
Assigning .


When you write a mod with a capital name of a keyword, we suggest changing it to the lowercase version of the keyword, which is, well, a keyword and not going to work. We should suggest converting the identifier to snake case and making it a raw identifier, or maybe suggest switching to an altogether separate name? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hey you might want to comment here to claim this issue :)
claim


<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Note: Same error on stable and beta. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
this works for me on latest nightly. If you update your version of the compiler, does it work for you?
Oh oops, I was missing , sorry:
Slightly smaller: If you change to , it works, so I think this is while trying to infer .
glacier ""
This issue has been fixed by , marking as .


As it is currently written, E0207 talks entirely about type parameters. Now that const parameters also need to constrain implementations (under the same rules described for types), they also need to be mentioned in the error explanation. Since other items don't require const parameters to be used at all, we might also want to specifically call out this difference here. Furthermore, E0207 triggers if you use an unconstrained lifetime in an associated type, and this is completely unspecified by the error as well. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


The following code errors, and the error contains a suggestion how to fix the error: The error message states: Obviously, writing is invalid syntax.
It seems the issue is that it's inserting the suggestion after the trait name and before the generics, rather than after the generics.
No-nightly-features code that exhibits the same problem: label -requires-nightly (should the F-labels go as well?)


Rustdoc on [nightly documents][1] methods have signature of as while it only has to document it as . ! On [rustdoc stable][2], things are normal: ! : Version 1.49.0 ( 2020-12-29) [1]: [2]:
I'd like to investigate this :)
searched nightlies: from nightly-2020-12-29 to nightly-2021-01-22 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: This regressed in , so this is probably caused by
This also affects Where will generate:
So a few observations: which displays mutability in patterns, causing to be displayed the mechanism for detecting and eliding works by , but as returns instead of , the comparison fails and displays the type.
I see two path to solving this bug: an option for to not display the mutability in patterns revert cc what do you think?
I would prefer to go for 1, there's no reason to have two completely different functions for pretty-printing.
Assigning and removing as in the prioritization working group.
(now a beta regression)


Since a few weeks we are getting an unrelated failure in a ui test where the order of two diagnostics changes. It is not entirely random, since it only changes if there are compiler changes, but we should still find and fix it <details<summary<iClick to see the possible cause of the failure (guessed by this bot)</i</summary</detailsOriginally posted by in
The first time I've seen it was in The second time in
This happened to me in too.
This could be happening because , declared here: is being traversed here: and thus we get non-determinism in the output... Two obvious solutions: change to a sorted map structure in the declaration, or normalize the order before traversing in the loop in
cc


The following comment causes a panic in jsondocck currently: Expected: Pretty error like 'Invalid split pattern on line X' Current: Giant stack trace, only obvious if you know what that line is doing. Opening this for tracking and so I don't forget to fix it <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assign (since you said "so I don't forget to fix 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. --Original: Minimized: <!-- 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 --
When running with , the last few lines before the panic are: seems relevant since it has a impl:
Minimized: rust pub struct Generic<T(T); impl<'astd::ops::Deref for Generic<&'a mut (){ type Target = Generic<&'a (); fn deref(&self) -&Self::Target { unimplemented!() } } impl<'aGeneric<&'a (){ pub fn some_method(&self) {} }
searched nightlies: from nightly-2020-11-12 to nightly-2021-01-17 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed in . label regression-from-stable-to-nightly
cc - do you have time to figure out what's going wrong here?
Yes, I believe so, I'll see what I can do here. claim
Please ping me once you open the PR ( is taking a break :) )
The core issue is the recursion cycle handling... It focuses only on s and wasn't anticipating targets that differ only in generic type args. I believe I see the tweak we'll need here, so I should have a PR in the next day or so.


This is derived from , in which we concluded that the bug should be filed against rustc, as it's an problem. In rustc: Then in a project using this toolchain via a rustup link: But note that does not make this work either, so there is probably more to it? Thanks <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
[removed comment, wrong issue, sorry]
(I think you posted that comment in the wrong place.)
Oops, yes.
Can anyone comment on what the correct fix for this might be? I notice that if I copy and from into then I'm able to run via the linked toolchain. I initially considered changing rustup to add to the PATH, but that seems incorrect as we would be adding something outside of the toolchain root to PATH. So should x.py copy or move the binaries from into ? I'm willing to (attempt to) do the work if we can agree on what the correct fix is.
I'm not really knowledgeable about . You might want to ask in on Zulip.
Yes, it should copy the binaries from stage1-tools-bin to stage1/bin.
Mentoring instructions: Add a new argument to the macro that says whether the tool should be to the sysroot, then copy it into the sysroot just after
I believe this will be fixed by , once we figure out some problems with clippy/fmt builds.
claim


When I install the latest master toolchains via and try to build with them, linking fails: I did some bisection, and it looks like the problem started happening with Cc
The error is actually already mentioned in However, I am building Miri with cargo, so I don't know how I'd "use LLD instead".
Hm, we probably need to revert that PR. I did not realize we'd need lld downstream too, I thought that was only on our builder. cc
Yes, a revert seems appropriate. We're going to have to figure out where that's actually coming from. The only change I saw between 10 and 11 by grepping was the removal of llgo, but maybe there's some bad remnant.
Yeah, I thought this issue would be limited to the rustc build, but it makes sense that it can also affect project linking against rustc shared objects. I've looked a bit into what the root cause is, and what I have so far as that the symbol comes from and is present as a weak symbol both when compiling with clang-10 and clang-11. The only difference I see from is this: So apparently was treated as a symbol of the library, while now it's treated as a symbol of -- I'm not sure what that actually means, but presumably that refers to the compiler runtime libraries. My guess is that previously it just ended up being nulled out as a missing weak symbol, but now it's actually being found and linking fails because ... reasons. I'm not good at linkers :) Edit: shows these as:
can you prepare a revert PR?
Done in . If nobody has an idea on how to avoid the linker error, two more options would be to comment out the symbol in our llvm-project fork, or to avoid upgrading clang altogether and just build both Python 2 and Python 3 for that image.
The issue is probably going to be in how exactly the objects that comprise are compiled, not linked. I suspect just ends up ignoring the malformed object or otherwise not reporting the issue, but the object and the relevant symbols ultimately end up in the anyway. Alas, reasons these obscure failures can occur are many – I've seen them occur from things as trivial as forgetting to . The question is: is there perhaps a way to disable ExecutionEngine entirely? Intuitively nothing we do should depend on that code. And if not, I'm comfortable patching out in our fork as we get closer to Feb 11 and continue having trouble pinpointing exact cause of this problem.
We normally don't link ExecutionEngine, but dist-x8664-linux in particular builds LLVM with ThinLTO, in which case we link as shared, instead of statically linking individual components into rustcllvm.
It seems to be possible to configure the components in using , but I'm not sure to what degree we can restrict those (not sure if this job also ships LLVM tools).
So, I think we could have used to exclude unnecessary parts from , as LLVM tools can still statically link the parts not in the dylib. But in the end, we can't use the option anyway due to
Looks like I'm getting this locally when trying to bootstrap rustc (while building ), might happen since the llvm upgrade but I'm not 100% sure. Are there some workarounds I can put into my for this? I'm using lld to link. <details<summaryBacktrace</summary<p</p</details
which commit are you trying to build?
latest git master
Probably best to open a new issue then; this one has been closed and the steps to reproduce it still work without error -- you might be having a different problem.
Opened
Did anyone file an upstream bug report about this? I'm observing it outside of Rust, but with a similar setup ( with lld+ThinLTO, then linking it into a binary with ). If not, I'd try to build a reproducer.
I've opened for this.
The bug has been fixed, the fix will be in LLVM 12.0.1.
Thanks! We can try updating clang again once the 12.0.1 tag is there.


<!-- 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. --ICE in illegal code in static block, rustc stable/beta/nightly. Found and reduced by <!-- 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. --: Also happens with <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning and removing as in the prioritization working group.


<!-- 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. --This ICE is related to : <!-- 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</detailsIdeally, would compile, but generic associated types in trait paths are currently not implemented. Maybe rustc could give a nice error message when the is missing.
Duplicate to and related heavily to others. But this has a nice minimal repro, so worth leaving open. Probably fixed by .
I've tested this locally and I can confirm that fixes this (with this change: ).


<!-- 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 think this issue is more than an internal compiler error, so I report here. I tried this code: The md5 of is: I expected to see this happen: normal compilation Instead, this happened: rustc crashes <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --I test it on nightly, beta, and stable versions. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
I am not sure whether it is a security-oriented bug. If so, please close this. But I guess it is ok to be public. Thanks.
This is an explicit : So just an ICE, just somebody used an instead of a .
is the that's being executed.
The problem is that the parsing code is attempting to emit a fatal error, but error emission cannot happen through the function. The stack looks something like this: Two potential fixes here: adjust so that it does not abort on panics or make anything running within the incapable of panicking. The latter is way harder and more prone to eventually break again. I think this is probably P-medium or thereabouts.
It seems like the implementation of is copied from [][1]'s : [1]:
Would this be safe? My understanding is if the callback panics then the pointer will potentially be in an inconsistent state and continuing execution will not be safe.
Well, not in the exact form it is now, but there are a couple avenues that could be explored to make it more resilient to closure panics – e.g. one could replace the old value with some sort of placeholder default while the original value is being processed.
Another test-case. Hope it can help. .
Assigning as discussed as part of the and removing .
No longer crashes due to


<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --The code is based on this example and the following : (commit ) <!-- 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. --It fails on stable and nightly: : $ rustc --version --verbose rustc 1.49.0 ( 2020-12-29) binary: rustc commit-hash: commit-date: 2020-12-29 host: x8664-unknown-linux-gnu release: 1.49.0 and rustc 1.51.0-nightly ( 2021-01-30) binary: rustc commit-hash: commit-date: 2021-01-30 host: x8664-unknown-linux-gnu release: 1.51.0-nightly LLVM version: 11.0.1 From stable, non verbose: <!-- 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 --
This looks like an incremental compilation ICE. Does it disappear after running ?
I can't reproduce the ICE, so it does look like an incremental bug
It does. I have cloned that repo, modified the file as in the git diff above and run fresh too.
<details<p</p</details
Sorry I had misread. No, it does not. Sorry for the confusion
Thanks for the report! I can reproduce with:
This is caused by: There is no guarantee that either or is actually local.
I've never committed to this repository; if you want to guide me to fix this issue, I'm happy to do it. If it's better if you do it, no worries
Assigning as discussed as part of the and removing .
claim


We should suggest the use of when writing :
Is there any precedent for the compiler suggesting an external crate?
Yes, for async traits the compiler suggests to use :
As pointed out, we do for . We normally wouldn't recommend one crate over another ("don't play favorites"), but for small, single use, specialized crates that fill a common language "hole" that we might be working towards "plugging", I think it is a much better experience to immediately unblock newcomers than send them to a user forum to ask how to get around the limitation. The current error gives some idea of how to fix this, but not nearly enough for an even moderately knowledgeable Rust user to fix the problem without some searching. That being said, thanks for double checking and mildly pushing back on a potentially controversial and "uncommon" request. That is important for the health of the project.


Gives:
cc ICE-ing instead of user error on misuse seems somewhat okay given that it's an internal attribute, IMO.
agreed. We don't protect against mis-use of rustc internal attributes beyond making sure that you can't trivially create buggy code. I don't think we should put any effort into making this nicer to use and instead create the const-generic based replacement.


Here is called for potential side effects until , ignoring however that it could have already been called in with those indexes. that demonstrates how this can be exploited to get two mutable references to the same data and cause an use-after-free bug.
Assigning as part of the .
The gift that keeps on giving Maybe it is time to get rid of as it exists today and replace it with a ? One that imposes the additional requirement on the caller that it must bring the iterator back into a safe state after it is done iterating. The upside would be eliminating a lot of code in and enabling the same optimization for and similar sources. While the downside would be that external iteration (i.e. loops and manual calls to ) would cease to benefit from optimizations and only internal iteration methods (including ) would continue to do so.
I don't know, I feel like that would just make more complex to upheld the invariants. IMO a good improvement over the current would be separating forward and backward iteration, this way it becomes easier to keep track of the state and I think would also make it possible to implement them for
I don't see how separating the forward and backward state would help with a drop implementation. The issue is that the source () currently does not have access to that state, instead the consumer drives the iteration by direct access through and never informs the source about it.
It would help because it allows the source iterator to keep track of its state by updating it when the method is called. Anyway, looks like someone already and it resulted in worse optimizations, but maybe LLVM got better in the meantime, or maybe that implementation could have been better. Anyway I don't think this is the right place to discuss this, a topic on zulip would probably be better.
https://rust-


<!-- 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: I expected that the help text would give syntactically correct code, or that there would be no help text. Instead, this happened: The provided code snippet is not valid - it tries to deference the else-block, which is impossible. Better would be to put the inside the else-block. <!-- 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. --: Also occurs on stable, 1.50.0. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I have a fix for this bug + an improvement. Gotta got for now but will submit the PR later today.


When running on Linux and a failure happens, a really nice diff of the output vs rustdoc-nightly is produced which very clearly shows the issue. This does not work on Windows for multiple reasons. One the call to fails: Second, the output from rustdoc-nightly seems to exactly match that from the local compiler making it not possible to do manual diffs.
How do you diff directories recursively on Windows? On Linux I would be very surprised for not to be installed. Oh I just thought of something - do you have a rustup overide that defaults to your local toolchain? Right now compiletest assumes the default is nightly, I've been meaning to change it.
No, I only set overrides on specific projects (and rust-lang/rust is not one of them). My default is the stable compiler.
Git for Windows provides : Are you building Rust using Git Bash prompt?
I don't think it'd be a good idea to require testing rustdoc in the Git for Windows bash shell. I'd like for this to work in and PowerShell if possible.


<!-- 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 regressed in 1.51 according to the playground
searched nightlies: from nightly-2020-12-15 to nightly-2021-02-01 regressed nightly: nightly-2021-01-30 searched commits: from to regressed commit: Regressed in
Most likely due to , cc
Assigning and removing as in the prioritization working group.


Hello, While trying to figure out how to keep a JoinHandle in a thread-local variable, I tried compiling this incorrect code, and rust crashed. It will not panic if I use a regular static var instead of in a block. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The ICE happens since 1.44 label: +regression-from-stable-to-stable
ping icebreakers-cleanup-crew can we add a bit more detail and trace where this starts?
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Regression between ... If I had to guess, I would say
Reduced testcase:
Not sure if of any help, but the thread_local macro is not needed:
const : Option<= map(value); ;)


The documentation for  reads: However, it does not mention that they must also have the same alignment. You would only learn about this if you try to dig into the code examples further down the page: Must the types and have the same alignment, or is that a particular quirk of the example? In any case, I think the documentation should explicitly mention alignment, because the compiler succeeds to compile the following with no warnings (), and I believe this is undefined behaviour: modify labels: +T-doc +C-enhancement
That looks like well-defined behavior to me. The alignment of is a relevant property if a transmute produces a reference to but for values it is the compiler's job to make them addressable at a properly aligned stack location (it doesn't strictly have to if no one takes a pointer to it). Regarding the quote paragraph, this references a conversion of to . The presented method does in fact cast pointers, but pointers to the value types inside the vector: to . It is the Vec which requires the pointee types to have the exact same size and alignment as a precondition for —and not transmutation.
Thanks for the clarification! So the documentation could still be updated to clarify when alignment matters, right?
I do not see a feasible way for the documentation to explain for all possible types which guarantees matter. Alignment is just one of many examples. Whether you can transmute to depends on the details of (and, less so, ), and I don't think can cover this for all possible . You example (the text you quoted) is specific to , and here it is alignment that matters. Another time, you might to ; this is also UB but this time alignment has nothing to do with it. And the list goes on forever.
However, maybe the comment in the example could be worded a bit more carefully to explain that alignment matters in this specific case because we are transmuting a pointer (implicitly as part of the ). Do you have any suggestions for how that could be worded? Honestly, that entire example is a bit weird. It says "still using transmute" but the code this comments doesn't even use .
If alignment is not a concern when transmuting values (because the compiler will move the memory to a stack location which is properly aligned), I think it would be worth explicitly saying this. Unless I was explicitly told (like Heroic explained), it would not have occured to me that it's moving into a proper aligned location. With regards to "explain all possible types", I don't think this is necessary. Saying "The resulting type must be a valid value" might be enough. Or maybe the: …should be changed to encourage reading that page more strongly ("Make sure you understand all the dangers of using before using it"), because that page does mention the invalid values thing (but it doesn't mention alignment at all, which is what raised this issue). It's not even use directly, it's casting pointers (which, sure, can be seen as a different way of transmuting values), where different rules apply. Maybe the example could be completely removed or moved elsewhere. Or framed differently, something like:
I'm not a fan of listing all the things that are not a concern. That's a long list. However, you are not the first person to suggest this, so I concede. I guess I will never understand why people expect alignment to be an issue here, but it seems they do, and I don't have to understand everything. ;) It already says that (in double-negated form): "Neither the original, nor the result, may be an invalid value." There are people (myself included) that use the term "to transmute" for any kind of "type-changing reinterpretation of raw bytes", whether it is via , via a pointer cast, or via union field accesses. The rules are the same in each case. However, since this is the docs of the function specifically, I think we should be more precise here, and I like your new framing.
In my case, it's because I'm not sure if it was undefined behaviour to read a type from memory with the wrong alignment. IIRC, there are some CPU architectures that fault when a misaligned memory access occurs? Or maybe I'm misremembering. Basically, I wasn't sure if "interpret this bunch of bytes as this other type" is something that is okay to do when "the bunch of bytes" is misaligned. My bad, somehow missed it.
It is UB to perform an unaligned read or write. But is a by-value operation, so you anyway have no control over the location at which or end up. Anyway, you made some good suggestions -- do you plan to turn these into a PR, or should we mark this as an E-easy issue for someone else to write the PR?


() Errors: Applying the suggestion leads to yet more errors. The new errors do suggest using , but they still suggest invalid code: After applying the new suggestions, I get: This seems likely to send new users in circles. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Assigning and removing as in the prioritization working group.
I've bisected to this nightly range: +nightly-2020-07-12-x8664-unknown-linux-gnu =old error msg +nightly-2020-07-26-x8664-unknown-linux-gnu =new error message (I cannot bisect further because in between of that range I cannot install nightlies :man_shrugging: )
Funny enough, when using as variable name, the suggestion will get displayed correctly:
This seems to be fixed on nighlty, but not on beta... somewhere between ... Fixed in Fixed by So this can be closed
But, as a sidenote: How could this ever be commited to master? I mean, it's obviosly wrong so say :/ I hope, that in the future the review process can be improved to detect such errors early on. The error was introduced in , where the test has been adapted to match the wrong syntax, but nobody has seen this :( Let's hope in the future it will get noticed right away
It looks like that PR caused a bunch of small diagnostics changes, so the reviewers probably just missed that bug.
Assigning myself for adding a test. claim


: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can't reproduce, can you provide the full code that's needed to reproduce this?
Sure
MCVE:
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
bisection: searched nightlies: from nightly-2020-06-01 to nightly-2021-03-17 regressed nightly: nightly-2020-10-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details


<!-- 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: Program does not panic. Instead, this happened: Program panics with the error . <!-- 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</detailsTo clarify: This problem occurs with all trait implementations that don't override the default implementation, e.g. with this simple DelegatingWrite:
I see two distinct possibilites to resolve this: 1) Treat incomplete s not ending on a codepoint boundary as a bug and fix that in the stdlib. Also clarify in the docs that indivual calls must be passed complete UTF-8 sequences if a Windows terminal is attached. 2) In the vain of "Be liberal in what you accept" handle incomplete UTF-8 passed in via calls appropriately, as long as the sequence is completed properly in the next call(s).
Hm, so this is ultimately a bug in the buffer uses? It attempts to write 1024 bytes but only 1023 bytes can written in the first OS call. It then has a leftover byte, which I guess it tries to write by itself thus causing this error?
The logic which errors if incomplete UTF-8 is passed in at index 0 is in the std lib at . That is where the error message comes from. As far as I can see the stdio buffer implementation (in stable, it is in , apparently currently being revamped) can not know of the requirement that only complete UTF-8 may be written to the underlying Windows terminal so I think that it should be encapsulated in by just accepting and buffering incomplete UTF-8 when necessary.
I mean, a generic buffer can attempt to avoid small writes (say, less than 16 bytes) by copying those left over bytes to the front of the buffer and waiting for either another to refill the buffer or a to empty it. But I see what you mean. Introducing a small buffer to windows/stdio would fix the problem.


<!-- 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 glob reexport reexports module and there is already module , the documentation duplicates. Current behaviour: ! ( module is duplicated, though both module links point to as expected) The expected behaviour: module is only shown once. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim


From a recent Reddit discussion ( ): Gives (rustc 1.53.0-nightly 2021-03-26): That Reddit discussion shows other cases.
See also:
I am quite surprised but fix of doesn't fix this issue. <details<summaryASM </summary</details
With the last nightly I'm seeing a probable improvement in foo1b (the second):
It looks like that one of SROA passes transforms getting of tuple fields into nearly this: Edit: Removing SROA doesn't prevent this transformation, it just happens in other steps.
This leads to big overhead of tuples and structs (because tuples is structs). Benchmark Results: So, PartialEq slower from 4 to 40 times.
Hack We could change std using this weird trick but possibly shouldn't. <details<summaryHacky code</summary</detailsThe problem is that we still: 't fix situation for structs (actually, problem affects every struct which size less or equal to 8 bytes) 't fix situation with tuples like or (newtypeoveru8, u8, ...) With the last nightly I'm seeing a probable improvement in foo1b (the second): Unfortunately, and inlining would convert this function to case. I suggest you to rename the issue to something like "Small POD struct equality ineffective".
It looks like Clang incapable for making such optimizations as well.
On the LLVM side, we're basically missing this fold:
Upstream review:
Upstream fix:
I ran into an issue where using a struct of two arrays was significant slower than passing those arrays directly. My arrays were larger, but the struct also came with a large overhead. Could those issues be related?
Unfortunately this has not been fixed by the LLVM 13 upgrade. Might be an unfortunate interaction with the migration from bitwise to logical and.
Upstream fix for the logical and/or issue: , Might make sense to cherry-pick this to our fork to avoid waiting another release cycle.
For the case foo1b the MergeICmps pass would usually handle this in the backend, but it's getting blocked by additional calls.
We're now generating good code for everything but foo1b: foo1b still unnecessarily splits out one comparison. Either or should address that.
Remaining case is fixed by the LLVM upgrade in Adding a codegen test for this may be worthwhile.
Thats true for , for it's still the same.


I tried this code: I expected to see this happen: successful test suite run Instead, this happened: debuginfo test failure for pretty-std-, saying that an expecting output from the debugger was not found. The specific line it seemed be this one: <details<summaryClick to see transcript that includes the full stdout/stderr output as reported by + </summary</details
Incidentally, when I tried to run the test by hand (which admittedly I might have messed up in some way), I saw this: <details<summaryClick to see some details about my attempt to run on a binary.</summary</summary</detailsIt seems pretty suspicious that lldb was reporting for the hashset and hashmap in these cases, when the unit 8test expects both their sizes to be 4. (But that also doesn't actually seem to be the behavior that x.py is observing, so that might be user error, or a separate bug entirely.)
I'm not sure if you've seen , but the lldb tests only run on macOS on CI. It looks like you are maybe using linux, so this is exercising untested code. In particular, pretty-std-collections is disabled on macOS, so it is not tested anywhere. It's not too surprising that it may have bitrotted. I'm also curious, are you using lldb installed on your system? Is it the same version of LLVM that rustc was built with?
Yeah I knew the debugger test suite i only enabled in certain contexts, but I couldn't remember the details. My runs of are using the wrapper from 1.50 stable. Of course that's just a wrapper over what's in my PATH ( in this case), right? lldb version 11.0.0 in this case. I should probably see if things change if I set in my . (In any case, I'd say it remains a suboptimal developer experience to have x.py test fail in this manner.)
was removed from rustbuild a long while back, so this shouldn't have any impact. Agreed, I ran into a similar problem (). As long as the test is disabled in CI, it'll probably keep breaking unfortunately. I'm pretty certain I tested locally, and it worked, so somehow it broke again. Maybe has some insight?
I can bisect, thanks for the link !
I checked the latest changes briefly and it looks like broke LLDB pretty-printing on Rust 1.51. Note that should be used only on the newest versions of . I'll open a PR to fix this soon.
Thanks that was quick! And please don't feel obligated to investigate when I ping. It was just a wild guess if you might know what was up.
No problem, please feel free to mention me in case of any debugger pretty-printers problems! I'm working on the debugging support in IntelliJ Rust and I'm interested in fixing issues like this ASAP.
I investigated the problem with a clear mind and found out that LLDB pretty-printer was updated improperly in (although GDB pretty-printer is OK). Please check the new PR. It would be so great to have LLDB pretty-printers tests on CI. In IntelliJ Rust, we on Linux. We Python package from CLion distribution but I suppose the system package can be linked and used instead (see ).


The states: Here, "its buffer may simply be reused" is simply meant to refer to the behavior of the underlying allocator. But I have seen people with low-level experience be misled by this into thinking that the implementation of itself has its own global allocation cache. They then thought this cache was responsible for excess memory usage in their programs. I'm not sure what the best way to clarify this would be. Part of the reason the current wording can be misleading is that "reused by another " suggests a mechanism specific to . On the other hand, it would also help to just explicitly mention the allocator. Here is a possible version that addresses both points, but it's more wordy than the current version: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I guess this also includes in-place iteration?
In-place iteration is a fancy case of type-conversion. Simpler examples are conversions to , and which also keep the allocation.
Maybe it would be more clear to say "may be reused by another allocation"? That doesn't imply it has to be a Vec that reuses the memory.
label +A-collections +C-enhancement +T-libs
claim


fails this test on native : (This is not a new failure, but I am cleaning up issues from downstream Red Hat bugzilla.)
We started discussing this in , and looking at the clang implementation here: I tried that minimal step with , but it still gives the same "Cannot select" error. I don't see any lowering of in like other targets, only stuff implementing the calling convention. So I guess we do need custom support, or perhaps the clang bits could be moved down into the LLVM lowering?
Hi , I ran into the same problem and noticed you had already opened an issue. I've now submitted a PR to implement valist and vaarg for s390x to fix this.


EDIT(camelid): This issue is now being used to track a different, but related, bug. The discussion starting is current. <!-- 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. --- Clone . <!-- 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 is probably related to somehow. I don't plan to investigate any of the proximate issues until the underlying problem is fixed. Feel free to take a look yourself if this is blocking your work, but it won't be easy.
Oh, I guess this could also be a missed case from That should be easier to fix.
If you can come up with an MCVE it would be easier to tell which of the two issues it is.
Not exactly an MCVE, but I think I'm able to reproduce this with only a handful of files The line does change slightly though: (Same rustc version output as above). Hope this helps :). Best, Mautamu
I think the issue is that the crate is first used in a dependency, so it isn't loaded in Maybe a fix is to recursively traverse the docs of re-exports? That sounds kind of expensive, but the only other option (besides fixing ) is to revert and re-open
An easy workaround is to link to somewhere in the crate re-exporting the docs, even something like this would work:
Hmm, this setup didn't reproduce the issue, not sure why:
Maybe the proc macro is related somehow?
Regression in searched nightlies: from nightly-2021-01-01 to nightly-2021-04-24 regressed nightly: nightly-2021-04-04 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsThat's , good guess,
This regression now slipped into beta 1.53.0.
came up with a slightly smaller reproduction, the proc macro wasn't related:
We've also run into this recently with a rather trivial crate
This is likely to hit stable, as no beta-accepted patch appears available at this time.
Is there an easy way to help bisect to figure out which PR to revert, or otherwise help along this issue? It’d be somewhat sad for our five-method create to not have docs even on stable.
you can use the workaround I mentioned at the top: is the PR to revert; I'm not wholly opposed to doing so but it means reintroducing other regressions. See .
This now occurs on stable and should likely be tagged , I assume.
A note to others who stumble upon this, the workaround in works great; to figure out which crate(s) you need to list, run: Look for the last log message before the panic — in my case, that was: Adding fixed the problem.
should give you a lot less logging and still show the right crate.
Further minimized from and turned into a rustdoc test form:
thanks for the reduction, that helped a lot. The problem is that rustdoc is considering each line on its own, when it should be considering the whole documentation for the item at once: When there's a reference link, rustdoc will see the link text instead of the link target: The fix is to use in instead of visiting each attribute one by one.
I experienced this same issue today on 1.56 stable despite the fix. The log followed the same pattern as above when run with . Removing this dependency fixed the problem:
can you post a link to the code that caused the ICE?
cc
reports the same issue in an open source codebase:
Also seeing this in another project in 1.56 stable. Would put together a reproducer but there already is one.
If you could minimize the crash that would be helpful, the one at the top was already fixed by
I've reduced it to Still seems a bit large but having trouble getting it any smaller. This reproducer involves I suspect that is the root cause in this case, not sure if that tracks with the other reports.
how can I build that package? running gives me even though I have gcc installed.
The dependency is macOS only. GitHub runners can do it. There is probably a way to shrink the dependency enough to build on some other platform, can look into it a bit more
Updated to ICE on windows, which I suspect is enough for linux as well. May require or
Hmm, so something strange is going on here - I example a little more, down to four local crates: If has the contents of , then the issue reproduces correctly, but if it's anything smaller, then documents fine. At first I suspected the crate hash was different or something, but cargo is passing different hashes even when and are identical, so that's not it.
FWIW you can work around the ICE with this diff:
Really interesting workaround! Those ought to be the same due to , maybe there’s some interaction there?
see
MCVE:


<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: a case-sensitive list of environment variables and values, matching the output of from C# and .NET and the output of from PowerShell. It seems we should align the output to match the modern APIs for Windows that Microsoft provides. Instead, this happened: returns all environment variable names in all uppercase. Rust via : C# via : <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: </p</details
I don't think this is related to reading environment variables, but is related to process spawning. If you are spawning a process from a Rust program, then they will be uppercased. But if the Rust program is spawned from something else (like PowerShell), then the env keys should be case-preserved. The issue is . This was originally in to I personally don't think that issue is all that important that all environment keys should be forced to be uppercase. However, if there is a desire to fix both issues, then there would need to be a case-insensitive map (maybe just keep a separate set of uppercased keys?).
thanks for the pointer. For our case, Nushell should be able to spawn processes and keep the environment as expected rather than uppercasing. This allows Nushell to work just as PowerShell spawning a program. As best as I can tell, it's the lookup of a single variable that should be case-insensitive and that listing of variables should maintain the case they had, though I'm far from an expert here.
Hm, the current code does look wrong. Windows environment variables are compared case-insensitive but when set they keep the same case. The simplest improvement here would be remove the and instead implement , and in a way that ignores case differences. However, note that Windows uses Unicode casing, not just ASCII. There is for comparing but using it for would mean lots of conversions from OsString to the Windows string type (and back again). Calling Rust's Unicode functions with a WTF-8 OsString looks tricky too (though maybe there's something I'm missing). I'm uncertain how to approach a proper fix.


Hello, Linking crate on fails when using . The link succeeds when using I expected to see this happen: linking successful. Instead, this happened: :
I'm adding a note here because my brain gets confused by github's bold-text "mentioned this issue" notes. I see the "No counters provided the source-hash" and jump to the wrong conclusion that this is related. (I think I've done this more than once.) So, NOTE TO SELF, this issue is NOT related to the "No counters provided the source hash" bug... Thanks and sorry for the churn...
Even worth, I suspect you deleted your previous comment :yum:. In my mail box I got from github on your behalf, I have the message "This should be fixed. There was a brief window in the nightly builds (less than a week I think) where this was a known bug. It was resolved."), but I have no trace of it in the conversation, so I am even more lost with just above message. If you wish you can edit messages instead of deleting. Users can see that your message was edited and they can access edition history to see what changed. But considering all the effort you are giving with instrument coverage, and how important this is to Rust (in my humble opinion), you are fully forgiven :smile:
I see is about to be stabilized: Will this issue be solved before stabilization?
I rarely have a useable windows configuration for debugging coverage. Any chance you can look into this? Also note the theory and workaround suggested in I think stabilizing the flag does not imply every edge case is understood and resolved so it may not block stabilization, but I haven't had any time to look into this one since it was filed. I suspect it has to do with generating function symbols for unused functions in the covmap generation code but not sure if something else is involved (macros were mentioned in the linked comment). Since I'm out for 3 weeks I'm not going to have a chance to look at this for at least that long. Seems very rare too. Thanks! Cc:
Yep, I'll take a look this week!
I hit this with the crate today as well, so any project with in its tree ( for me) may hit it. That said, only three (known) cases isn't a lot of evidence towards rarity or against it...
- Did you have any opportunity to look into this?
I'm still looking into this but I have managed to construct a minimal (I believe) repro: Which, with the appropriate flags, will then trigger the link error: There's quite a lot of dead code in the "minimal" repro but removing any of it or even moving it around causes the error to go away. We need basically this exact structure to get the codegen units to be placed into the state which triggers this bug.
Thank you! Having a reproducible example like this is still very helpful. It's not a stretch to assume the trigger relates to the CGU-specific logic in My educated guess (still a guess though) is that we're trying to for the same unused from multiple CGUs. I will try your example on Linux as well, just to be certain this reproducible case really is Windows specific. If it is the CGU logic, and is Windows-specific, the question I have is, what's different between Windows and other platforms like Linux? Some half-baked theories: Codegen on Linux is not actually using multiple codegen units? (Or not as commonly/extensively as on Windows?) I assume this is not the case. Some subtle difference in the parallelism between Windows and Linux is making this situation more likely on Windows? I can't picture how it would be that deterministic on Windows. Differences between the linkers and/or linker parameters, and how they handle duplicate symbols. If so, is this a "bug" in that we can "fix" to make linking on Windows more like linking on the other platforms?
It might also be worth logging the s in that call on line 374, maybe along with identifying the CGU, to confirm that more than one CGU is trying to define the same (unless you already know this to be the case).
- What is the filename for the last chunk of rust code? It doesn't appear to be referenced from any of the other files, unless I'm missing something. I wonder why it gets pulled into the compilation?
Woops, sorry about that! I've updated the comment to include the file name. It's pulled in by the statement in . Codegen on Linux does use multiple cgus (especially when is passed). At least from my tests, is the minimum number of CGUs required to trigger this. I haven't had any issue reproducing with this source (ie, it's not intermittent when the source code is not changed). So it doesn't feel like a parallelism/determinism issue to me. This seems like the most likely issue to me. I'm digging into the symbol table and LLVM IR ...
FYI, I just compiled this on my Linux machine, using , and I a debug message. It does indeed appear to define the same from different CGUs, but it links successfully. This log is printed twice, with two different cgu names:
(In case you'd like to try the same, I this line right before the call to :
Here's another (surprising? to me anyway) clue: I a debug log here: And two CGU's ( shown below and a different CGU) printed identical results: Doesn't this mean that the two CGUs are redundantly generating code for the same 5 functions (6 including the undefined function coverage is adding)? Is there something about the symbols generated for the "used" functions shown here that makes them unique within their CGU, so Windows is not getting linker errors on the used functions as well? Wishful thinking, maybe this identifies an opportunity to improve compiler performance, but more likely I just misunderstood the relationship between the CGUs and the results from the call to .
Ok, that was super helpful and pointed me in the direction of the actual minimal repro. Thanks Since is marked , it's included in the CGU for and the CGU for . Therefore, both CGUs think they should be responsible for generating the unused function and there are two copies of it generated. While the functions are generated as weak symbols, the MSVC linker seems to treat weak symbols differently than unix-y linkers do. I'm a bit curious why we use instead of for these functions? Using seems to produce the correct results (at least in this simple test): Changing to use those attributes instead seems like a quick, easy fix to resolve this for now. A better solution might be to reserve one CGU and put all of the dead code in that CGU which would sidestep the entire issue by ensuring there is only one CGU with these functions in it.
Let's try it! Are you planning to submit the PR or do you want me to. I think this is harder than it might seem on the surface. If I recall correctly, this was something I looked into, but the information required was not where I needed it, after CGU partitioning. Someone may know a way to do it, but I just want to caution that it might not be that trivial.
Let's see if CI passes
Historical context: See ... My depth of understanding of all of the different linkage options is still more shallow than I'd like. I read the LLVM documentation descriptions several times, but the number of combinations, and their effects, are still hard for me to understand. Some choices I had to make were an "educated guess" on my part. As you can see, MOST of the time, the current linkage works, but if your suggested changes resolve these issues without breaking anything else, that's fantastic.
Ah, thanks! I won't claim my understanding of the linkage options is complete either, but I think will cause the dead code functions' symbols to be made private to the CGU they're declared in and prevent any name collisions by renaming if necessary.


I was experimenting with some code on godbolt, when encountering this: with produces the expected assembly: However, when adding (into the same file) this function: The previous function's codegen changes to The issue: it stores the result on the stack, and then immediately discards that. (which it didn't do previously) The second potential issue I'm unsure about is, that here a function's codegen changes by just adding removing seemingly unrelated functions. I was told on discord this is because the two functions use the same , and adding the second one forces to be generalized to and as opposed to just . But I by far don't know enough to judge whether this is a problem or not, or what it's caused by, but I wanted to mention it.
label +A-codegen +I-slow +T-compiler
What's really weird is that on , it looks like this: But for , we get this:
The reason why the second call makes a difference is that IPSCCP is no longer able to propagate the slice length into various functions early.
I would probably blame this one a LoopDeletion/SROA interaction. LoopDeletion leaves behind this code: And SROA runs directly afterwards, before the phi has been folded, so we don't know that the GEPs actually access constant offsets. Possibly the backedge-breaking in LoopDeletion should also perform some folding, or we need a phase ordering change.
Or possibly IndVars should already be replacing the PHI. Just remembered that we have the replaceLoopPHINodesWithPreheaderValues() transform, which seems like it should be taking care of this.
and together should fix this.


<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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 --
must not be a power of two to work (e.g. 3, 5, 7, 9, 10, 11, ...). seems to be a lower bound, but I'm not entirely sure. Doesn't panic with anything below these values. Regression in cc
We need to report a proper ub error in for the unwrap on the alignment. Basically do the same thing as if the result of Align::from_bytes is Err. cc
agreed, that's the right fix.
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low


Go to: It was but the rustdoc generates like: ! The problem is that the previous variant's version is placed at the same height. I think it's ideal to place the version of the item itself at the same height, like functions.
I am new here but it looks like something I could do. Can you point me in the right direction?
Sorry but I'm not familiar with rustdoc, could you help them?
I don't have time, sorry. may have suggestions.
I can help if needed. But first: how would you want it to look like?
As mentioned first, the version at the same height should be the variant's IMO.
Ah ok sorry, so it's a layout bug. I thought you wanted to improve the display (which would be welcome too!). The problematic line is . It should be set before the docblock (in the variant header if possible).
I will gladly take a look at it, so I can familiarize with the codebase.
Sure, go ahead! Do test locally: Like that you can then go to the page and check if the bug is fixed. ;)


Yet another soundness bug in Zip's TRA specialization. Line 300 is not called when line 298 panics. This leaves outdated, which results in calling with an invalid index in line 242. Here is a that demonstrates creating two mutable references to the same memory location without unsafe code. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
How close is this to ?
The same functions are involved but the aspects that interact to cause unsafety are quite different. claim
I agree, this is much closer to .


Last line yields several occurrences of in the generated file. ## Expected behavior No occurrences of anywhere since it was label C-bug T-rustdoc cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I expect the fix is to check for just after
claim
cc I checked for doc(hidden) like this: But it doesn't seem to work, as my test would fail. I also tried using the same way to check for but it also failed. I noticed that the issue involves so I might need to iterate over generic parameters, I cannot find any function that does that in , so can someone point me in the right direction? Thanks :)
You can look at how the pass works:
am I right in understanding this only happens for cross-crate traits, and impls for hidden traits in the same crate are still hidden? In other words, just makes the cross-crate case consistent?
I believe so, yes: the pass was already taking care of such cases for local types. FWIW, the thing that motivated this discussion was noticing a leaking on the docs for , but not on the ones for


: <details<summaryerror output</summary</details
Rust playground:
Have you been able to reproduce this ICE with the latest nightly?
Playground link is not failing, I guess it's a good sign.
No longer ICEs since


Given the following code: The current output is: Ideally the output should look like: Right now, cargo and rustc operate basically independently of each other. The summary ("aborting ..." and "could not compile ...") is repeated twice, and both have different, incompatible ways to get more info about what went wrong. There's no reason to repeat these twice; we could include all the same information in half the space if we can get cargo and rustc to cooperate. I suggest the way this be implemented is by keeping rustc's output the same when run standalone, but omitting "aborting due to ..." and "for more information ..." when run with . Then cargo can aggregate the info it used to print into its own errors by using the JSON output. cc (meta note: I thought of this while working on , which has fully 12 lines of "metadata" after the 5 line error. Most builds are not that bad in comparison, but I do think it shows that it needs support from all the tools in the stack to keep the verbosity down.)
I'm not sure whether making the decision on the error format scheme is the right way to go. I can't think of any reason not to do it, unless the implementation is messy, so


Compare to This is almost certainly caused by <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Ayu-only. The summary in the search results is now blue, when it used to be white. ! ! Ayu-only. The color of impls in Ayu has changed from white to yellow. This may be intentional, but it looked off when I saw it. Note that this happens for all impls, not just foreign impls. ! ! All themes. Certain auto-trait, foreign, unconditional impls have underlines. ! ! All themes. The phrase next to in the search results is now red in addition to itself being red, whereas used to be gray. ! ! All of the regressions seem to have occurred in beta (1.54.0).
Regression 3 is fixed in
Sending a fix for the three others.
Regressions 1 and 4 are fixed in .


This was reported by on Zulip: https://rust- Demo:
I think the fix should be as simple as using instead of as the type of - that will work regardless of whether or not the memory is initialized.
The other option is just removing the case entirely. Llvm is smart enough to turn that loop in the branch into a memset.
It does help the gcc codgen backend at least as it can't manage to produce a memset for u64 so I assume it would fail to do the same for u8 if it weren't for that specialization.
It also fails for the case:
It does call memset if you don't pass an array.
I'd think the intrinsic could easily have its type changed to take a , which would let one solve this problem. The stable function of course cannot be changed, though...
Reopening to track adding a test. (That's the standard procedure for this, isn't it?)
I would like to try working on adding the test, though this will be my first contribution so I'd need some guidance. I'm assuming this would be a miri test as it's related to correctness--may I DM you on Zulip? (or would someone else be more suitable?)
great. :) Miri runs the libcore test suite via So adding it as a test in libcore makes most sense, IMO.


I've been working on a branch where I've made some refactoring changes and I'm working through cargo check errors/warnings/etc. now. Unexpectedly, one of the errors was from rustc mentioning "overflowed the stack": To reproduce: out the branch the patch listed below (uncomment a single line) <!-- 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. . --Backtrace N/A.
Your compiler is "very" (3 versions behind) old. There should be no reason to pin to such an old compiler, unless you're using a very specific nightly version, which you aren't. This error however does also occur on latest stable (1.54.0) as well as nightly. So, ... modify labels: regression-from-stable-to-stable I-crash -I-ICE Stable and nightly outputs are different though: (See for explanation) <details<summarystable</summary</details<details<summarynightly</summary</details
This is causing the overflow: Trying to get rid of serde ~and bisecting~ right now. Bisecting shows that even a 2018-06-01 (1.28.0-nightly) will overflow. This is a edition2018 specific bug, because there's no need for anymore. If I add that to the outer scope, the overflow will go away. For reference, here's a code that a user would write, therefore I think this should be P-High The workaround is to move the to the outer scope.
Please don't respond to issues in this way. There are plenty of reasons to pin compiler versions like that, it's not a good idea to presume that someone has no reason to do a thing, and in the case of this issue it seems extraneous. The reduced testcase is appreciated, however!
note that adding the use declaration is not the source of the bug; the use declaration uncovers the bug because without the the compiler fails earlier in the pipeline. reduced testcase also runs on the if needed, btw!
cc
For reference: The small error went away with , which seems fine and dandy because that's whats the PR is supposed to do. So there's nothing wrong with the different outputs of stable and nightly :)
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I believe I managed to hit this specific crash while working on ( is the WIP commit where I first encountered that crash), however, this project does not depend on Serde. I investigated further, and managed to make a complete , here's the gist of it (in ) : This cannot be reproduced solely in the playground without Serde, as it requires a multiple-crate setup. This project has a main crate and a single dependency. The points for reproducing the issue in a project are the following: As pointed out by the title of this issue, there needs to be an declaration inside of a trait implementation, which references the same crate the trait is coming from. There also needs an exposed function referencing a type from that same crate, i.e. either returning it, or receiving it as a parameter (either directly, or through a reference or pointer). The exposed function can be either a function, or a private function marked with the attribute (the attribute is how I encountered the crash at first). The common denominator with Serde here is the in "hack" to make proc macros as hygienic as possible, first suggested in , which I discovered through the explanation in . I had just tried to use this same trick, as we've had , and that's when the compiler crashed with the stack overflow: And here's my : I know nothing about 's internals, but here are a few additional observations I made while making this test case: Unlike what's described in the first message, both Rust-LV2 and my test project only reproduce the crash by actually building the project using (in either debug or release mode). Using on those projects did not crash. This is also corroborated by the fact that introducing a type error in the exposed function does not result in a crash either — the type error stops the rustc before it actually builds anything. The exposed function can be either in the same module as the trait implementations, or in a submodule, as long as it is either public or the function is (which, in a way, bypasses module visibility). If the function is either private, or marked but in a private module, the compiler does not crash. The "exposed function" part of the crash does not apply to all exposed items: replacing the function with e.g. does not trigger a crash. If a second declaration is in the implementation of another trait (here demonstrated with ) then the crash does not happen anymore. Having it only in the impl does not trigger the crash either. It behaves like there is a cache of some sort on these 'extern crate' declarations, and having a cache miss inside of the trait impl referenced by that crate causes the crash. Hope this helps! :slightlysmiling_face:
I remember this, it is an old issue -
If returns and finishes , then this issue should be fixed as well. Narrator: eddyb never returned.
Ah, right, that got lost in the chaos of Rust 2018 + all the changes. Fingers crossed that code hasn't gotten crazier since.
A different reproducer (one above will stop working soon; probably).
Finally found some time for this, some notes: had been superseded by work, seems to be correct, so there's not really anything to do by trying to rebase that PR is what never happened, and should be relatively simple by comparison right now we prioritize over "Rust 2018 paths to " (whether in or elsewhere), as the "source of ", but I'm not sure the latter ends up being used with -introduced names, so I'm hoping flipping that priority direction is enough to get better results
Also, I don't recall seeing - seems like that would be the correct fix for the stack overflow, whereas the priority thing is more of an "aesthetic" fix. EDIT: this turns out not to be that simple, see


More information on
To be clear, I'm not actually sure that's a private link, I didn't look at it in detail. It might just be doc(hidden) or something.
I didn't either. Just that most of weird things happening are in .


The following ICE was found migrating . cc which was very similar, but has been fixed. Also found in: - https://crater- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim


<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code from glacier/fixed/-1.rs <!-- 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 --
claim
This is caused by , when we try to resolve the instance for a trait fn we use receiver substs from the , which don't match with the generic params the associated fn expects. This happens when we change the of the callee. What was the intent of that change?
I didn't see the call to after that. I think I basically wanted to replicate the behavior of , when I didn't know that it is already being done. A trivial fix is to just leave that match arm empty.
I tried that, I also tried to just use the identity substs, in which case the resolution succeeds. But in both cases we get another ICE later during monorphization (which I'm not familiar with). This is the backtrace: What does correspond to? Where is the instance for that created and why isn't it local? Could this be related to the changes in your PR? cc
I have no idea what that ICE means. I haven't touched code in that backtrace.
That ICE resulted from some debugging code I had included, sorry for the confusion.


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


As far as I understand, the str types have a pretty strong assumption that they contain valid UTF-8. Any method/function that could break this (such as ) is marked as unsafe. However, it is possible to assign random bytes in the middle of a ~str, breaking the UTF-8 invariant: I think that such assignments should only be allowed in unsafe code. Update: should also be unsafe, IMO.
I had no idea str even allowed index-assign.
forbidding it entirely could also fix the issue, but might be overkill.
Hmm... This could be tricker than just forbidding assignment because this code compiles as well
I suppose we could also forbid (in safe code) to borrow mutable references to individual bytes in a string. Similarly, I believe that should be unsafe (but does not need to be.)
I think we should just forbid index-assign and borrowing mutable references. It can still be done through unsafe methods, but doesn't need to be in the language as a feature. The only language feature we have is raw pointer dereferencing so it's nice to keep it simple.
Nominating for the backwards compatible milestone.
doesn't need to be unsafe because it passes you a raw pointer, which is unusable without
Accepted for well-defined. (Also: document what "unsafe" means, which is a separate issue.)