Question:
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

["T", "Focus the theme picker menu"], ["↑", "Move up in search results"], ["↓", "Move down in search results"],  ["↹", "Switch tab"],   ["ctrl + ↑ / ↓", "Switch result tab"],  ["⏎", "Go to active search result"], ["+", "Expand all sections"], ["-", "Collapse all sections"],  ].map(x => "
" + x[0] + "

" + x[1] + "
").join("");   ].map(x => "
" + x[0].split(" ") .map((y, index) => (index & 1) === 0 ? "" + y + "" : y) .join("") + "

" + x[1] + "
").join("");  var div_shortcuts = document.createElement("div"); addClass(div_shortcuts, "shortcuts"); div_shortcuts.innerHTML = "
Keyboard Shortcuts

" + shortcuts + "

";


Question:
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.

cc @{}, do you think you would have time to do the follow-up work? If so, that would be great! <del> cc @{}, the PR reviewer, and @rust-lang/compiler -- nominating for prioritization. </del> <ins> cc @{}, the PR reviewer, and nominating for compiler team prioritization. </ins> ''').format( relevant_pr_number, tool, status_description,


Question:
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.

declare_lint! { pub CONST_ERR, Deny, <del> "constant evaluation detected erroneous expression" </del> <ins> "constant evaluation detected erroneous expression", report_in_external_macro: true </ins> } declare_lint! {


Question:
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.

<ins> #![feature(allow_internal_unstable)] // Macro to help ensure CONST_ERR lint errors // are not silenced in external macros. // https://github.com/rust-lang/rust/issues/65300 #[macro_export] #[allow_internal_unstable(type_ascription)] macro_rules! static_assert { ($test:expr) => { #[allow(dead_code)] const _: () = [()][!($test: bool) as usize]; } } </ins>


Question:
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.

<ins> // edition:2018 // aux-build:external_macro.rs // Ensure that CONST_ERR lint errors // are not silenced in external macros. // https://github.com/rust-lang/rust/issues/65300 extern crate external_macro; use external_macro::static_assert; fn main() { static_assert!(2 + 2 == 5); //~ ERROR } </ins>


Question:
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.

<ins> error: any use of this value will cause an error --> $DIR/const-external-macro-const-err.rs:12:5 | LL |     static_assert!(2 + 2 == 5); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ index out of bounds: the len is 1 but the index is 1 | = note: `#[deny(const_err)]` on by default = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info) error: aborting due to previous error </ins>


Question:
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

<del> Subproject commit 5cb983338e924ec85898880d60e65f2a1291b7be </del> <ins> Subproject commit 52cebb1f8f8789b97d243c07bf4c961ca0017f7b </ins>


Question:
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:

#[stable(feature = "rust1", since = "1.0.0")] impl fmt::Debug for RangeFull { fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result { <del> fmt::Debug::fmt("..", fmt) </del> <ins> write!(fmt, "..") </ins> } }


Question:
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.

self.tcx().mk_const( ty::Const { val: ConstValue::Infer(InferConst::Canonical(self.binder_index, var.into())), <del> ty: const_var.ty, </del> <ins> ty: self.fold_ty(const_var.ty), </ins> } ) }


Question:
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.

<ins> // revisions:rpass1 #![feature(const_generics)] struct Struct<T>(T); impl<T, const N: usize> Struct<[T; N]> { fn f() {} fn g() { Self::f(); } } fn main() { Struct::<[u32; 3]>::g(); } </ins>


Question:
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.

<ins> // revisions:rpass1 #![feature(const_generics)] struct FakeArray<T, const N: usize>(T); impl<T, const N: usize> FakeArray<T, { N }> { fn len(&self) -> usize { N } } fn main() { let fa = FakeArray::<u32, { 32 }>(1); assert_eq!(fa.len(), 32); } </ins>


Question:
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.

<ins> // revisions:cfail1 #![feature(const_generics)] //[cfail1]~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct S<T, const N: usize>([T; N]); fn f<T, const N: usize>(x: T) -> S<T, {N}> { panic!() } fn main() { f(0u8); //[cfail1]~^ ERROR type annotations needed } </ins>


Question:
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.

<ins> // revisions:cfail1 #![feature(const_generics)] //[cfail1]~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash fn combinator<T, const S: usize>() -> [T; S] {} //[cfail1]~^ ERROR mismatched types fn main() { combinator().into_iter(); //[cfail1]~^ ERROR type annotations needed } </ins>


Question:
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.

<ins> // revisions:rpass1 #![feature(const_generics)] pub struct Foo<T, const N: usize>([T; 0]); impl<T, const N: usize> Foo<T, {N}> { pub fn new() -> Self { Foo([]) } } fn main() { let _: Foo<u32, 0> = Foo::new(); } </ins>


Question:
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

<del> Subproject commit 941968db2fd9c85788a4f971c8e425d46b4cb734 </del> <ins> Subproject commit 75a5f9236c689a547fe207a10854f0775bce7937 </ins>


Question:
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.

"regex-syntax", "semver", "serde", <del> "smallvec 0.6.10", </del> <ins> "smallvec 1.0.0", </ins> "toml", "unicode-normalization", "url 2.1.0",


Question:
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.

let host_libs = builder .stage_out(compiler, Mode::ToolRustc) .join(builder.cargo_dir()); <ins> let target_libs = builder .stage_out(compiler, Mode::ToolRustc) .join(&self.host) .join(builder.cargo_dir()); </ins> cargo.env("HOST_LIBS", host_libs); <ins> cargo.env("TARGET_LIBS", target_libs); </ins> // clippy tests need to find the driver cargo.env("CLIPPY_DRIVER_PATH", clippy);


Question:
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.

<del> Subproject commit c8e3cfbdd997839c771ca32c7ac860fe95149a04 </del> <ins> Subproject commit 3abdd2f1ced4cf3a44c7de88c5e39b3bb5037c4d </ins>


Question:
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.

let result = match (&desc.should_panic, task_result) { (&ShouldPanic::No, Ok(())) | (&ShouldPanic::Yes, Err(_)) => TestResult::TrOk, (&ShouldPanic::YesWithMessage(msg), Err(ref err)) => { <del> if err </del> <ins> let maybe_panic_str = err </ins> .downcast_ref::<String>() .map(|e| &**e) <del> .or_else(|| err.downcast_ref::<&'static str>().map(|e| *e)) .map(|e| e.contains(msg)) .unwrap_or(false) { </del> <ins> .or_else(|| err.downcast_ref::<&'static str>().map(|e| *e)); if maybe_panic_str.map(|e| e.contains(msg)).unwrap_or(false) { </ins> TestResult::TrOk <ins> } else if desc.allow_fail { TestResult::TrAllowedFail } else if let Some(panic_str) = maybe_panic_str { TestResult::TrFailedMsg(format!( r#"panic did not contain expected string panic message: `{:?}`, expected substring: `{:?}`"#, panic_str, msg )) </ins> } else { <del> if desc.allow_fail { TestResult::TrAllowedFail } else { TestResult::TrFailedMsg( format!("panic did not include expected string '{}'", msg) ) } </del> <ins> TestResult::TrFailedMsg(format!( r#"expected panic with string value, found non-string value: `{:?}` expected substring: `{:?}`"#, (**err).type_id(), msg )) </ins> } } (&ShouldPanic::Yes, Ok(())) => {


Question:
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.

// TestType, TrFailedMsg, TrIgnored, TrOk, }, }; <ins> use std::any::TypeId; </ins> use std::sync::mpsc::channel; use std::time::Duration;


Question:
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.

let (tx, rx) = channel(); run_test(&TestOpts::new(), false, desc, RunStrategy::InProcess, tx, Concurrent::No); let result = rx.recv().unwrap().result; <del> assert!(result != TrOk); </del> <ins> assert_ne!(result, TrOk); </ins> } #[test]


Question:
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.

let (tx, rx) = channel(); run_test(&TestOpts::new(), false, desc, RunStrategy::InProcess, tx, Concurrent::No); let result = rx.recv().unwrap().result; <del> assert!(result == TrIgnored); </del> <ins> assert_eq!(result, TrIgnored); </ins> } // FIXME: Re-enable emscripten once it can catch panics again (introduced by #65251)


Question:
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.

let (tx, rx) = channel(); run_test(&TestOpts::new(), false, desc, RunStrategy::InProcess, tx, Concurrent::No); let result = rx.recv().unwrap().result; <del> assert!(result == TrOk); </del> <ins> assert_eq!(result, TrOk); </ins> } // FIXME: Re-enable emscripten once it can catch panics again (introduced by #65251)


Question:
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.

panic!("an error message"); } let expected = "foobar"; <del> let failed_msg = "panic did not include expected string"; </del> <ins> let failed_msg = r#"panic did not contain expected string panic message: `"an error message"`, expected substring: `"foobar"`"#; </ins> let desc = TestDescAndFn { desc: TestDesc { name: StaticTestName("whatever"),


Question:
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.

let (tx, rx) = channel(); run_test(&TestOpts::new(), false, desc, RunStrategy::InProcess, tx, Concurrent::No); let result = rx.recv().unwrap().result; <del> assert!(result == TrFailedMsg(format!("{} '{}'", failed_msg, expected))); </del> <ins> assert_eq!(result, TrFailedMsg(failed_msg.to_string())); } // FIXME: Re-enable emscripten once it can catch panics again (introduced by #65251) #[test] #[cfg(not(target_os = "emscripten"))] fn test_should_panic_non_string_message_type() { use crate::tests::TrFailedMsg; fn f() { panic!(1i32); } let expected = "foobar"; let failed_msg = format!(r#"expected panic with string value, found non-string value: `{:?}` expected substring: `"foobar"`"#, TypeId::of::<i32>()); let desc = TestDescAndFn { desc: TestDesc { name: StaticTestName("whatever"), ignore: false, should_panic: ShouldPanic::YesWithMessage(expected), allow_fail: false, test_type: TestType::Unknown, }, testfn: DynTestFn(Box::new(f)), }; let (tx, rx) = channel(); run_test(&TestOpts::new(), false, desc, RunStrategy::InProcess, tx, Concurrent::No); let result = rx.recv().unwrap().result; assert_eq!(result, TrFailedMsg(failed_msg)); </ins> } // FIXME: Re-enable emscripten once it can catch panics again (introduced by #65251)


Question:
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.

let (tx, rx) = channel(); run_test(&TestOpts::new(), false, desc, RunStrategy::InProcess, tx, Concurrent::No); let result = rx.recv().unwrap().result; <del> assert!(result == TrFailedMsg("test did not panic as expected".to_string())); </del> <ins> assert_eq!(result, TrFailedMsg("test did not panic as expected".to_string())); </ins> } fn report_time_test_template(report_time: bool) -> Option<TestExecTime> {


Question:
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.

]; for (a, b) in expected.iter().zip(filtered) { <del> assert!(*a == b.desc.name.to_string()); </del> <ins> assert_eq!(*a, b.desc.name.to_string()); </ins> } }


Question:
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.

<ins> // edition:2018 trait Test<T> { fn is_some(self: T); //~ ERROR invalid `self` parameter type } async fn f() { let x = Some(2); if x.is_some() { println!("Some"); } } fn main() {} </ins>


Question:
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.

<ins> error[E0307]: invalid `self` parameter type: T --> $DIR/issue-66312.rs:4:22 | LL |     fn is_some(self: T); |                      ^ | = note: type of `self` must be `Self` or a type that dereferences to it = help: consider changing to `self`, `&self`, `&mut self`, `self: Box<Self>`, `self: Rc<Self>`, `self: Arc<Self>`, or `self: Pin<P>` (where P is one of the previous types except `Self`) error: aborting due to previous error For more information about this error, try `rustc --explain E0307`. </ins>


Question: 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.

"clippy_lints", "compiletest_rs", "derive-new", <ins> "git2", </ins> "lazy_static 1.3.0", "regex", "rustc-workspace-hack", "rustc_tools_util 0.2.0", "semver", "serde", <ins> "tempfile", </ins> "tester", ]


Question: 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.

<del> Subproject commit 7b8e8293d08d298579470f9d6c74731043c6601a </del> <ins> Subproject commit 7a943a9dfcdca98e5988da6d0b7d2f83a364b5ba </ins>


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

impl<'tcx> MirPass<'tcx> for SimplifyArmIdentity { fn run_pass(&self, _: TyCtxt<'tcx>, _: MirSource<'tcx>, body: &mut Body<'tcx>) { <del> for bb in body.basic_blocks_mut() { </del> <ins> let (basic_blocks, local_decls) = body.basic_blocks_and_local_decls_mut(); for bb in basic_blocks { </ins> // Need 3 statements: let (s0, s1, s2) = match &mut *bb.statements { [s0, s1, s2] => (s0, s1, s2),


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

Some(x) => x, }; if local_tmp_s0 != local_tmp_s1 <ins> // The field-and-variant information match up. </ins> || vf_s0 != vf_s1 <ins> // Source and target locals have the same type. // FIXME(Centril | oli-obk): possibly relax to same layout? || local_decls[local_0].ty != local_decls[local_1].ty // We're setting the discriminant of `local_0` to this variant. </ins> || Some((local_0, vf_s0.var_idx)) != match_set_discr(s2) { continue;


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

<ins> // Checks that `SimplifyArmIdentity` is not applied if enums have incompatible layouts. // Regression test for issue #66856. // // compile-flags: -Zmir-opt-level=2 enum Src { Foo(u8), Bar, } enum Dst { Foo(u8), } fn main() { let e: Src = Src::Foo(0); let _: Dst = match e { Src::Foo(x) => Dst::Foo(x), Src::Bar => Dst::Foo(0), }; } // END RUST SOURCE // START rustc.main.SimplifyArmIdentity.before.mir // fn main() -> () { //     ... //     bb0: { //         StorageLive(_1); //         ((_1 as Foo).0: u8) = const 0u8; //         discriminant(_1) = 0; //         StorageLive(_2); //         _3 = discriminant(_1); //         switchInt(move _3) -> [0isize: bb3, 1isize: bb1, otherwise: bb2]; //     } //     bb1: { //         ((_2 as Foo).0: u8) = const 0u8; //         discriminant(_2) = 0; //         goto -> bb4; //     } //     ... //     bb3: { //         _4 = ((_1 as Foo).0: u8); //         ((_2 as Foo).0: u8) = move _4; //         discriminant(_2) = 0; //         goto -> bb4; //     } //     ... // } // END rustc.main.SimplifyArmIdentity.before.mir // START rustc.main.SimplifyArmIdentity.after.mir // fn main() -> () { //     ... //     bb0: { //         StorageLive(_1); //         ((_1 as Foo).0: u8) = const 0u8; //         discriminant(_1) = 0; //         StorageLive(_2); //         _3 = discriminant(_1); //         switchInt(move _3) -> [0isize: bb3, 1isize: bb1, otherwise: bb2]; //     } //     bb1: { //         ((_2 as Foo).0: u8) = const 0u8; //         discriminant(_2) = 0; //         goto -> bb4; //     } //     ... //     bb3: { //         _4 = ((_1 as Foo).0: u8); //         ((_2 as Foo).0: u8) = move _4; //         discriminant(_2) = 0; //         goto -> bb4; //     } //     ... // } // END rustc.main.SimplifyArmIdentity.after.mir </ins>


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

<ins> // This used to mis-compile because the mir-opt `SimplifyArmIdentity` // did not check that the types matched up in the `Ok(r)` branch. // // run-pass // compile-flags: -Zmir-opt-level=2 #[derive(Debug, PartialEq, Eq)] enum SpecialsRes { Res(u64) } fn e103() -> SpecialsRes { if let Ok(r) = "1".parse() { SpecialsRes::Res(r) } else { SpecialsRes::Res(42) } } fn main() { assert_eq!(e103(), SpecialsRes::Res(1)); } </ins>


Question:
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.

let tcx = self.infcx.tcx; let generics = tcx.generics_of(self.mir_def_id); let param = generics.type_param(&param_ty, tcx); <del> let generics = tcx.hir().get_generics(self.mir_def_id).unwrap(); suggest_constraining_type_param( generics, &mut err, &param.name.as_str(), "Copy", tcx.sess.source_map(), span, ); </del> <ins> if let Some(generics) = tcx.hir().get_generics(self.mir_def_id) { suggest_constraining_type_param( generics, &mut err, &param.name.as_str(), "Copy", tcx.sess.source_map(), span, ); } </ins> } let span = if let Some(local) = place.as_local() { let decl = &self.body.local_decls[local];


Question:
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.

<ins> // edition:2018 struct Ia<S>(S); impl<S> Ia<S> { fn partial(_: S) {} fn full(self) {} async fn crash(self) { Self::partial(self.0); Self::full(self); //~ ERROR use of moved value: `self` } } fn main() {} </ins>


Question:
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.

<ins> error[E0382]: use of moved value: `self` --> $DIR/issue-66958-non-copy-infered-type-arg.rs:11:20 | LL |         Self::partial(self.0); |                       ------ value moved here LL |         Self::full(self); |                    ^^^^ value used here after partial move | = note: move occurs because `self.0` has type `S`, which does not implement the `Copy` trait error: aborting due to previous error For more information about this error, try `rustc --explain E0382`. </ins>


Question:
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.

# - thumbv7em-none-eabihf (Bare Cortex-M4F, M7F, FPU, hardfloat) # - thumbv7m-none-eabi (Bare Cortex-M3) <del> # only-thumbv6m-none-eabi # only-thumbv7em-none-eabi # only-thumbv7em-none-eabihf # only-thumbv7m-none-eabi </del> <ins> # only-thumb </ins> # For cargo setting RUSTC := $(RUSTC_ORIGINAL)


Question:
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.

CRATE_URL := https://github.com/rust-embedded/cortex-m CRATE_SHA1 := a448e9156e2cb1e556e5441fd65426952ef4b927 # 0.5.0 <del> export RUSTFLAGS := --cap-lints=allow </del> <ins> # Don't make lints fatal, but they need to at least warn or they break Cargo's target info parsing. export RUSTFLAGS := --cap-lints=warn </ins> all: env


Question:
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.

-include ../../run-make-fulldeps/tools.mk <del> # only-thumbv7m-none-eabi # only-thumbv6m-none-eabi </del> <ins> # only-thumb </ins> # How to run this # $ ./x.py clean


Question:
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.

<del> [target.thumbv7m-none-eabi] # uncomment this to make `cargo run` execute programs on QEMU </del> <ins> [target.thumbv6m-none-eabi] # FIXME: Should be Cortex-M0, but Qemu used by CI is too old </ins> runner = "qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" <del> [target.thumbv6m-none-eabi] # uncomment this to make `cargo run` execute programs on QEMU # For now, we use cortex-m3 instead of cortex-m0 which are not supported by QEMU </del> <ins> [target.thumbv7m-none-eabi] </ins> runner = "qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" <ins> [target.thumbv7em-none-eabi] runner = "qemu-system-arm -cpu cortex-m4 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" [target.thumbv7em-none-eabihf] runner = "qemu-system-arm -cpu cortex-m4 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" [target.thumbv8m.base-none-eabi] # FIXME: Should be the Cortex-M23, bt Qemu does not currently support it runner = "qemu-system-arm -cpu cortex-m33 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" [target.thumbv8m.main-none-eabi] runner = "qemu-system-arm -cpu cortex-m33 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" [target.thumbv8m.main-none-eabihf] runner = "qemu-system-arm -cpu cortex-m33 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" </ins> [target.'cfg(all(target_arch = "arm", target_os = "none"))'] # uncomment ONE of these three option to make `cargo run` start a GDB session # which option to pick depends on your system


Question:
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.

# "-C", "linker=arm-none-eabi-gcc", # "-C", "link-arg=-Wl,-Tlink.x", # "-C", "link-arg=-nostartfiles", <del> ] </del>  No newline at end of file <ins> ] </ins>


Question:
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.

<ins> # This file is automatically @generated by Cargo. # It is not intended for manual editing. [[package]] name = "aligned" version = "0.3.2" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "as-slice 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "as-slice" version = "0.1.2" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "generic-array 0.12.3 (registry+https://github.com/rust-lang/crates.io-index)", "generic-array 0.13.2 (registry+https://github.com/rust-lang/crates.io-index)", "stable_deref_trait 1.1.1 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "bare-metal" version = "0.2.5" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "rustc_version 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "cortex-m" version = "0.6.2" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "aligned 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)", "bare-metal 0.2.5 (registry+https://github.com/rust-lang/crates.io-index)", "volatile-register 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "cortex-m-rt" version = "0.6.11" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "cortex-m-rt-macros 0.1.7 (registry+https://github.com/rust-lang/crates.io-index)", "r0 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "cortex-m-rt-macros" version = "0.1.7" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "proc-macro2 1.0.8 (registry+https://github.com/rust-lang/crates.io-index)", "quote 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)", "syn 1.0.14 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "cortex-m-semihosting" version = "0.3.5" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "cortex-m 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "example" version = "0.1.0" dependencies = [ "cortex-m 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)", "cortex-m-rt 0.6.11 (registry+https://github.com/rust-lang/crates.io-index)", "cortex-m-semihosting 0.3.5 (registry+https://github.com/rust-lang/crates.io-index)", "panic-halt 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "generic-array" version = "0.12.3" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "typenum 1.11.2 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "generic-array" version = "0.13.2" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "typenum 1.11.2 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "panic-halt" version = "0.2.0" source = "registry+https://github.com/rust-lang/crates.io-index" [[package]] name = "proc-macro2" version = "1.0.8" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "unicode-xid 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "quote" version = "1.0.2" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "proc-macro2 1.0.8 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "r0" version = "0.2.2" source = "registry+https://github.com/rust-lang/crates.io-index" [[package]] name = "rustc_version" version = "0.2.3" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "semver 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "semver" version = "0.9.0" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "semver-parser 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "semver-parser" version = "0.7.0" source = "registry+https://github.com/rust-lang/crates.io-index" [[package]] name = "stable_deref_trait" version = "1.1.1" source = "registry+https://github.com/rust-lang/crates.io-index" [[package]] name = "syn" version = "1.0.14" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "proc-macro2 1.0.8 (registry+https://github.com/rust-lang/crates.io-index)", "quote 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)", "unicode-xid 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "typenum" version = "1.11.2" source = "registry+https://github.com/rust-lang/crates.io-index" [[package]] name = "unicode-xid" version = "0.2.0" source = "registry+https://github.com/rust-lang/crates.io-index" [[package]] name = "vcell" version = "0.1.2" source = "registry+https://github.com/rust-lang/crates.io-index" [[package]] name = "volatile-register" version = "0.2.0" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "vcell 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)", ] [metadata] "checksum aligned 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)" = "eb1ce8b3382016136ab1d31a1b5ce807144f8b7eb2d5f16b2108f0f07edceb94" "checksum as-slice 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "be6b7e95ac49d753f19cab5a825dea99a1149a04e4e3230b33ae16e120954c04" "checksum bare-metal 0.2.5 (registry+https://github.com/rust-lang/crates.io-index)" = "5deb64efa5bd81e31fcd1938615a6d98c82eafcbcd787162b6f63b91d6bac5b3" "checksum cortex-m 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)" = "2954942fbbdd49996704e6f048ce57567c3e1a4e2dc59b41ae9fde06a01fc763" "checksum cortex-m-rt 0.6.11 (registry+https://github.com/rust-lang/crates.io-index)" = "33a716cd7d8627fae3892c2eede9249e50d2d79aedfb43ca28dad9a2b23876d9" "checksum cortex-m-rt-macros 0.1.7 (registry+https://github.com/rust-lang/crates.io-index)" = "72b1073338d1e691b3b7aaf6bd61993e589ececce9242a02dfa5453e1b98918d" "checksum cortex-m-semihosting 0.3.5 (registry+https://github.com/rust-lang/crates.io-index)" = "113ef0ecffee2b62b58f9380f4469099b30e9f9cbee2804771b4203ba1762cfa" "checksum generic-array 0.12.3 (registry+https://github.com/rust-lang/crates.io-index)" = "c68f0274ae0e023facc3c97b2e00f076be70e254bc851d972503b328db79b2ec" "checksum generic-array 0.13.2 (registry+https://github.com/rust-lang/crates.io-index)" = "0ed1e761351b56f54eb9dcd0cfaca9fd0daecf93918e1cfc01c8a3d26ee7adcd" "checksum panic-halt 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "de96540e0ebde571dc55c73d60ef407c653844e6f9a1e2fdbd40c07b9252d812" "checksum proc-macro2 1.0.8 (registry+https://github.com/rust-lang/crates.io-index)" = "3acb317c6ff86a4e579dfa00fc5e6cca91ecbb4e7eb2df0468805b674eb88548" "checksum quote 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)" = "053a8c8bcc71fcce321828dc897a98ab9760bef03a4fc36693c231e5b3216cfe" "checksum r0 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)" = "e2a38df5b15c8d5c7e8654189744d8e396bddc18ad48041a500ce52d6948941f" "checksum rustc_version 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)" = "138e3e0acb6c9fb258b19b67cb8abd63c00679d2851805ea151465464fe9030a" "checksum semver 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)" = "1d7eb9ef2c18661902cc47e535f9bc51b78acd254da71d375c2f6720d9a40403" "checksum semver-parser 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)" = "388a1df253eca08550bef6c72392cfe7c30914bf41df5269b68cbd6ff8f570a3" "checksum stable_deref_trait 1.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "dba1a27d3efae4351c8051072d619e3ade2820635c3958d826bfea39d59b54c8" "checksum syn 1.0.14 (registry+https://github.com/rust-lang/crates.io-index)" = "af6f3550d8dff9ef7dc34d384ac6f107e5d31c8f57d9f28e0081503f547ac8f5" "checksum typenum 1.11.2 (registry+https://github.com/rust-lang/crates.io-index)" = "6d2783fe2d6b8c1101136184eb41be8b1ad379e4657050b8aaff0c79ee7575f9" "checksum unicode-xid 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "826e7639553986605ec5979c7dd957c7895e93eabed50ab2ffa7f6128a75097c" "checksum vcell 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "876e32dcadfe563a4289e994f7cb391197f362b6315dc45e8ba4aa6f564a4b3c" "checksum volatile-register 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "0d67cb4616d99b940db1d6bd28844ff97108b498a6ca850e5b6191a532063286" </ins>


Question:
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.

edition = "2018" [dependencies] <del> cortex-m = "0.5.4" cortex-m-rt = "=0.5.4" </del> <ins> cortex-m = "0.6.2" cortex-m-rt = "0.6.11" </ins> panic-halt = "0.2.0" cortex-m-semihosting = "0.3.1"


Question:
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.

<del> // #![feature(stdsimd)] </del> #![no_main] #![no_std] use core::fmt::Write;


Question:
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.

use cortex_m_rt::entry; use cortex_m_semihosting as semihosting; <del> //FIXME: This imports the provided #[panic_handler]. #[allow(rust_2018_idioms)] extern crate panic_halt; entry!(main); </del> <ins> use panic_halt as _; #[entry] </ins> fn main() -> ! { let x = 42;


Question:
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.

// Check timestamps. let mut inputs = inputs.clone(); <del> inputs.add_path(&testpaths.file); </del> <ins> // Use `add_dir` to account for run-make tests, which use their individual directory inputs.add_dir(&testpaths.file); </ins> for aux in &props.aux { let path = testpaths.file.parent().unwrap().join("auxiliary").join(aux);


Question:
Code: <details<summaryBacktrace</summary</details
modify labels: I-ICE C-Bug T-compiler A-mir Regression from 1.34 to 1.35
Additionally, this one ICEs with different error message: () <details<summaryBacktrace</summary</details
This code should not get all the way to codegen without an error
Another, different ICE? <details<summaryBacktrace</summary</summary
Regression somewhere between ...
looks suspicious, cc In particular, maybe is falsly returning here since the expected type is due to the other match arms?

} // Error possibly reported in `check_assign` so avoid emitting error again. <del> err.emit_unless(expression.filter(|e| fcx.is_assign_to_bool(e, expected)) .is_some()); </del> <ins> let assign_to_bool = expression // #67273: Use initial expected type as opposed to `expected`. // Otherwise we end up using prior coercions in e.g. a `match` expression: // ``` // match i { //     0 => true, // Because of this... //     1 => i = 1, // ...`expected == bool` now, but not when checking `i = 1`. //     _ => (), // }; // ``` .filter(|e| fcx.is_assign_to_bool(e, self.expected_ty())) .is_some(); err.emit_unless(assign_to_bool); </ins> self.final_ty = Some(fcx.tcx.types.err); }