(edit: much simpler reproducer at second post) (see edit history for the initial issue text) Potential duplicate of and cc
(edit: updated to nightly from 2018-08-14, as the error message changed) Another simpler reproducer: Backtrace: The backtrace looks quite different though, so I guess a fix for this one should also be checked to fix the first example.
Latest nightly appears to have fixed the ICE, however it's still making unbounded recursion :)
Async-await traige: Marking as blocking pending investigation to understand what is happening.
Alright, so here's what I've worked out so far: I was able to reproduce the ICE from the original code snippet using the compiler version and library versions from when the issue was reported ( was the closest version I could find and I had to use patch to make Cargo download versions of libraries that worked). I was then able to confirm that the reproduction supplied in the next comment also triggered the ICE. I was then able to get rid of the external dependencies (mostly by copying in parts of that version of futures) and still get the ICE - . After that, I upgraded to as mentioned in the next comment and confirmed that the ICE had been fixed and the unbounded recursion was happening with that same test case. Then, I took that test case that was confirmed to have the problem and tried to run it on the latest nightly - I had to make some minor adjustments as the pin module had changed since August, but I couldn't get the recursion error to happen. I'm inclined to say that this has been fixed at some point - .
I've submitted with a regression test for this issue. if you are able to reproduce this failure on a more recent nightly then feel free to re-open or file a new issue.
Sounds good to me, thanks!


The following code: Produces the following error message: This error message tells you that the types are mismatched, but doesn't fully explain why. To fix it, you need to use a floating point literal instead of an integer literal. This isn't clear from the error message. If you're new to programming or if you come from a language that doesn't draw the same distinction between integer and floating point literals, it may not be clear why the literal is not the same as . It would be great if we could add something in our error message that would suggest one or more of the valid ways to fix this: - - type could be in another context


We should only pass stage0 in general, should be sufficient for all use cases. cc for awareness and in case there's any concerns


Let's say you have the following (simplified) code: () This results in the following error: The suggested fix will work, but already copies the data so the extra is wasteful. The error message should instead suggest . This is an error you can run into if was previously of type and you changed it to a slice after writing the rest of the code.
Note: this kind of improvement applies to too: Err:


This example (reduced from ) either crashes LLVM or makes it emit an assertion: I suspect the loops aren't needed, but the control-flow there affects the bug in finicky ways. The name of the module appears to be important and tied to the fact that we end up emitting in a symbol name (because of the ), which gets mangled as (note the two dots). Among other things, changing the we use to mangle , to makes the bug go away. Assertion message (if LLVM assertions are enabled): Stack backtrace for SIGSEGV (if LLVM assertions are disabled): cc
Found the culprit in : LLVM implicitly assumes that cannot show up randomly in symbol names, and rustc breaks that assumption - but LLVM never checks it, so it shares part of the blame here, IMO. Probably the correct thing to do for LLVM is to split the string at the last , instead of the first.
Why are computers
The work around I introduced with the above commit is a proposition of and fixes this issue with the segfault.
Sanitizing to and adding a debug assertion would also be a good idea.


Take the following code: Attempting to compile this results in the following: I think the compiler should fail with something along the lines of "you attempted to use a complex type () where I expected an immediate".
edit: not sure if these symptoms are the same, but here's what I stumbled across. The following code generates a similar result for me: The and struct seem to be required, else the ICE is not triggered. Output
No longer reproduces:


This page: It's not obvious that reference equality is accomplished via implicit reference-pointer coercion plus . The docs mention this, but I would not look there to find reference equality. The reference primitive page is someplace I would look for info about reference equality. Update this page to discuss reference equality, and link to .
Can I help with this issue?
Still waiting for your reply
Sorry, it looks like got to this now, in


is an incorrect suggestion because has higher precedence than . It should suggest .
If someone wants to tackle this issue, it should be straightforward to fix. In: there should be another branch for , where the path of the call is . This code is a good reference: This issue affects the other range syntaxes too, so those should also be fixed (although these are not — look at for clues).
Hi I'd like to tackle this and take the plunge into the Rust compiler code :)
great! Let me know if you hit any snags or need any more tips. You'll want to add tests for these (in ). The is a good place for general information about the compiler. When you're done, include in the pull request and I'll review it!
you've anticipated most of my newbie questions already :) Thanks for that info, very useful! I'm now in the process of stressing my PC with lots of compiling to actually get started. Skimming the test code I'm really impressed by how easy it is to add "UI" tests for these sorts of things (compile this, expect this error on this line). Snazzy! That's all great, but do you anticipate I should also add "deeper" tests? I guess I'm trying to understand if the scope of this is just pure UI or do I need to touch some syntax parsing/immediate representations, since you mentioned code in . Because the compiler is emitting a syntax suggestion, we might want to assert that the suggestion is correct syntax in the first place. I don't know if that's how deep the rabbit hole goes and if there's a facility to help out, but my hunch is that since we have all of the compiler at hand, why not use it to validate the suggestion syntax? EDIT: OK, reading up on adding new tests to the compiler I encountered mention of , and it seems to be sort-of what I was after.
The issue here is just a diagnostic issue, so checking that we're getting the updated hint is enough. The code in is just helpful to see what ranges like and are desugared into, so you can catch them in — you shouldn't need to modify anything (apart from the test) outside of . It would technically be possible to do something like this, but it would probably be more trouble than it's worth. (I'm not aware of a facility to do this easily already.) I think manually going through the possible s and checking that the parenthesisation behaviour is correct in each case would be a lot simpler: if we handle the different s in an exhaustive now (it's likely that if the ranges were handled incorrectly, there could be some others that are also missed at the moment), then this should be a one-time fix and the tests should prevent it regressing. A simple UI test should be sufficient here: will generate the output files, which will include all the relevant notes.
There was a similar problem with the suggestions, and it was fixed in . Further use of the operator precedence list can be seen in (which introduced the error fixed in the other PR).
Thanks for your guidance and much appreciated. I have dug into HIR and built-in ranges a bit more. Decided to check all the built-in range types and concluded they are all indeed affected by this problem. The following test I came up with demonstrates my intended fix (fails with nightly as well as stage 1 compiled from master): None of the fix suggestions, when applied, constitute valid syntax. My test checks for syntax I believe should be suggested by the compiler. I'm keen to tackle all of the range types at once in the scope of this issue. The problem I see though is just how wildly different each of the range types is represented in HIR. Adding a call just above this line: Revealed the following: for isfor isfor isfor isfor isfor is I'm quite bewildered by this non-uniformity and I guess I need some help unifying all of these into a elegant condition to tell "is this a built-in range?". I could probably brute-force it in a with explicit checks for , but maybe we can do better. Thanks in advance! EDIT realized that this non-uniformity was actually mentioned in the second comment from , but my plea still stands. Thanks for your patience.
I think you can match on all of these with something along the lines of (pseudocode):
Right, that's what I had in mind, but was also wondering if something like a check for  trait would work better. I guess we want to match against built-in range literals though, and explicitly. Here's how I rationalize it: because they are parsed and desugared by the compiler, the check needs to be explicit and hardcode all paths to builtin ranges. Handle a special case with a special case.
Yes, this is where the lowering code comes in handy, because you can see exactly how the different syntax is desugared differently, to make sure you really are catching all the cases. Yes, I agree. It'd be nice if there was a more uniform way to handle them, but it's not convenient at the moment. You could include a reference back to in a comment to where the desugaring takes place, which will provide some motivation for matching in .
All clear now, thanks. I have succeeded in matching all range types and getting the test to pass. Needs some cleanups, but hopefully should be ready for PR soon. I have a few more questions before that though :smile: I have noticed that most of my code would actually be irrelevant if I re-used functions and constants defined in , e.g.: Can't deny that I have used these as inspiration / guideline (albeit I did not do a stupid copy-paste). What's the policy on using clippy code (clippy is a submodule of main repo)? This is purely in the interest of pursuing . The diff is not that big (52 new lines to , fairly specific to matching paths) -- but still, my clean code sense tingles because of possible DRY violation. Another conundrum I have is whether we should address and paths (and if so, how to work out we're not using at compile time)?
Unfortunately, there's not much sharing from clippy to rustc. I wouldn't worry about it. If you can encapsulate it easily, it's possible that clippy could make use of the code in rustc instead. The function in picks the correct path for / — you should be able to use that.
Thanks for the suggestion for , unfortunately I can't really make the association of and . It seems to me they are disjoint -- in : lowering happens in , whereas typechecking happens in . in takes : The it uses needs an awful lot of things to be instantiated. Not sure if I can get the hold of it all in . Another problem I encountered while writing tests is that the changes I have made will affect suggestions for code like this: With my changes, the suggestion would be . I believe the correct suggestion would not involve the needless parentheses. This is due to not differentiating between "de-sugared" form coming from and between these de-sugared forms being supplied explicitly as input source code. With this in mind, I think current code is not PR worthy just yet. If of interest, here's the branch:
Left a couple of comments on possible approaches on that commit. The code looks fine.


The following code emits an unsquelchable warning. This warning should be a part of .
empty trait list in should have a lint name ... and that name is .
Does not appear to squelch the warning for me...
It seems eminently reasonable to me to include in since it is an attribute applied with no effect; so let's kick off fcp for that. merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Implementing this as part of the existing would be complicated by , but it might also be possible to implement where the existing "empty trait list" warning is issued (possibly as a ).
I need to make a buffered early lint for the same thing with .
Seems reasonable. And a macro that might end up with an empty derive list should have no problem turning off locally.
reviewed I certainly agree with moving warnings to lints.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.


The documentation for with say "no re-ordering of reads and writes across this point is allowed". As I understand it, for a single thread doesn't give anything more than . E.g., a store before the fence could be moved past a load after then fence. Is that correct? cc
Hmm, that's a good point, though the details are a little subtle. From the : I think what this translates into is that guarantees that: no subsequent operations can be moved before this operation if it is a load, and no operations can be moved after this operation if it is a store. The italic parts there aren't present in the current documentation, so that should probably be rectified. I think some annotated source code would really help here!
It actually depends on the other operation, does it not? stores after the fence can be moved up, but stores cannot. TBH I have a hard time thinking in terms of reorderings; I usually think in terms of what actually happens in the underlying memory model. Some of these models can be fully characterized by the allowed reorderings, but not all of them can (as far as we know). And anyway, SC fences are broken in the C11 memory model and probably going to change in the next version, so...^^ On top of that, all are in a total order, and that is the entire point of . (The website says it but you left it away in your quote. Just making sure nobody thinks that a load is the same as an load. It is not.)
I'm actually not entirely sure about that. Another store to the same memory location shouldn't be ordered before, but I don't see from the reference text why an unrelated store with couldn't be. I'd be happy for this to be rephrased this in terms of the memory model, but I'm not entirely sure how we'd even do that. Proposals welcome. I think talking about what can and cannot happen, with examples, is probably the most understandable way to present what the different orderings do. I left off the total order part because it didn't seem directly related to the original question. But you're right that it's a vital part of that shouldn't get lost in the docs!
It says The sequentially-consistent ordering consists of all operation, across all locations, and the order in which they are observed must be consistent across all threads. In particular, if one thread performs two operations (i.e., they are ordered by program-order), then the order in which it does them must match the order in which every other thread observes them. That rules out reordering them. This is the sole justification for the existence of .
Yes, good point. So how about we move the bullet point to bottom and change it to say


Given: results in: Is this intentional due to some soundness issue with having it otherwise? (I cannot think of any...) We could fix this by attaching to manually. While having be structurally matchable is quite boring and useless on its lonesome it prevents other types that contain it from being structurally matchable. (not likely to occur very often, but when it occur it seems like it would be annoying...) r? cc


The output from , at the top of the page for a or a , etc., includes a line like, Clicking the on a browser w/ restrictive cookie settings (which typically includes ) results in an error similar to the following: Additionally, the section fails to expand or contract, as the exception isn't handled. is attempting to store the collapse/expand state, s.t. later visits to the page presumably maintain that state for the user's convenience. I browse the web with an admittedly somewhat atypical setup: I whitelist cookies. , in most browsers, counts, since it is a similar mechanism of persistence. I think Rust's use of here is fine, but I would request that, if is forbidden by the user agent, that the documentation gracefully "degrade" to just expanding or contracting the requested item, but not persist it. As it is, the JS crashes while storing the state, and appears to never make it to actually expanding/contracting the item.


Spawned off of 's on :
to be clear: we don't need to use to reproduce the problem, right? I.e. hypothetically examples exist that don't use that feature? In particular I know this problem is in some way related to , which is definitely a true regression of stable code.
Right, this here is not really a regression. It is just an ICE that should be an error and it is fixed by We can probably do this without const_let, but I couldn't come up with an example.
A user is the
I have tried to reduce the problem. This repository is smaller, but still fails on : . The same crate builds on stable.
I think you are encountering which has a fix in (making everything work again) This issue is different, even though the symptom is the same right now. When this issue is fixed (via ), the ICE will become a hard error.


On the surface, these functions seem very similar. When is it appropriate to use one vs. the other?
Anyone able to describe the differences and use-cases for these functions? I'd be willing to add docs for this, I just don't know when to use either
My understanding for these two functions is: Both are probably not needed in general. While can be a debugging utility in some situations they're largely only needed when writing some form of a spin loop. The function is for very tight spin loops. It is ideally used in situations where you know that a contended lock is held by another thread and you're sure the other thread is running on a different CPU. If the other thread holding a lock (or whatever condition is being waited on in a spin loop) isn't actually running then spinning with this function will eat the entire time slice allocated for the OS until that thread starts running again. This is a CPU instruction on some platforms, and a noop on other platforms. The function invokes the OS scheduler, asking the current thread to basically be put into the back of the run queue. This is best for spin loops where you're pretty certain the lock/condition will become available soon, but you're not sure if the thread holding the lock is running or not. I believe the general wisdom is that on lock contention you for a bit, then a little bit, and finally sleep for real. All of these are pretty advanced functions, though, and the documentation should be very clear that these are largely just current-practice-guidelines and benchmarking and further understanding is highly encouraged
One use case for is a bunch of threads blocked on . potentially needs a large number of cycles to execute but it is also executed in performance-sensitive code (graphics, crypto, etc.) where a full or would not be wanted.
Are you still interested in writing docs for this?
I still don't feel confident to write them given my current level of understanding with these APIs. But if you want to try, go for it!
I will give it a try! I am sure others will correct me if I write some things that are wrong :) I hope I'll be able to deliver a PR somewhere this week.
It seems like you always pop up on my screen when people are talking about technical details so I thought you might be the right man for this question :) When diving into the details of I found this: So basically does a call to which is defined like this: Question: What is the difference in semantics between and ? Or to ask it differently, why should we not deprecate and only use ? The documentation of both functions is exactly the same as well. (Aside being experimental). Or we could maybe re-export as in ?
I did an attempt! I hope it clarifies some things. I didn't edit the documentation to not bloat the documentation there too much. But if that is desired as well, please let me know. The pull is here:


With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:


This is intended to be a tracking issue to incorporate into the current beta branch for the Rust 2018 release, as we'll be relying on that in documentation that we're writing.
The Cargo backport is happening here - , and after that needs a PR to the beta branch in this repository
This is now submitted as
Done!


Given the following source: The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report: Strangely enough, putting either the leading or the closing on its own line will cause the report to change to something that looks correct, if a little too broad: I believe the code at fault is this section here: Because it assumes that every doc comment will have a padding of 3 characters (the or ), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.
I'm working on this.
You can also reproduce this with unsugared docs:


<details </summary<p</p is empty <details<summaryerror </summary<p<pre<font color="#AB4642"<b </b</font<font color="C1B9"<bice</b</font<font color="CAFC2"<bgit:(</b</font<font color="#AB4642"<bmaster</b</font<font color="CAFC2"<b) </b</font<font color="#F7CA88"<b</b</fontRUSTBACKTRACE=1 cargo +beta build <font color="#A1B56C"<bCompiling</b</fontice v0.1.0 (/home/shadlock0133/projects/rust/ice) thread 'main' panicked at 'byte index 45 is out of bounds of ', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at at 2: std::panicking::defaulthook::{{closure}} at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::continuepanicfmt at 7: rustbeginunwind at 8: core::panicking::panicfmt at 9: core::str::sliceerrorfail at 10: core::str::traits::<impl core::slice::SliceIndex<str> for core::ops::range::RangeTo<usize>>::index::{{closure}} 11: rustcresolve::Resolver::reportconflict 12: rustcresolve::resolveimports::ImportResolver::resolveimports 13: rustcresolve::macros::<impl syntax::ext::base::Resolver for rustcresolve::Resolver<'a, 'crateloader>>::resolveimports 14: syntax::ext::expand::MacroExpander::expandfragment 15: syntax::ext::expand::MacroExpander::expandcrate 16: rustcdriver::driver::phase2configureandexpandinner::{{closure}} 17: rustc::util::common::time 18: rustcdriver::driver::phase2configureandexpand 19: rustcdriver::driver::compileinput 20: rustcdriver::runcompilerwithpool 21: rustcdriver::driver::spawnthreadpool 22: rustcdriver::runcompiler 23: <scopedtls::ScopedKey<T>>::set 24: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::callonce 25: rustmaybecatchpanic at 26: rustcdriver::run 27: rustcdriver::main 28: std::rt::langstart::{{closure}} 29: std::panicking::try::docall at at 30: rustmaybecatchpanic at 31: std::rt::langstartinternal at at at 32: main 33: libcstartmain 34: <unknown> query stack during panic: end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.31.0-beta.19 ( 2018-11-26) running on x8664-unknown-linux-gnu note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib note: some of the compiler flags provided by cargo are hidden <font color="#AB4642"<berror:</b</fontCould not compile . To learn more, run the command again with --verbose. </pre</p</details
More or less same as should stop doing span arithmetics. cc
I don't see how not to do span arithmetics here ? In , the snippet is , source is and the binding is . By taking the snippet that starts at the beginning of the binding span and end at the end of source span, we have In this case, I think it would be better to remove the suggestion when the issue happens in a macro because the suggestion will be wrong anyway.
we could completely avoid span arithmetics by giving more useful spans, instead of having to come up with them on the spot. The counterarguments to that would be that it would increase memory usage in every import and that this suggestion is already useless in macro context (especially in this case).


Sorry for the cryptic title, didn't knew exactly what to put there. On musl targets (well and (hf)) for some reason pipe2 is not used (even on kernels that support it). Pipe2 is important to protect against race condition when multiple threads run external commands. The following is an example that due to this bug will deadlock on the musl targets listed above (and probably all linux musl ones). Running with strace proves that pipe2 is not used, and that instead the fallback is: vs the target: Versions affected: 1.30.1 1.31.0 - Current stable rustc 1.32.0-nightly ( 2018-12-07) Later Edit: Just to be clear, if I compile a C file with the same musl toolchain that rust uses pipe2 works, so it's not a bug in Musl (or doesn't look like one to me).
cc
Did some investigation regarding this bug: The culprit seems to be: More specifically the following comment: “It assumes that //! we've been dynamically linked to the library the symbol comes from, but that //! is currently always the case for things like libpthread/libc.” Well this is not the case for musl target binaries. pipe2 is one of the symbols rust uses this mechanism to check for existence.(for fair reasons, the symbol is not there on old kernels). But on any musl target this symbol does exist because musl is emulating it in it’s standard library in case the systemcall is missing. A solution would thus be to assume this symbol always exists on musl targets (and it’s probably the same for the other ones) and make the weak! macro return the symbol directly for such targets. I could do it myself if this sounds resonable.
Thanks for the report Your investigation sounds right to me and I agree that we can probably just assume these symbols always exist on the musl target (as we're mostly pulling in the libc anyway). Should be fine to update the standard library to assume so!
Is this kind of what you had in mind? I wanna know if I should go like this, or I understood you wrong.


https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.


This code demonstrates the problem (): With stable-1.32.0 it prints . With beta-1.33.0 it wrongly prints . Beta also produces these wrong warnings: It seems that Rustc decides, that the first arm covers the whole range of a and optimizes out the other arms before they even reach MIR. The code is very similar to this . But the testcase does not test that the other arms can be reached. I was able to bisect the regression to . (This issue seems similar to , but the reduced testcase there does not use any associated consts)
Not the same as
triage: P-high, A-NLL, NLL-complete, assigning to self.
cc
I have confirmed that the bug appears to be specifically injected by commit (I've skimmed over that commit several times and still can't see the problem, but I'm going to try again now. Maybe the actual issue is that we are miscompiling downstream, but that pattern is not sufficiently exercised elsewhere in the compiler today...)
Well this is making my spidey-sense tingle: but even when that returns false, it seems like that would only imply that we fall through to presumably more general purpose code here: (still looking. Going to add a bit of instrumentation to these parts of the compiler.)
I don't mean to step on any toes, but I looked into this a little as an earlier PR of mine introduced it. I've got a fix up at but if that's not the approach we want to take then I can leave this to you.


std::collections::BinaryHeap is a max-heap. A very common use case for users will be to make a min-heap. The basic example should include a min-heap.
Do you think you would be able to make a PR based on e.g. ?
Added an example in


The following code generates some really awful LLVM IR: The same happens with . Cc who made me write these tests, and
Feels like an LLVM limitation to me. It should be replacing the with a (or a of poison when that becomes available).
For reference: LLVM is capable of optimizing a memcpy of undef alloca away, this just runs into the usual limitation that all of memcpyopt doesn't work across BBs.
This is such a long-standing issue. Seems like it might be wise to have someone working on fixing this.
Someone has already worked on this, see It's a bit hard to track, but unfortunately this got reverted again (multiple times). I suspect that this is only going to get really resolved once memcpyopt moves to memssa -- which someone has also worked on in the past (), but which never really went anywhere.
The alloca and memcpy are no longer present on nightly, as a result of .
The FIXME in the test is still there, needs a test.


Compiler crash when using cfgif and defining a macro with macrorules twice. I tried this code: In a repo: I expected to see this happen: error: a macro named has already been exported Instead, this happened: error: internal compiler error: unexpected panic : Backtrace:
Regression from stable to stable (works in 1.30). Reduced test case:
mode is implemented on best effort basis, generally unsupported and will be removed in some time.
Ah, I see, the original issue doesn't have it. I'll investigate.
Reproducer in no longer ICEs.


For the following code: We get the following diagnostics: Notice that the String expression correctly suggests removing the borrow, but the expression incorrectly suggests adding , which does not fix the error.


ICEes when trying to compile the following code. As far as I can tell, the issue is due to the HRTB. All other issues I found mentioning where either using unstable features and/or related to which seems to be unrelated to this issue. On the playground, I am able to reproduce the ICE on stable (1.33), beta, and nightly. Locally I have the following setup: : Backtrace:
Triage: Reproduces as of 2020-03-10.
Triage: This ICE has been fixed in the latest nightly, I assume it's fixed by . Marking as .


The default edition is 2015, but the option to change this in the "extended" list, so it is only discoverable with , rather than just . Users should be encouraged to use 2018 where possible, but the omission of the edition from the default help list makes it less likely that it will be found for users not using Cargo.


charatreverse(s, i) returns the character at i - 1 instead of s.char_len() - 1 - i.
This is actually the "correct" behaviour (at least it is the behaviour listed in the documentation of ). Also, note that and actually deal with byte positions, not unicode char positions (this is not stated in the documentation for either of these :( ). Pull request hopefully corrects both of these issues.
Closing, has been clarified in a documentation update.


First of all, it now returns an Err with "not available on this platform currently". But I found that there is a system call  available in Linux kernel 4.11, which can get the birth time. As the , the function uses on Unix platforms. But the just never contains . Shouldn't it try when available?


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


While I was trying to make a general impl, I came across this ICE. Note that inlining makes this ICE go away.
thanks for putting the stack-trace, I forgot about that This also works
Small repro: I'll try to have a PR up for this next week.
Another repro from


Run tests for and you'll get the following diagnostic: But to be as helpful as possible the diagnostic should, if possible, point to the start of the invalid code block.
This error was removed in because I didn't think it could actually be produced. Looks like it was possible to trigger by writing an empty doc test. The error message is misleading, though. It's a valid code block, just empty. On master, this code produces a passing doc test now. IMO, that is the correct behavior. There should probably be a test for it.
I agree completely. Would this mean re-introducing this message but improving the message (replacing invalid with empty or something similar)? I believe that is the best course of action as warning on an empty code block is completely valid and desired IMO.
The original code only caught this incidentally. I think this check would make more sense as a rustdoc lint instead of a hard warning. Could be to or a new pass entirely.
could you edit this issue to reflect the current status? It should be something like "Empty doc tests should be linted".
I'd like to take this issue - should have a PR this week for review.


How to reproduce Actual Result Actual Result with full backtrace rustc --version --verbose Expected result Additional details Please note that the issue will go away once you succeed in building the project (probably thanks due to some compiler caching, sorry, not sure here). A is enough to get the error back :) Thank you.
triage: P-medium due to niche nature of bug. Leaving nominated to try to increase its visibility in short term in case T-compiler members want to attack it.
I'm not asking you to re-prio. I'd just like to say I don't think the issue is so niche, as seems to exhibit the very same behaviour, and I can easily see myself trying: Thank you and again for looking at the ticket :+1:
briefly at T-compiler meeting. un-nominating.
I inadvertently ran into this bug today when trying to do with my project with closed to see how my project would behave. I wasted quite a bit of time trying to find the ICE by reducing my program then I found this issue.
I am unable to reproduce this anymore and WSL:
The problem is still present for me on macOS even on nightly:
I wonder if this is related to ? By the way, for that reason, don't run Rust things with .


only checks that the link section contains no pointers, but there may be arbitrary bytes in the data, even undefined bytes (e.g. due to padding). cc is that ok? llvm may insert whereever there are undefined bytes. Or should we lint/error on such statics? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
that should be ok yeah, I think that's what happens on all other platforms and it's up to the consumer to ensure that all bytes they read have defined values if they want.
Ok, I guess we should probably just document that in the code segment that I linked above.
claim


The following code (which is awesome!), but the warning is not as clear as it could be: This results in: it should probably say "futures do nothing unless you await them" or something. Most people won't know what 'polled' is all about, I think.
The current note originates from: To change it, simply edit that.
What about ?
In any case, . Just a typo :wink: I would actually expect something in the line of: Btw, I'd love to work on this issue and provide a PR. I'm really looking forward to help Rust just as much as it has helped me thus far!
We may want to work in the fact that you can use somehow. Other than that, sounds pretty good.
what trait does provide ? :astonished:
is equivalent to and is likely to replace it eventually. See I think for now might be good enough and we could tweak later.
That makes sense to me! Am I ok to work on this?


Hello, I was working on my toy project here: The project was compiling and running fine at this commit: However, I decided I wanted to move functionality out of and into , so I moved all of it except the declarations, and then tried to compile. This led to the compiler panic. The repro commit for this: I am using CLion, and the command I run is simply . I am pretty new to Rust so it might just be me doing something really wrong, but it'd be great if someone could look into this and advise. Thank you! With : With : EDIT: Updated with last working commit. EDIT2: Posted crash message with --verbose flag and clarified IDE. EDIT3: Added MSVC toolchain error.
I have a PR that will fix the underlying problem, but we need to come up with a reproduction case to avoid regressions in the future.
Removing nomination since a fix is already approved
Thank you so much for the super-fast response! However, I am not at all familiar with rust's compiler code, so if you could tell which part of the code the compiler trips upon, I can try isolating that part of the code to make a smaller reproducible example.
Reduced it down to two files: (replace obvisouly ^^) can be any primtive type as , , , . Haven't managed to get it down to one file sadly :/
is there a problem of adding the test in two files (with )? if not, I could try to work on this as a first issue.
No, that's totally fine. Go for it!


gives a warning, but does not.
suggested that we test this out with crater to see if this would generate much substantial noise and how common it would be.
I'd expect it'd be a pretty substantial source of warnings, but that's exactly why I think we should introduce it. People compiling with are asking for these sorts of bugs to be caught, and we should serve them appropriately ;) In any case, running crater would require having an implementation to do a crater run on, so let's do it!
Let's do it. (I'd personally even like an attribute to allow people to opt-in to this for , for example, when T is itself . That way if I make a , I'll get a warning on that I normally wouldn't want but plausibly do now that I'm getting s in the s.)
I've opened a pull request to try this out:
We discussed this on the language team meeting; folks felt generally positive, but we'd like to do a crater run to see what the impact would be like and if there would be many false positives.
I tried this using but it does not seemed to complain when the part of is not used, is the the correct behavior? I hit this when doing where I didn't use part of the tuple which cause it to not work, which I did not know is required to be used.
putting it into a binding, even an unused one, is considered a use, like how doesn't lint. With just calling it lints:


A new project with the following code: Causes the following error:
Reduced: cc
Latest nightly shows a different compile error: error: internal compiler error: ty::TyKind::hashstable() - can't hash a TyVid _t.
Does not ICE anymore on playground - But does ICE in my local PC with latest nightly.
Can confirm it still ICE's with the latest nightly both in my little testing crate, and my larger project. The lack of ICE on the playground is very weird. Even copying my testing crate's code exactly doesn't make the ICE occur, even though both the playground and my computer run rustc .
Maybe a compiler flag? Not sure if playground uses . cc
The playground attempts to build each night, . You can always review exactly what version you are using in the channel dropdown: ! For what it’s worth, I don’t see the producing an error locally or in the playground.
Thank you very much, It is clear now that incremental compilation is the source of this behavior. To make a successful compilation with cargo, it is possible to use, for example, .


Unit tests should not be doing multi-second sleeps as this is bad for turnaround during development.
Fair enough, I will try to get around to looking at this.
Done.


Rust version affected Both stable and nightly: How to reproduce Run on this code: Stacktrace Potentially related issue: , although here it happens only with not
Can confirm on .
MCVE: Bisected to find regression is in nightly , from: to the above ICE. As far as I can tell only rustdoc triggers it, but I don't know enough to say that for certain.
Cannot reproduce the ICE with the above MCVE on latest nightly ()
After too much time bisecting, it has worked since , more specifically commit which is this rollup: . My guess is that this is another bug fixed by .
I can confirm that probably fixed this. I've submitted the MCVE as a regression test:


Was working on bug and tried to compile the program below. The inline assembly may be bogus: I make no guarantees of its correctness. crashed with this output: : (but also happened on a nightly from late May)
The inline assembly is in fact bogus. Here's a minimal example that crashes the compiler. The problem is likely using the string operand (by mistake, because I'm dumb).
<details<summarybacktrace</summary</details
modify labels: I-ICE T-compiler A-inline-assembly C-bug
Thank you!


Let's tying to compile this code.This code compiled ok on stable and on nightly-2019-06-17 (for example at rust play site) But in current rustc 1.37.0-nightly ( 2019-06-26) compilation fails with message:
Bisected to: Ok Fail ...
I bisected to , which is also part of the range identified. I get build failures when I try to bisect further into the commits of that PR. cc
Hmm curious, we do have tests for such situations. I'll investigate, but it'll drop into beta today. It's probably an easy fix
Today? Beta cutoff is on Tuesday.
Not this time I believe
Beta cutoff is 2019-06-29 https://rust-
triage: P-high, remove nomination, assign to
FYI, Oli is on vacation for 2 weeks.
Should this be marked regression-from-stable-to-beta now?


The following code causes an error () Errors:
Reduced:
seems like this bug dates at least to when was stabilized in 1.26.0
bug dates back to at least nightly-2017-10-15 and perhaps earlier. It seems reasonable right now to assume its been present ever since was introduced.
I'm going to have to do some background reading to remember what we are supposed to do in a case like this. If you remove the occurrences of you get the same ICE behavior, and that behavior dates all the way back to rust 1.10.0:
triage: P-medium. Removing nomination. Assigning to self.
I just ran into this on 1.41.1. Attempted to minimize what I was doing and ended up basically identical to Centril's above.
If it helps, this slightly modified snippet produces no ICE but a very odd error: In that code is , so it seems like something isn't being fully expanded somewhere?
Seems related to note that in needs to be generic to compile, but the output type can be changed to


I have the following code: Attempting to use this function, such as in the following manner: causes the compiler to crash with the following backtrace: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like this was fixed at some point. The following minimal example ICEs on nightly-2019-06-26, but doesn't on nightly-2020-03-11!
I'll look into adding a test for this tomorrow! :)
assign


Hello, I found a bug while developing a project who produce an internal error. I create this code to reproduce the error: I got this error: ! If you do the same using an Option, for example: But if you do this: You got another internal compiler error: ! And to know: There is a correct way to do this without a match? I try this, but it wasn't accepted: Thank you
Does not panic on nightly-2019-06-17 (playground nightly). Must have been fixed. E-needstest?
you should update your rust :)
Hello, Ok with an update it's fixed: ! Thank you :) But, there is a way to have auto updates on Linux? There is a way to check the enum value type without checking the content wrapped? (with a if, not a match)
You can use the like so: (Or you can say , which I think is better style, but there are scenarios where one must resort to the method.)
For the record: has been fixed in
Ok thank you ! I forgot the "let" before the Some(), I think it's the reason why it's doesn't works.


(and by extension ) have as the mask type, but the lists as the mask type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hey I (I think we all) very much appreciate the work you are doing by looking at the docs and finding unsound things. What about opening a PR and fixing them immediatly (some of them could be done by using the github editor)? It's a very great opportunity to make Rust a better programming langauge. If you feel like it, please open a PR and reference this issue with one of the github provides.
I am well aware of how GitHub works :D unfortunately for us all, I only have so much programming time. I've been busy at work safe wrapping all these intrinsics for my own lib, which is why I'm filing bugs on them as they come up. However, in my experience, filing even a single PR to this repo is rather involved and so I've mostly given up on doing it. As to this particular issue, it's a change to a stable API, so at minimum a full crater run would have to be performed of course. The input mask value has to be a const, so you get a lot of literals of course and those can usually infer to the new type fine, but you also get a lot of const declarations too, which would break. I suspect that at least some people will get their code broken. Given that the intrinsic only uses the 8 lowest bits, it would be entirely reasonable for T-libs to say they don't care about the i32/u32 difference compared to code breaks and just document the (very minor) difference. or they could go for absolute exactness and declare the breaks to be the fair product of a bug fix. up to them
I believe this was changed recently because Intel's definition is wrong/inconsistent. See
ah lovely. of course the guide is wrong :P well, then consider this a minor documentation issue. the function should simply explain that it doesn't match the spec and why and such.
I could take this! claim
Triage: I'm going to release assignment due to inactivity. If you're still interested in this, feel free to re-claim. release-assignment
claim
I have submitted in order to fix this. I believe we could resolve this issue once that PR is merged by updating the submodule.


On x86_64, this prints the values in comments: What's happening here is that when we pick the niche to represent of , we pick the largest (or "roomiest") of the niches in , so that further enums around have more optimization opportunities themselves. (Why just one niche? That has to do with the fact that in an , the only part of the representation guaranteed to be always initialized and valid is the tag / niche, but no other variant fields) For , however, we just pick the best niche in and only look at if has no niches at all, so if has a better niche, we miss it. This is a small oversight in the code itself, and arguably it will be slightly nicer once this is fixed, but I wanted to open this issue first, before I have a chance to fix it myself (if someone else doesn't get there first). cc
I was pretty sure that my patch to find the roomiest niche covered that case, but apparently it didn't. :(


This may or may not have the same fix as , but the LinuxTools PR builder doesn't have access to the same variables as the auto builders, which means the docker image fails at the very end () with an undefined env var.
cc


The support for ARMv6 architecture was broken somewhere between ...: compiles file while produces binary that crashes with . More specifically, this is a binary cross-compiled from for arch, linked with a . The hardware is part of Raspberry Pi Zero rev. 1.1, the processor information is as follows:
Presumably due to LLVM update. Can you determine what the illegal instruction is? (E.g. via gdb and .)
did you try compiling code on your raspberry pi 0 ? this might be issue with gcc cross compiler (code generator part)l/linker rather than Rust
Looks like even compilation directly on RPi0 is broken as the compiler/cargo crashes: Running under gdb: I'm not sure if this helpful at all, I can send (e-mail) you the coredump or do anything else you need, unfortunately I have basically no experience debugging low-level ASM issues.
The problematic instruction is , which vfp2 and dpvfp. The target builds with . There were some in LLVM 9 around the sp/dp handling on ARM ( became ), possibly we flipped a default there...
According to the ARM1176JZF-S Technical Reference Manual (which is the CPU used in Raspberry Pi Zero) it contains a VFP11 coprocessor (VFP2 implementation with full support for single-precision and double-precision math operations). Maybe VFP11 is somehow slightly different from what LLVM assumes? ARM refs: VFP11 VectorFloating-point Coprocessor Technical Reference Manual for ARM1136JF-S
Thanks for the references. So both vfp2 and fp64 should be supported. Something I missed before is that the instruction uses the register, while the VFP11 coprocessor only has 16 double-precision registers. To target this CPU needs to be to the target features. It looks like the corresponding does disable . Possibly the default flipped here, in which case we should just add to all the older ARM targets.
This issue might be related to this one - libc's CI is broken since the LLVM upgrade.
This is probably caused by EDIT: Ah nevermind, someone found this already
Reopening until there is confirmation that this is fixed...
Hi with the recent 1.38.0-nightly ( 2019-07-26) both local toolchain / cargo and the cross-compiled binary seem to work. Thanks.
Great, closing as fixed


As per : Add the following link () next to the existing ones: See all std's items Re-exports Primitive Types Modules Macros <-- this one. cc
Thanks for opening the issue! I'll send the PR tomorrow (but if you want to do it, please go ahead ).


When run on an with elided lifetimes, generates documentation containing the anonymous elided lifetimes in the function's signature. Running on the blocking variant of the same function produces a correct signature. You can reproduce this issue by generating docs for the following code: The asynchronous function's docs show the elided lifetimes, the blocking function's docs don't: :
I agree that this makes some function signatures unnecessarily verbose. For example: ... becomes ... However, given the nuances of async functions (specifically: the referenced values must survive every state of the FSM), one could argue that showing these lifetimes in the docs might be useful(?). It's obviously not the worst problem on earth, but could someone at least shed some light on whether this behaviour is intended or not? Is this a feature or a bug? Maybe
I think it's the expected behaviour. However we can discuss about removing the elided lifetimes. In this case it's not really useful...
It's especially visually disruptive with a parameter, making simple methods look significantly more complex than they actually are. It also feels surprising to special-case async functions like this, if it makes sense to show these lifetimes symmetry with traditional functions would be nice.
We have several instances of in the Tokio codebase because the version with explicit lifetimes is simpler than the one with all the elided ones displayed. There are many cases where it would be more useful to just not show lifetimes on the method.
So I don't forget, I got halfway through debugging this and it has something to do with 'in band lifetimes': Naively changing this to use the same mechanism as .
Funnily enough, this does work with 1.34 if you add enough s: ! So in some sense this is a regression, although you needed nightly to use at the time.


Roughly according to cc
Some notes: I think this is not worth fixing as it would require hacks deep in the general sequence parser. We should try to still have suggestions; notes that there are special purpose methods for doing that. "Unnecessary" is semantically misleading here as this is a hard error, not a lint.


This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in


libcore however doesn't use those for the implementations for and for the unit type. This means that the special case in cg_ssa can be removed.
Hi I'd like to work on this. Would be a good initial contribution to Rust :)
I'm really new to the code base, though. Could you clarify what the means above?
That's , a part of the code generation code in rustc. The code in the first snippet is located there.
Thanks for clarifying that! I'll go through the code and post any questions here.
Would love to help but don't know where to start. If mentoring is still possible please ping me or send me in the right direction somehow .
or maybe if your up to the task :)
I think you just need to look at and remove the check for that was mentioned. You can check https://rust- for an overview of the compiler and instruction on how to build it and run tests.
Thanks seems to be a little simpler then I thought once I dug into the docs. Will do hope your having a good one .


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


The keyword doesn't seem to currently work with specialization (namely ). The order of keywords does not matter — I'm not sure which it's supposed to be. Minimal example from in dtolnay/async-trait: which gives the following error
Note that in traits is not yet allowed, so this would be meaningless even if it parsed.
[async_trait] can handle this if rustc will parse it.
Where this came up is when attempting to use the crate, which uses a proc macro to transform async traits to current syntax. I was attempting to use it in Rocket when I ran into this.


has been renamed to as discussed in , but the old name is still referenced in the docs:


Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.


It would be nice to get rustdoc to convert double-hyphen () (probably just when surrounded by spaces?) to a dash character () in doc-comments. People tend to use double-hyphen in code instead of the actual actual character, since it's easier to type on most keyboards. I reckon this could be done perfectly reliably.
Do you have an example of where it'd be useful? In such cases, I'm afraid of side-effects of unwanted replacements or maybe users' misunderstanding.
Well, it's just about nicer typography. See the rustc guide for example. What side effects do you imagine? The main one I can envisage is , but they should always be in backticks, I'd think... and you use a Markdown parser anyway, so I think it's okay.
So still doesn't sell much of a dream: ;)
Oh I know, the benefit is incremental... but the implementation cost is so low, and I don't see the downside. ;-)
I mean... don't we all like nice, propr typography?
Install a better font maybe? :stuckouttongue:
This is nothing to do with fonts... it's to do with vs. !
I'm assuming you mean converting a pair of hyphen-minus characters into an en dash like in TeX? rustdoc uses CommonMark and unless this was to that spec I don't think it's worth adding this feature. It's already possible to insert en dashes using for example.
Yes, I wrote it correctly in my title and the wrong way round in the comment oops. I think this is really orthogonal to Markdown to be honest... Sure, it's already possible, but no one is going to write in doc-comments, that's the problem. We might as well accept the convention and just aim for better typographical display.
I think this is simply incorrect: it's the em dash [—] that I'm trying to emulate when I use a double hyphen [--], not a single hyphen [-] (or an en dash [–] for that matter). Obviously "the actual hyphen character" is easy to type, since a double hyphen is literally just typing it twice. But assuming that was just terminology confusion, auto-converting a double hyphen to an em dash makes a lot of sense to me, and I feel like I've encountered this behavior in other tools before without complaint. Though it also seems reasonable to move this question to the CommonMark spec, since it probably ought to be done in all markdown-processing tools.
was was just me accidentally writing them the wrong way round (I had written it correctly earlier, oops!). en/em-dash is definitely not easier to type on most keyboards (which don't have it) and OSs. On Windows you need an Alt+code combination, and on macOS you need Alt + Shift + for the em-dash! Double-tapping the same key twice is a lot easier, I'm sure. you think the behaviour itself is useful. I agree it would probably make sense to become a part of CommonMark, but I don't think it needs to for us to implement it here. But I'll file an issue there anyway; good idea.
Ah, seems there's already an "optional extension" to the spec, but it has meaning en-dash and meaning em-dash, which is slightly awkward I think. (In practice, en-dash is encountered much less often, I find, since it used primarily for ranges, and the typographic difference from hyphen is less noticeable.)
This is my opinion as well.
See my above comment. It's an optional extension already part of the spec, according to that thread. :-)
Unless I'm mistaken rustdoc now uses pulldown-cmark which performs this transformation. Transformation is performed inconsistently - only in blocks it considers to be markdown. This makes generating documentation in markdown with extra html styling complicated enough to the point it's easier to generate just html. Either way this ticket seems to be completed.


When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per


This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect. But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants


The following ICE's on stable, beta and nightly: <details<summaryBacktrace:</summary</detailsRunning a quick test in godbolt, the first occurrence of the ICE is in stable 1.25. Feel free to close if this is a dupe of
triage: P-medium. has fix in PR (thanks !). Assigning to latter and removing nomination label.


Internal compiler error when missing bound on struct. Reproducible on stable/beta/nightly on . Also, not sure if it already has it's own issue, but is causing an illegal instruction error when you run it with on this code as well, which is also reproducible on playground if you turn the backtrace setting on. I tried this code: () I expected to see this happen: Instead, this happened: rustc versions (from playground): <details<summaryBacktrace (note the SIGILL at the end)</summary<p</p</details
cc
triage: P-high, removing nomination label (has PR).


This fails (as expected): However, the help message is wrong: It should suggest instead. Rust version: 1.38.0 (stable)
I would like to pick this up, in case nobody is working on it
go ahead!


This code: Errors on with this message:
cc
regression in
I'm still building a compiler with graphviz debugging enabled so I can have a closer look, but I have a theory. I believe the problem is that we are too conservative when marking locals as . Because we pessimistically assume that type is , we also assume that type can be mutated through a shared reference. Once a shared reference to it is taken, we assume that all qualifs that could apply to are applied to that local. We should special case zero-sized arrays here, so when the borrow of occurs, it is not marked as indirectly mutable. Perhaps we could assume that zero-sized arrays never actually as well? While this change would solve this particular issue, I believe that this won't solve the problem entirely. What if we take two references to the zero-sized type ()? While the local containing the ZST itself will not be marked as indirectly mutable, the local containing the first borrow will be, which diverges from the old analysis. We may need to base whether a is indirectly mutable on the analysis.


Currently rustdoc's keyboard shortcuts use <kbd<kbdTab</kbd</kbdto cycle between the tabs at the top of search results, and the arrow keys for moving through search results. It's much more common for <kbd<kbdTab</kbd</kbdand <kbd<kbdShift</kbd+ <kbdTab</kbd</kbdto be used for navigating a list, and you can autosupport this by adding es, I think those autoskip elements as well. It's pretty bad form to override <kbd<kbdTab</kbd</kbd. Perhaps we should use for this and use something else for switching the search result tabs?
I never navigated a list using tab. I didn't even know it was a thing. O.o Also, up and down arrows seem more accurate to me and this has been integrated. As a little "bonus", uses arrows as well to go through crates. However, we can talk about adding if you want?
tabindex won't work if we override tab, that's the problem this is a well-established pattern
Even with tabindex, we'll still have to bind 'enter' key I assume to change the current search tab, no? Also, we can't bind right and left arrows to do this so we're kinda limited to find replacements. The last option would be to add a setting to disable like you proposed in I guess? But we have other issues to answer on this other one.
No, if you're using tab navigation the enter key should automatically work to "click" the currently selected thing. The browser functionality around this is quite robust, let's not reinvent it.
TIL. One less thing to worry about. :)
Triage: not aware of any work here
After coming back to this issue after such a long time, I think we should keep the current behavior.
I still disagree. I haven't had the time to prototype this, but this is very much not following the norms for keyboard navigation which has accessibility implications.
I don't see how accessibility can be impacted by this. I assume they don't go through text content the same way and that changing how the interactions are done will change anything for them. In addition to that, when included in , adding more tabindex could be problematic depending on evolutions (we some tabindex there as well).
Firstly, keyboard accessibility is not only for the blind. People may prefer keyboards over mice for many accessibiltiy reasons. However, tab navigation is a huge part of accessibility for the blind in many cases. No, that's the point, we don't actually need to add tabindex, currently we're overriding tab defaults via JS which is almost always really bad. The tab defaults for the page are quite good already, what would happen is that you would tab through focus on the top tabs, and then through all of the links and summary short strings. We may potentially want to exclude the summary short strings from tab navigation, but other than that we wouldn't be doing special tabindex stuff.
The largest problem here is that the moment you tab into the "tabs", your keyboard navigation is stuck there forever. Overriding browser tabbing with JS isn't always a problem but this is like one of the biggest reasons it usually is.
Maybe we could use left/right arrows instead of tab for switching between 'In Names' and 'In Parameters'? I think that's more clear than tabs anyway.
My rough proposal is that we remove all JS that consumes <kbd<kbdTab</kbd</kbd, potentially use on the summary entries (and on the links, if necessary, but i don't think it will be). (Negative tab index = "do not tab-focus this". Zero tab index = "please tab focus this in document order", this does not interfere with any explicitly defined positive tab indices in ) We could also add arrow key navigation, but people also use arrow keys for editing typed search phrases so that's more complex. At the very least we need to get rid of the custom JS IMO.
Hmm, personally I think I'd prefer for left/right to switch the search tabs and have to use explicitly to bring the search bar into focus. I don't think we should get rid of keyboard shortcuts for tabbing without having some replacement, even if it's a few more keystrokes.
Oh sure, I meant that we should not be capturing left/right whilst focused on the search box. We can add that event listener to the search results area, that should be fine.
But then how do you move in the search input? ;) I don't see how the current behavior blocks that? You can still move through answers using up and down arrows. But I think I'm starting to understand your issue: it's the overload we in the JS, right? Then, with what would you replace it? Also, you can use and then use afterwards.
Nothing. The browser has acceptable default tab navigation behavior, though we can improve on it by applying some s if we want You only do this when focused on the search results area
Then I'm lost: how do you switch between the three tabs? But then you need to focus on the search results area, which is almost never the case as far as can I can tell. That doesn't sound like a great idea. :-/
Tab navigate to a different "tab" and hit space. You will after hitting tab a few times. This is how keyboard navigation usually works.
That seems very counter-intuitive. Even more considering that switching between elements using isn't that common. Which is exactly why I don't think this is a good idea here. It's much more complicated than the current behavior.
This is literally how keyboard navigation typically works on the web. There are norms for how to do this, many people use this to a fair amount, some people rely strongly on it. The current behavior tab-locks you which is a huge accessibility hazard. Furthermore, it's nonintuitive, it does not follow the typical model of tab-navigation on the web.
I'm only using keyboard on my computer and I never use tab to switch between elements and I also find current shortcuts good enough.
You can switch to the "default" behavior by simply pressing "esc". I don't see why it's a problem then.
Firstly, no, the escape key exits the search pane altogether. Secondly, keyboard users will not know to expect such a thing. No matter what, it is a problem that our webpages tablock by default. I can't believe that we're having a hard time coming to agreement on that, I would have expected accessibility to be valued here :/
Some citations: From We are currently not coordinated with the structure of the webpage, and we do not follow the visual flow. From We violate this by tablocking From From Tab navigation, which is primarily how you change focus, is changing the context of the page here.
mentioned that she had been having trouble with this as well and was happy to see that it was reported.
What you're reporting isn't about accessibility but about personal preference: not using a mouse is a choice in most cases. Even though I think the current behavior is completely fine, I suggested to replace with another key. I don't want to lose the possibility to navigate the docs only with the keyboard, which is currently possible. Having to focus on tabs' title to switch between them is an absolute non-sense.
Even if this is true, what about the cases that are not the "most" case? That would be things like accessibility. Which does matter.
They can completely use rustdoc without a mouse, which was the whole point of those bindings. Accessibility does matter, I just don't agree with the arguments used here to support this.
This ... is an aspect of accessibility. Accessibility is about making your software accessible to the most number of people as possible; this includes people who are used to interacting with the web via keyboard. Even if it's a choice, it might introduce a barrier to entry to deliberately not use the choice (what if you don't even have a mouse attached to your computer and need to find one?) I do not think we should start a discussion about specific disabilities here, but there can be situations where someone has strong reasons for doing this where it's not "just a choice", as well. Furthermore tab-locking is absolutely a problem for blind users since the tab key is a key part of how blind users interact with the web and software in general. It feels roughly equivalent to locking Feel free to introduce a different keyboard shortcut for them that doesn't use tabs. My recommendation, to make this take the least amount of effort and least amount of change, was to use the default focus behavior and do nothing else. We don't have to force users to use the default focus behavior to navigate the page, I just want that to work. Alternatives would be good too; I'm having a hard time coming up with alternatives because most keys are used during typing. Note that with some tweaks we can make it so that literally the first tab-out of the search box will go to the tabs. So the workflow would be "tab, then hit tab more times to select your 'tab', and space" Also my personal feeling is that the tabs are not that used as much so I'm personally okay not having this. I'll point out that you are calling the default accessibility guidelines of the web as nonsense. This is stuff that has had a lot of work and research put into it, by people who are experts on this topic. The focus model of the web isn't perfect, but it's way better than what we'll be able to come up with. No, they cannot, because these are not clear at all, and there are norms about this so that people don't need to learn bespoke keyboard combinations for each website, because they won't. That's way too much overhead to just use a website. just didn't use search because of this. The tab-locking made it worse so she would refresh the page (not knowing that Esc works) to exit the search since the tab lock wouldn't let her otherwise, and over time stopped. She was typing URLs for documentation items directly instead of using search, which is an illustration of how bad this failure is. I'm sure she can talk more about her experience, but it is absolutely unacceptable for the answer to an accessibility issue to be "they can theoretically use it" when it is not designed for people to practically do it, since there's no obvious way to learn. Help text is not going to help here either, because, again, keyboard navigation on the web is largely a matter of norms, so people will not look for information on how to correctly keyboard navigate, they will simply dismiss the website as broken. That's a huge failure.
You can completely use rustdoc without a mouse (I don't have one for example), this isn't the issue here in my opinion. Well, we still need to keep that in mind in such discussions. I have to admit it's a bit hard to read this when I had to fight to keep rustdoc usable even without JS. But I'm glad that it's now an important parameter of rustdoc and that I'm not the only one to think about it. :) Yes, it's my whole point: I don't mind removing the current tab-locking (even less if it improves experience for people with no mouse!), but it needs to be replaced by something else. You're getting out of scope here, please not give me intentions I don't have. What I said is that the rustdoc search works without keyboard and that if we wanted to not tab-lock anymore, I'm okay with it but we needed to replace it with another key to be able to keep the same behavior overall. I'd rather simply switch fully out of the instead of doing such hacks if possible. We just need to agree on another key to have the same results. I agree with that part, but then it's a complete different issue. You're using one person to back all the reasoning here, which isn't great. I'm sorry if had a bad experience with rustdoc. But one person had issue with rustdoc doesn't mean it's a failure. Once again, it'd be nice to consider that people spent a lot of time on rustdoc and that if they knew about this, they'd be very happy about trying to improve the situation. However, I repeat myself once again: I agree that tab-locking isn't the best and I agree we should replace it and not remove it.
You theoretically can, practically it is hard to discover this keyboard setup and it does not follow norms, so people will not use it. It is! The default focus behavior of the web! Which is what is used everywhere, including on Google Search, which also has search results and tabs. This isn't a hack! This is how focus works on the web by default! We would not even have to write code to support this, our page is laid out in a way that works well without any javascript! No, I also had the same problem here, I just am more comfortable with switching to a mouse for this. I'm highlighting Katie's experience because she hit the worst failure mode -- she stopped using search entirely. Thank you. I do not mind coming up with something better, but I do not want to block it on coming up with additional keyboard shortcuts, because I think this is hard. I want to remove this, and then consider coming up with something that can replace it, keeping in mind that tab-switching would be possible by default via the keyboard the same way it is on Google. I think tab-locking is very very bad and should be gotten rid of as soon as possible.
Honestly, the fact that Google works this way should be a strong signal that we should follow suit, since most people using keyboard navigation will be used to doing it the same way there.
Hi all, I was around when implemented the feature and I have grown quite fond of how it works because it is very intuitive for me. What would you do with the tab key when it is not bound to tabbing trough the results? After pressing escape, the tab is free anyways. Just because Google does something, feels like an ad-hominem argument. Unless you would like rustdoc to collect the most common searches and report them (for a subscription?) to the crate authors too? Can you elaborate on the No-JS idea? Because this is hard for me to imagine since the filtering is very powerful at the moment and I love the reverse search which I need in like 30% of my queries. Cheers, Stefan
a data point: i was wildly surprised to find that <kbdtab</kbdswitches between tabs, and it took me a while to work out that it only happens when the textfield has focus. i usually use vimium to navigate the search results, which works because the results are just (pairs of) links: ! you might notice that the tab titles don't get annotations, because they're just s, so they're not keyboard-accessible.
how many people are necessary? even if the accessibility point is not compelling for some reason, the current tab mechanic has a very surprising behavior: if you begin a search, then empty the box (backspace, or ctrl+a and then backspace), the docs page reverts to the crate documentation as if no search had been done, but focus is still locked to the search bar. the page is visually identical to having not done a search, where tab could cycle between elements. before seeing this issue, i had encountered this and assumed that simply had some flaky javascript, did not make time to investigate, and moved on. i thought it was a bug. to return to a mode where the tab key is useful again, you have to know to press . this means does a different thing for than it does by default on every browser: is a shortcut for "stop", which stops all connections. the escape key has an expected behavior. it will not occur to someone who primarily navigates the internet by keyboard to press the escape key. i would have the tab key to cycle through through tabs and continue to the "in names" content, from top to bottom. cycling from "In Return Types" to "In Names" is an extremely narrow repurposing of tab (and shift+tab, to go backwards in tab order) command.
Then that is a problem we should address! Well, you can't get this page if you don't have javascript enabled, so in that sense, it wouldn't improve anything. :laughing: And it's exactly what I suggest by replacing instead of removing. The default web behavior exists but requires multiple actions. We can do better than that (like we currently do for example). Because the page is much simpler and I think the comparison is a bit out of context here. For reference, I was commenting on this: and I misunderstood what you meant. But that still makes more interactions than the current behavior (one), which is why I want a replacement and not a removal. And again, without javascript, you can't have the search results page. And I'm sorry about that. Which is why we're currently discussing about fixing it.
1. The whole point here is about prioritization. Until recently, I was mostly alone working on this. suggested this new feature, I thought it was nice and would improve everyone's life. Now I realize it didn't, I'm sorry about it but I still want to be able to switch tabs without losing focus on the search bar. We just need to agree on a key to do so and then it's done. Please all remember that it's mostly about priority. I don't voluntarily want to make people rustdoc's experience bad. If something doesn't feel right to you, well, it's simply because I ignored it could be used this way. Could you open a separate issue about this please?
will do. another point: in current versions of chrome, without vimium installed, pressing <kbdesc</kbddoes not release focus from the text field, it cancels the search altogether. so as far as i can see, if you don't use vimium, there's no way to recover the usual behaviour of <kbdtab</kbdonce you've done a search.
Browsers by default use the tab key for focus, which is an important accessibility property. It would just use the default behavior, which lets you switch through "tabs" and the search results This was an argument about norms: When people interact with the web, there are norms as to how things work. You can expect to find a search box at the top or top right of the page. You can expect to find a contact us at the bottom. Nobody is going to learn a billion minute things about how to use a particular website, a lot of this is based on norms. If you follow norms, you do not need to educate your users on how to use your website, which is exactly the problem we have here. Furthermore, the fact that Google -- an organization large enough to have accessibility teams to actually do the research on this -- picked the default behavior on their main website, is a pretty large signal. But okay, Bing has similar behavior, except focus starts on the first search entry, and you can shift-tab to get back to the "tabs". This is also easy behavior to replicate with a little javascript. Wikipedia doesn't have "tabs" but it has options at the top of the search and it works the same way. Oh no i'm not saying we remove all the JS here, I'm just saying that if we remove the JS around the tab key the default behavior is actually quite okay.
I meant no further custom JS. I understood what you meant. That is more interactions, but what i'm saying is that -- we are not losing the ability to do this, it's just harder (but following web norms, so nobody has to learn them!!), and given that we are currently violating many accessibility guidelines I would like to remove this behavior as soon as possible (there was less urgency for me when I filed this because I had not noticed the tablocking), and perhaps introduce new behavior later if possible. I'm having trouble imagining a good option for new behavior. The best I can think of is using the up/down arrow keys for this, which isn't super intuitive.
up/down is already used to go through items in the current tab, so we'll need another one haha. tab was very convenient for that... Well anyway, let's just pick a key, whichever the one we take and I'll open a PR so we can move on.
Just got an idea for the key: ctrl (or shift) + up/down would go through tabs up/down alone go through items in the list How does that sound?
It's voluntary (just realized it). The search page results is supposed to be switched into/out quickly by using escape or focusing on the search bar. We should really add all the rustdoc interactions into the help... I'll do that once we've settled down here.
My expectation is that arrow keys are for scrolling and tab is for selecting. It took me some time to get used to rustdoc doing things differently.
shift + up/down should be a non-option: shift+up will select the text being searched for. why must the list of tabs be cyclic? is going from the third tab to first tab in one keystroke a common task? i do not understand why tab cannot move focus from the third tab to the first item in the selected tab of results
that seems great! It seems a little unintuitive to me but that is fine, I don't think tab-switching is a particularly common operation. If you're okay with people learning the key combos I'm all for it.
I think I can explain this, wants a way to go through search results without having to defocus the search field, so that you can keep typing
Not if you in a input field. And that problem will be solved when we'll stop tab-locking. ;) Good point, ctrl+arrows then! That's a completely different behavior. But since we won't have tab-lock anymore, it'll now be possible so I guess it's all good? You'll have the choice between using rustdoc events through the search input or you can simply use the normal events by unfocusing the search input. Exactly! Great! I'll send the PR shortly then. We really need to improve the help popup.
ah, so pressing enter to (say) select an alternate tab would be out of the question since it would defocus? i can see that
Hello! Pardon the late response. As mentioned above, I would like to reiterate that is not only a conventional choice for navigating through lists such as this, but also a specified best practice for web accessibility. The W3C Working Groups's Authoring Practices says . I will try not to rehash the accessibility discussion above, but I will say that I do not own a mouse. Regardless of whether or not that is "by choice" due to a disability, this means that the tablocking behavior makes the generated documentation difficult for me to use. In many situations, rather than using the search feature, I often opt to manually type the URL's myself to navigate to a given type. While today I am a Rust engineer by trade, until very recently I worked as a front-end engineer, often focusing on improving the accessibility features of existing websites. The behavior that is requesting is not a matter of preference, it is considered an industry-wide best practice. I do not believe that citing other websites' conformance to this is an ad-hominem argument, it is reasonable supporting evidence of this position.
I use vimium for navigation and browser use. I find the rust docs to be very amenable to use of a keyboard with vimium.
Could you and implement it? Since you seem more knowledgeable in this area.
I mean, we were suggesting switching to the default behavior of the browser, so there's nothing new to implement, just code to use. I'm happy to do this or implement Guillaume's proposed keyboard shortcuts but it seems like he's already working on it? If not, happy to do this myself. There's a follow-up I'd like to experiment with which I'll implement, but I'll do that once we resolve this
Arf, another issue? :-/
While I appreciate the invitation to do so, I have very little familiarity with the internals of , and unfortunately very little bandwidth to contribute as of late. I do want to make a note of appreciation for all of the work that goes into maintaining this project, but I should disclaim that I was offering a comment describing my experience from the perspective of (a) a user of the Rust documentation impacted by keyboard accessibility, and (b) an engineer that has some previous experience with web accessibility guidelines and standards.
Nothing pressing, I just have ideas for how we can be even better here and want to experiment. I'll open PRs if I find something that works well


While it's important to keep on top of regressions to the toolstate, most of the time these issues are fixed quickly, by the author of the PR that caused the regression, or someone else. With GitHub notifications being difficult enough to keep up with as it is, being mentioned on every toolstate change issue is mostly noise. The issues are already tagged T-compiler and nominated, so I think additionally pinging everyone is unnecessary. I think it would be sensible to change: to: cc
I think that's a good idea!
I agree that the pings are rarely useful. Nominating is probably sufficient.


The following does not error locally / on the playground If I copy paste the macro into the same file, it errors as expected Checking other macros, error as expected.
This feels like it's related to a similar issue () I created a while back.
cc
This is probably because the "error" is just a lint. And we appear to silence it in external macros. We shouldn't do that. IIRC this is just a flag that needs to be set for the lint macro
Yes, we need to set reportinexternal_macro param on the lint I believe
Ah, that makes sense! Building locally with the parameter set to confirm. it does ^^ will check the samples in there too.


Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Fix is on the way at


Running Servo’s unit tests started failing on CI a couple nightlies ago. A customized CI task to add shows: The error message appears to come from here: Reading through the call sites of this function I quickly reach in , so I don’t understand how this message could be emitted while is not actually present in the command-line arguments given to rustc by Cargo. I have also not managed to reproduce this outside of the CI environment. I don’t have an exact regression range, but this started happening a couple days ago which is close to when landed. This PR updated Cargo, including whose description mentions using rustc’s JSON output more. I suspect this is what caused the issue to be uncovered, but it looks like the root cause is in rustc’s argument parsing.
Sorry for the noise! I managed to reproduce in a local docker container (in order to copy CI’s config exactly), the problem turned out to be using an old version of sccache:


I started to further investigate the bug blocking . The following is a minimised test case: Results in (with debug assertions enabled): Here with the backtrace: <details</detailsI would love to investigate further, but I am too confused and the panic message doesn't tell me anything useful either. But please tell me if I can do anything else to help you solve the bug. I'd love to have it fixed so that I can continue working on . CC
It's this debug assertion that's failing: Debug assertions are not turned on on released artifacts, but your local probably has them enabled.
Ohhh, that explains the weirdness. Should have thought of that myself. Thanks! But anyway, it's still a bug I assume. And I couldn't find another const generic bug with this error message.
The test case is sufficient with debug assertions (I can reproduce locally). Sorry, I've been meaning to look into this for ages. Having a minimal test case is helpful.
No problem, I'm happy for every minute you spend working on const generics ^_^
Sounds like inference variables are leaking out of somewhere. EDIT: wait, canonical variables reuse some of that infra - is the definition of symmetrical between , and ?
I had a quick look, and didn't spot any obvious asymmetries, but there surely must be for this error to occur…
This doesn't seem to have an analogue anymore in /: This mentions regions even though it shouldn't:
The first has an analogue in: I'll fix the second one.
I think the problem is here: We are creating a new canonical variable for the const value but are returning the type unchanged. So if the type has inference variables in it they will leak through.
So was replaced by ? The same should be done for consts.
Opened for that.


modify labels: E-easy
I think it is known that those are broken, it is tracked in the . I'm not sure if is still interested in updating the submodule. Is it in a passable state now?
Oops I know I was missing something! PR opened. Thanks


Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium. Removing nomination label.


When running this test (): the output is which makes it hard to spot the difference in whitespace characters. Would it be possible to change this to e.g.: This would improve the usability when running into these kinds of test failures and also make it more consistent with which outputs both the left and the right value too.
Agree with having them vertically aligned. I think we do want line endings to create a new line though for multi-line readability. Maybe we should say something like this: (The first difference at char line we might also want to add to assert_eq also?)
The message sounds good, but I am not sure how well it applies to the comparison, as it is not an equality, but a substring comparison. Maybe we could adjust the wording of the error message to e.g.: to make that easier to spot. I think the escaping is essential, take for instance which has no newlines, but contains : On many shells, this will produce this output: which makes it very hard for a user to figure out what's going on (let's assume the happens in a more obscure location). Maybe a more important reason is that escaping would be consistent with the behavior of , which for : outputs: The escaping avoids surprises which could occur depending on the user`s environment.
Ok I'm sold. Do you want to fork rust-lang/rust and submit this as a PR? (If you don't want to I can do the legwork).
Thanks for the offer, I'll try to write a PR and will add you as a reviewer once I have a first version ready.


produces an expected error: , the original error is replaced with this: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Nominating because: The trait impl does not exist, the compiler hallucinated it into existence Inherent methods are supposed to take precedence over trait methods This might indicate a quite serious bug in the compiler.
I would suggest stable- and beta-nominating the fix for this PR; it seems like this could warrant a point release. cc
modify labels: beta-nominated stable-nominated
Phew; looks like precedence works correctly in non-error code at least: Crisis averted? :)
assign
unnominating for back ports; we don't backport nominate issues, just Pull Requests.
claim I'll take a look, since is finding this to be mighty tricky to track down
I managed to get similar symptoms without async but with . But this time the trait compiles.
I am 99% sure that also applies here.
The async case is fixed by , I think we should break out the arbitrary self types case into a distinct bug.


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


PR introduced an ICE in the following code with :
cc with mir-opt-level=1: with mir-opt-level=2: Where the types are


I encounter an ICE: with rustc 1.41.0-nightly ( 2019-11-29) running on x8664-apple-darwin when compiling The same code does not ICE when using nightly-2019-11-27-x8664-apple-darwin Sorry, I haven't taken the time to make a minimal reproduction example.
Can you post the ICE message and backtrace?
Certainly! Although it is not the best stacktrace I have ever seen. Backtrace:
Backtrace:
modify labels: A-mir
I think I have a clue here: First the code: The problem seems to be a partial move of together with async together with a generic type (if we replace by for example, rust will complain as well and no ICE). If we remove the rust will complain: modify labels: +A-async-await -E-needs-mcve +E-needs-bisection
Regression in cc modify labels: -E-needs-bisection
triage: has PR. P-high, removing nomination.


I was working on making a run-make test today for a particular thumb target. While looking over how we do this elsewhere, I found this bit of code: From my local testing, it seems like having multiple lines of this form has the net effect of making the test a no-op that does not test anything: since a target matching line 13 will not match line 14, and vice versa, there are no targets that can run on this test. We should either revert the portion of the commit that did this: or figure out some other way to express the desired property here (or change the semantics of when multiple targets are provided to make it gather all such targets up in a set before doing the check for membership... but I am wary of making such a change since doing it right would require differentiating e.g. processor target vs OS target, for example...)
Also, It looks like there may be other instances of the same mistake elsewhere in the test suite, such as in:
Oof, not good. It shouldn't be hard to make rustbuild outright reject this scenario though.
Further effort on has led me to conclude that these lines do not work at all, at least not for cross-compilation.