Question:
The feature gate for the issue is . When constructing a value using the word "default" is repeated twice. See for additional details, including alternative solutions. <!-- Include each step required to complete the feature. Typically, this is a PR implementing a feature, followed by a PR that stabilizes the feature. However for larger features an implementation could be broken up into multiple PRs. --- [X] Implement the RFC: [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [ ] Update examples in the documentation that currently use to use where it makes sense. [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilized. --- Should the language allow direct import of trait methods, this feature becomes redundant. This addition is likely to be stabilized only when we decide that direct import of trait methods is will not be supported. <!-- Include a list of all the PRs that were involved in implementing the feature. --
modify labels to +F-defaultfreefn
You call out in the description here - but why aren't or good alternatives? They work today, if the Default trait is in scope, and it is in the prelude.
is convenient when the compiler can not infer the type. But when it can, because redundant. Here is a discussion where this was mentioned as well:
FWIW I think it is often still good style to say to communicate to the human reader the type being constructed away, which can be declared very far away in the code (even in a different file).
I do no think this change takes away that and in certain cases you have to say . The change allows you to say in cases where you are currently saying .
happens a lot in struct displays, with being as redundant as .
A bit late to the party, but why not just a in the prelude instead ? That's less code to inline for the optimizer.
I am not sure I understand exactly what are you suggesting. But if the motivation described in the issues summary is not enough, please, read the discussion in
Is there a reason why this new free function isn't in the prelude when the feature is used?
Any additions to the prelude need to go through their own RFC. The bar is quite high, to say the least.
What's the status of this feature? I've found that The Book should be updated (Appendix C - Derivable Traits) but not really sure how to proceed.
One thing that I think is worth calling out is that this is putting a free function inside the module. So in order to avoid the stutter complaint of using , it sounds like you'd have to add a somewhere in order to use . So that stutter is still there in some sense and you have to write an import for it. Granted, this gets rid of the stutter at the call site. I also want to bring up the alternative. In particular, while it of course is not a replacement to avoid the stutter in all cases, I do think it is generally better to use in lieu of either a free function or . So to me, this on its own reduces the incidence of having to write a stuttering call, and thus also reduces the importance of adding things to std that allow one to avoid the stutter. As a more general point, to be honest, I'm not a huge fan of dumping aliases to things into std. I think it invites questions like, "Wait, what's the difference between the free function and ?" And it kind of just becomes another thing that folks need to learn, and another thing where some code will undoubtedly be using and other code will just be using the free function, which are expressed as two different things in std's API. More generally, do we have other aliases like this in std already? I know we have things like and , but we've deprecated the former. I wonder if it makes more sense to talk about "let's add aliases to std" as a more general policy question. In , wrote: To be honest, this seems infrequent enough where it might be reasonable to just define an internal helper function.
Isn't the plan to have in the prelude ?
I'm not aware of that plan. Could you please link to it?
You're right my bad. It was just a reminiscence of .
We discussed this in today's meeting. The general sentiment was: We'd like to make sure that can work even in const contexts. Ping what's the status of being able to say, for a free function like , that it's if and only if there's a const impl of ? We'd like to know if that'd be possible, even if it's nightly-only. And if it is, we'd like to use that for . Assuming that's possible, those of us in the meeting were generally in favor of having , and adding it to the prelude.
it's possible and already works (not yet in bootstrap libcore though): But we are not yet confident in whether we can safely (in the stability sense) stabilize a function that uses this feature without also stabilizing something of that feature at the same time.
Are we working on the assumption that something like won't be available in the future? Or is it more that we're okay with the potential for a little duplication down the road?
If one day it becomes possible to a trait method, then I think we'd still want to export the free function , we'd just turn it into a . So I don't see any reason we should wait for that. That looks great. It'd be helpful to know if we could stabilize a function using and without first stabilizing those two features themselves, but even if that's not the case, the confirmation that this can work is good enough for me to think we should stabilize this. I'm starting an FCP to get consensus on providing the free function , and exporting it from the prelude. (This consensus does not mean we have to stabilize it immediately; we can work with const-eval to figure out if it's possible to export something based on and , or if we need to wait for those features. For now, I'd just like to confirm consensus for the general plan of providing the function and the prelude re-export.) merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [ ] [x] [ ] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Oh sure, I just wanted to make sure that this was desired even in that situation. Personally I'm :+1: regardless.
This is still fairly early in the experimental stage, so I don't think we should stabilize anything using it just yet.
The primary blocker from our meeting was whether it would be possible, not necessarily doing so right away.
I think my general lean is in line with comment and comment . I'm hesitant to add alternative ways to invoke the same functionality without strong justification, and I don't believe that "reducing visual noise" is a sufficiently strong justification in this case. Also, given indicating that it would likely be easy to add support for to the language and the fact that as far as I can tell we've not ruled that out, other than that nobody has attempted it, I would prefer seeing an attempt to implement support for importing trait methods in general to stabizing this API.
since its been a month and a half and we're still only at 2/6 in favor of merging, I'm going to go ahead and close the FCP, though I will not be starting a new FCP to close the tracking issue because I still think we should work to resolve this issue through trait method imports or at least rule that out as a possibility. cancel
proposal cancelled.
Related discussion on Internals (some people here are proposing a lint to recommend over , to clear up some confusion related to the functional update syntax, which would make an anti-pattern right out of the gate):
Bevy 0.7 introduced a similar function in their own prelude: , bevyengine/bevy.
Just wanted to say that I very much enjoy using bevy's function. It's fairly common in struct initialisation, so it does make a tangible difference to the enjoyment of rust have such a shorthand.
There are tons of other traits that contains a single method, for example . Do we want to create free functions for all the traits?
No, just this one. It's more readable than .. Default::default()
I have included in my utils. You can write: and get correct type suggestions on the fly. I like this style personally.
There is really no need for this extra function, just simply add to the prelude
Trait methods can't be imported directly
This came up with Bevy uses of a free function: The lint : "function cannot return without recursing" is not raised by using Does not raise a warning: Raises a warning: This is
There is one thing that I noticed: When I initialize a struct I often start with and then jump to the definition of (using rust-analyzer) to see what the defaults are and to decide which fields I want to change. That's possible with and , but that's not possible with the free function (e.g. the one from bevy, it just jumps to definition inside the bevy crate). That's very unfortunate because from a visual perspective I would prefer .
That’s ok, IDEs will get smarter. It’s not a reason to not do it. On Fri, 23 Jun 2023 at 19:12, Jakob Schikowski
We discussed this in the libs-api meeting today. We would prefer to see a language feature to import the method directly. The language team seems to be open to this, but someone needs to write up a language proposal and drive the design of this feature. Since we are unlikely to stabilize the function as-is, we would like to remove it from the standard library. fcp close
Team member has proposed to close this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
I am not familiar with the removal process, but if it is just another issue with, essentially, a revert of the original change, I can do that. Though, if someone happens to have a link to an example, I would appreciate it. Was the consensus to remove it now, or after support for importing trait methods is to the language? If someone wants to mentor me in writing a language proposal, I could probably do that as well. As I have not participated in the language processes in the past, it is not very likely I would manage it by myself.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to close, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
So, the feature has been removed in favor of a language change, but without actually formally proposing the language change? Disappointing.
TL;DR
maybe we can have a language feature (alias) specifically for when creating structs with to support which expands to . This makes sense because the language already has this syntax is places such as pattern matching
has there been any followup RFC/tracking issue for an eventual syntax?
For what it's worth, is an open issue on this, maybe we could have some discussion there to move things forward.

fn default() -> Self; } <del> /// Return the default value of a type according to the `Default` trait. /// /// The type to return is inferred from context; this is equivalent to /// `Default::default()` but shorter to type. /// /// For example: /// ``` /// #![feature(default_free_fn)] /// /// use std::default::default; /// /// #[derive(Default)] /// struct AppConfig { ///     foo: FooConfig, ///     bar: BarConfig, /// } /// /// #[derive(Default)] /// struct FooConfig { ///     foo: i32, /// } /// /// #[derive(Default)] /// struct BarConfig { ///     bar: f32, ///     baz: u8, /// } /// /// fn main() { ///     let options = AppConfig { ///         foo: default(), ///         bar: BarConfig { ///             bar: 10.1, ///             ..default() ///         }, ///     }; /// } /// ``` #[unstable(feature = "default_free_fn", issue = "73014")] #[must_use] #[inline] pub fn default<T: Default>() -> T { Default::default() } </del> /// Derive macro generating an impl of the trait `Default`. #[rustc_builtin_macro(Default, attributes(default))] #[stable(feature = "builtin_macro_prelude", since = "1.38.0")]


Question:
The feature gate for the issue is . When constructing a value using the word "default" is repeated twice. See for additional details, including alternative solutions. <!-- Include each step required to complete the feature. Typically, this is a PR implementing a feature, followed by a PR that stabilizes the feature. However for larger features an implementation could be broken up into multiple PRs. --- [X] Implement the RFC: [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [ ] Update examples in the documentation that currently use to use where it makes sense. [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilized. --- Should the language allow direct import of trait methods, this feature becomes redundant. This addition is likely to be stabilized only when we decide that direct import of trait methods is will not be supported. <!-- Include a list of all the PRs that were involved in implementing the feature. --
modify labels to +F-defaultfreefn
You call out in the description here - but why aren't or good alternatives? They work today, if the Default trait is in scope, and it is in the prelude.
is convenient when the compiler can not infer the type. But when it can, because redundant. Here is a discussion where this was mentioned as well:
FWIW I think it is often still good style to say to communicate to the human reader the type being constructed away, which can be declared very far away in the code (even in a different file).
I do no think this change takes away that and in certain cases you have to say . The change allows you to say in cases where you are currently saying .
happens a lot in struct displays, with being as redundant as .
A bit late to the party, but why not just a in the prelude instead ? That's less code to inline for the optimizer.
I am not sure I understand exactly what are you suggesting. But if the motivation described in the issues summary is not enough, please, read the discussion in
Is there a reason why this new free function isn't in the prelude when the feature is used?
Any additions to the prelude need to go through their own RFC. The bar is quite high, to say the least.
What's the status of this feature? I've found that The Book should be updated (Appendix C - Derivable Traits) but not really sure how to proceed.
One thing that I think is worth calling out is that this is putting a free function inside the module. So in order to avoid the stutter complaint of using , it sounds like you'd have to add a somewhere in order to use . So that stutter is still there in some sense and you have to write an import for it. Granted, this gets rid of the stutter at the call site. I also want to bring up the alternative. In particular, while it of course is not a replacement to avoid the stutter in all cases, I do think it is generally better to use in lieu of either a free function or . So to me, this on its own reduces the incidence of having to write a stuttering call, and thus also reduces the importance of adding things to std that allow one to avoid the stutter. As a more general point, to be honest, I'm not a huge fan of dumping aliases to things into std. I think it invites questions like, "Wait, what's the difference between the free function and ?" And it kind of just becomes another thing that folks need to learn, and another thing where some code will undoubtedly be using and other code will just be using the free function, which are expressed as two different things in std's API. More generally, do we have other aliases like this in std already? I know we have things like and , but we've deprecated the former. I wonder if it makes more sense to talk about "let's add aliases to std" as a more general policy question. In , wrote: To be honest, this seems infrequent enough where it might be reasonable to just define an internal helper function.
Isn't the plan to have in the prelude ?
I'm not aware of that plan. Could you please link to it?
You're right my bad. It was just a reminiscence of .
We discussed this in today's meeting. The general sentiment was: We'd like to make sure that can work even in const contexts. Ping what's the status of being able to say, for a free function like , that it's if and only if there's a const impl of ? We'd like to know if that'd be possible, even if it's nightly-only. And if it is, we'd like to use that for . Assuming that's possible, those of us in the meeting were generally in favor of having , and adding it to the prelude.
it's possible and already works (not yet in bootstrap libcore though): But we are not yet confident in whether we can safely (in the stability sense) stabilize a function that uses this feature without also stabilizing something of that feature at the same time.
Are we working on the assumption that something like won't be available in the future? Or is it more that we're okay with the potential for a little duplication down the road?
If one day it becomes possible to a trait method, then I think we'd still want to export the free function , we'd just turn it into a . So I don't see any reason we should wait for that. That looks great. It'd be helpful to know if we could stabilize a function using and without first stabilizing those two features themselves, but even if that's not the case, the confirmation that this can work is good enough for me to think we should stabilize this. I'm starting an FCP to get consensus on providing the free function , and exporting it from the prelude. (This consensus does not mean we have to stabilize it immediately; we can work with const-eval to figure out if it's possible to export something based on and , or if we need to wait for those features. For now, I'd just like to confirm consensus for the general plan of providing the function and the prelude re-export.) merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [ ] [x] [ ] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Oh sure, I just wanted to make sure that this was desired even in that situation. Personally I'm :+1: regardless.
This is still fairly early in the experimental stage, so I don't think we should stabilize anything using it just yet.
The primary blocker from our meeting was whether it would be possible, not necessarily doing so right away.
I think my general lean is in line with comment and comment . I'm hesitant to add alternative ways to invoke the same functionality without strong justification, and I don't believe that "reducing visual noise" is a sufficiently strong justification in this case. Also, given indicating that it would likely be easy to add support for to the language and the fact that as far as I can tell we've not ruled that out, other than that nobody has attempted it, I would prefer seeing an attempt to implement support for importing trait methods in general to stabizing this API.
since its been a month and a half and we're still only at 2/6 in favor of merging, I'm going to go ahead and close the FCP, though I will not be starting a new FCP to close the tracking issue because I still think we should work to resolve this issue through trait method imports or at least rule that out as a possibility. cancel
proposal cancelled.
Related discussion on Internals (some people here are proposing a lint to recommend over , to clear up some confusion related to the functional update syntax, which would make an anti-pattern right out of the gate):
Bevy 0.7 introduced a similar function in their own prelude: , bevyengine/bevy.
Just wanted to say that I very much enjoy using bevy's function. It's fairly common in struct initialisation, so it does make a tangible difference to the enjoyment of rust have such a shorthand.
There are tons of other traits that contains a single method, for example . Do we want to create free functions for all the traits?
No, just this one. It's more readable than .. Default::default()
I have included in my utils. You can write: and get correct type suggestions on the fly. I like this style personally.
There is really no need for this extra function, just simply add to the prelude
Trait methods can't be imported directly
This came up with Bevy uses of a free function: The lint : "function cannot return without recursing" is not raised by using Does not raise a warning: Raises a warning: This is
There is one thing that I noticed: When I initialize a struct I often start with and then jump to the definition of (using rust-analyzer) to see what the defaults are and to decide which fields I want to change. That's possible with and , but that's not possible with the free function (e.g. the one from bevy, it just jumps to definition inside the bevy crate). That's very unfortunate because from a visual perspective I would prefer .
That’s ok, IDEs will get smarter. It’s not a reason to not do it. On Fri, 23 Jun 2023 at 19:12, Jakob Schikowski
We discussed this in the libs-api meeting today. We would prefer to see a language feature to import the method directly. The language team seems to be open to this, but someone needs to write up a language proposal and drive the design of this feature. Since we are unlikely to stabilize the function as-is, we would like to remove it from the standard library. fcp close
Team member has proposed to close this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
I am not familiar with the removal process, but if it is just another issue with, essentially, a revert of the original change, I can do that. Though, if someone happens to have a link to an example, I would appreciate it. Was the consensus to remove it now, or after support for importing trait methods is to the language? If someone wants to mentor me in writing a language proposal, I could probably do that as well. As I have not participated in the language processes in the past, it is not very likely I would manage it by myself.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to close, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
So, the feature has been removed in favor of a language change, but without actually formally proposing the language change? Disappointing.
TL;DR
maybe we can have a language feature (alias) specifically for when creating structs with to support which expands to . This makes sense because the language already has this syntax is places such as pattern matching
has there been any followup RFC/tracking issue for an eventual syntax?
For what it's worth, is an open issue on this, maybe we could have some discussion there to move things forward.

<del> # `default_free_fn` The tracking issue for this feature is: [#73014] [#73014]: https://github.com/rust-lang/rust/issues/73014 ------------------------ Adds a free `default()` function to the `std::default` module.  This function just forwards to [`Default::default()`], but may remove repetition of the word "default" from the call site. [`Default::default()`]: ../../std/default/trait.Default.html#tymethod.default Here is an example: ```rust #![feature(default_free_fn)] use std::default::default; #[derive(Default)] struct AppConfig { foo: FooConfig, bar: BarConfig, } #[derive(Default)] struct FooConfig { foo: i32, } #[derive(Default)] struct BarConfig { bar: f32, baz: u8, } fn main() { let options = AppConfig { foo: default(), bar: BarConfig { bar: 10.1, ..default() }, }; } ``` </del>


Question:
The feature gate for the issue is . When constructing a value using the word "default" is repeated twice. See for additional details, including alternative solutions. <!-- Include each step required to complete the feature. Typically, this is a PR implementing a feature, followed by a PR that stabilizes the feature. However for larger features an implementation could be broken up into multiple PRs. --- [X] Implement the RFC: [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [ ] Update examples in the documentation that currently use to use where it makes sense. [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilized. --- Should the language allow direct import of trait methods, this feature becomes redundant. This addition is likely to be stabilized only when we decide that direct import of trait methods is will not be supported. <!-- Include a list of all the PRs that were involved in implementing the feature. --
modify labels to +F-defaultfreefn
You call out in the description here - but why aren't or good alternatives? They work today, if the Default trait is in scope, and it is in the prelude.
is convenient when the compiler can not infer the type. But when it can, because redundant. Here is a discussion where this was mentioned as well:
FWIW I think it is often still good style to say to communicate to the human reader the type being constructed away, which can be declared very far away in the code (even in a different file).
I do no think this change takes away that and in certain cases you have to say . The change allows you to say in cases where you are currently saying .
happens a lot in struct displays, with being as redundant as .
A bit late to the party, but why not just a in the prelude instead ? That's less code to inline for the optimizer.
I am not sure I understand exactly what are you suggesting. But if the motivation described in the issues summary is not enough, please, read the discussion in
Is there a reason why this new free function isn't in the prelude when the feature is used?
Any additions to the prelude need to go through their own RFC. The bar is quite high, to say the least.
What's the status of this feature? I've found that The Book should be updated (Appendix C - Derivable Traits) but not really sure how to proceed.
One thing that I think is worth calling out is that this is putting a free function inside the module. So in order to avoid the stutter complaint of using , it sounds like you'd have to add a somewhere in order to use . So that stutter is still there in some sense and you have to write an import for it. Granted, this gets rid of the stutter at the call site. I also want to bring up the alternative. In particular, while it of course is not a replacement to avoid the stutter in all cases, I do think it is generally better to use in lieu of either a free function or . So to me, this on its own reduces the incidence of having to write a stuttering call, and thus also reduces the importance of adding things to std that allow one to avoid the stutter. As a more general point, to be honest, I'm not a huge fan of dumping aliases to things into std. I think it invites questions like, "Wait, what's the difference between the free function and ?" And it kind of just becomes another thing that folks need to learn, and another thing where some code will undoubtedly be using and other code will just be using the free function, which are expressed as two different things in std's API. More generally, do we have other aliases like this in std already? I know we have things like and , but we've deprecated the former. I wonder if it makes more sense to talk about "let's add aliases to std" as a more general policy question. In , wrote: To be honest, this seems infrequent enough where it might be reasonable to just define an internal helper function.
Isn't the plan to have in the prelude ?
I'm not aware of that plan. Could you please link to it?
You're right my bad. It was just a reminiscence of .
We discussed this in today's meeting. The general sentiment was: We'd like to make sure that can work even in const contexts. Ping what's the status of being able to say, for a free function like , that it's if and only if there's a const impl of ? We'd like to know if that'd be possible, even if it's nightly-only. And if it is, we'd like to use that for . Assuming that's possible, those of us in the meeting were generally in favor of having , and adding it to the prelude.
it's possible and already works (not yet in bootstrap libcore though): But we are not yet confident in whether we can safely (in the stability sense) stabilize a function that uses this feature without also stabilizing something of that feature at the same time.
Are we working on the assumption that something like won't be available in the future? Or is it more that we're okay with the potential for a little duplication down the road?
If one day it becomes possible to a trait method, then I think we'd still want to export the free function , we'd just turn it into a . So I don't see any reason we should wait for that. That looks great. It'd be helpful to know if we could stabilize a function using and without first stabilizing those two features themselves, but even if that's not the case, the confirmation that this can work is good enough for me to think we should stabilize this. I'm starting an FCP to get consensus on providing the free function , and exporting it from the prelude. (This consensus does not mean we have to stabilize it immediately; we can work with const-eval to figure out if it's possible to export something based on and , or if we need to wait for those features. For now, I'd just like to confirm consensus for the general plan of providing the function and the prelude re-export.) merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [ ] [x] [ ] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Oh sure, I just wanted to make sure that this was desired even in that situation. Personally I'm :+1: regardless.
This is still fairly early in the experimental stage, so I don't think we should stabilize anything using it just yet.
The primary blocker from our meeting was whether it would be possible, not necessarily doing so right away.
I think my general lean is in line with comment and comment . I'm hesitant to add alternative ways to invoke the same functionality without strong justification, and I don't believe that "reducing visual noise" is a sufficiently strong justification in this case. Also, given indicating that it would likely be easy to add support for to the language and the fact that as far as I can tell we've not ruled that out, other than that nobody has attempted it, I would prefer seeing an attempt to implement support for importing trait methods in general to stabizing this API.
since its been a month and a half and we're still only at 2/6 in favor of merging, I'm going to go ahead and close the FCP, though I will not be starting a new FCP to close the tracking issue because I still think we should work to resolve this issue through trait method imports or at least rule that out as a possibility. cancel
proposal cancelled.
Related discussion on Internals (some people here are proposing a lint to recommend over , to clear up some confusion related to the functional update syntax, which would make an anti-pattern right out of the gate):
Bevy 0.7 introduced a similar function in their own prelude: , bevyengine/bevy.
Just wanted to say that I very much enjoy using bevy's function. It's fairly common in struct initialisation, so it does make a tangible difference to the enjoyment of rust have such a shorthand.
There are tons of other traits that contains a single method, for example . Do we want to create free functions for all the traits?
No, just this one. It's more readable than .. Default::default()
I have included in my utils. You can write: and get correct type suggestions on the fly. I like this style personally.
There is really no need for this extra function, just simply add to the prelude
Trait methods can't be imported directly
This came up with Bevy uses of a free function: The lint : "function cannot return without recursing" is not raised by using Does not raise a warning: Raises a warning: This is
There is one thing that I noticed: When I initialize a struct I often start with and then jump to the definition of (using rust-analyzer) to see what the defaults are and to decide which fields I want to change. That's possible with and , but that's not possible with the free function (e.g. the one from bevy, it just jumps to definition inside the bevy crate). That's very unfortunate because from a visual perspective I would prefer .
That’s ok, IDEs will get smarter. It’s not a reason to not do it. On Fri, 23 Jun 2023 at 19:12, Jakob Schikowski
We discussed this in the libs-api meeting today. We would prefer to see a language feature to import the method directly. The language team seems to be open to this, but someone needs to write up a language proposal and drive the design of this feature. Since we are unlikely to stabilize the function as-is, we would like to remove it from the standard library. fcp close
Team member has proposed to close this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
I am not familiar with the removal process, but if it is just another issue with, essentially, a revert of the original change, I can do that. Though, if someone happens to have a link to an example, I would appreciate it. Was the consensus to remove it now, or after support for importing trait methods is to the language? If someone wants to mentor me in writing a language proposal, I could probably do that as well. As I have not participated in the language processes in the past, it is not very likely I would manage it by myself.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to close, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
So, the feature has been removed in favor of a language change, but without actually formally proposing the language change? Disappointing.
TL;DR
maybe we can have a language feature (alias) specifically for when creating structs with to support which expands to . This makes sense because the language already has this syntax is places such as pattern matching
has there been any followup RFC/tracking issue for an eventual syntax?
For what it's worth, is an open issue on this, maybe we could have some discussion there to move things forward.

<del> error[E0425]: cannot find function `default` in this scope --> $DIR/issue-2356.rs:31:5 | LL |     default(); |     ^^^^^^^ | help: you might have meant to call the associated function | LL |     Self::default(); |     ~~~~~~~~~~~~~ help: consider importing this function | LL + use std::default::default; | </del> error[E0425]: cannot find value `whiskers` in this scope --> $DIR/issue-2356.rs:39:5 |


Question:
The feature gate for the issue is . When constructing a value using the word "default" is repeated twice. See for additional details, including alternative solutions. <!-- Include each step required to complete the feature. Typically, this is a PR implementing a feature, followed by a PR that stabilizes the feature. However for larger features an implementation could be broken up into multiple PRs. --- [X] Implement the RFC: [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [ ] Update examples in the documentation that currently use to use where it makes sense. [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilized. --- Should the language allow direct import of trait methods, this feature becomes redundant. This addition is likely to be stabilized only when we decide that direct import of trait methods is will not be supported. <!-- Include a list of all the PRs that were involved in implementing the feature. --
modify labels to +F-defaultfreefn
You call out in the description here - but why aren't or good alternatives? They work today, if the Default trait is in scope, and it is in the prelude.
is convenient when the compiler can not infer the type. But when it can, because redundant. Here is a discussion where this was mentioned as well:
FWIW I think it is often still good style to say to communicate to the human reader the type being constructed away, which can be declared very far away in the code (even in a different file).
I do no think this change takes away that and in certain cases you have to say . The change allows you to say in cases where you are currently saying .
happens a lot in struct displays, with being as redundant as .
A bit late to the party, but why not just a in the prelude instead ? That's less code to inline for the optimizer.
I am not sure I understand exactly what are you suggesting. But if the motivation described in the issues summary is not enough, please, read the discussion in
Is there a reason why this new free function isn't in the prelude when the feature is used?
Any additions to the prelude need to go through their own RFC. The bar is quite high, to say the least.
What's the status of this feature? I've found that The Book should be updated (Appendix C - Derivable Traits) but not really sure how to proceed.
One thing that I think is worth calling out is that this is putting a free function inside the module. So in order to avoid the stutter complaint of using , it sounds like you'd have to add a somewhere in order to use . So that stutter is still there in some sense and you have to write an import for it. Granted, this gets rid of the stutter at the call site. I also want to bring up the alternative. In particular, while it of course is not a replacement to avoid the stutter in all cases, I do think it is generally better to use in lieu of either a free function or . So to me, this on its own reduces the incidence of having to write a stuttering call, and thus also reduces the importance of adding things to std that allow one to avoid the stutter. As a more general point, to be honest, I'm not a huge fan of dumping aliases to things into std. I think it invites questions like, "Wait, what's the difference between the free function and ?" And it kind of just becomes another thing that folks need to learn, and another thing where some code will undoubtedly be using and other code will just be using the free function, which are expressed as two different things in std's API. More generally, do we have other aliases like this in std already? I know we have things like and , but we've deprecated the former. I wonder if it makes more sense to talk about "let's add aliases to std" as a more general policy question. In , wrote: To be honest, this seems infrequent enough where it might be reasonable to just define an internal helper function.
Isn't the plan to have in the prelude ?
I'm not aware of that plan. Could you please link to it?
You're right my bad. It was just a reminiscence of .
We discussed this in today's meeting. The general sentiment was: We'd like to make sure that can work even in const contexts. Ping what's the status of being able to say, for a free function like , that it's if and only if there's a const impl of ? We'd like to know if that'd be possible, even if it's nightly-only. And if it is, we'd like to use that for . Assuming that's possible, those of us in the meeting were generally in favor of having , and adding it to the prelude.
it's possible and already works (not yet in bootstrap libcore though): But we are not yet confident in whether we can safely (in the stability sense) stabilize a function that uses this feature without also stabilizing something of that feature at the same time.
Are we working on the assumption that something like won't be available in the future? Or is it more that we're okay with the potential for a little duplication down the road?
If one day it becomes possible to a trait method, then I think we'd still want to export the free function , we'd just turn it into a . So I don't see any reason we should wait for that. That looks great. It'd be helpful to know if we could stabilize a function using and without first stabilizing those two features themselves, but even if that's not the case, the confirmation that this can work is good enough for me to think we should stabilize this. I'm starting an FCP to get consensus on providing the free function , and exporting it from the prelude. (This consensus does not mean we have to stabilize it immediately; we can work with const-eval to figure out if it's possible to export something based on and , or if we need to wait for those features. For now, I'd just like to confirm consensus for the general plan of providing the function and the prelude re-export.) merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [ ] [x] [ ] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Oh sure, I just wanted to make sure that this was desired even in that situation. Personally I'm :+1: regardless.
This is still fairly early in the experimental stage, so I don't think we should stabilize anything using it just yet.
The primary blocker from our meeting was whether it would be possible, not necessarily doing so right away.
I think my general lean is in line with comment and comment . I'm hesitant to add alternative ways to invoke the same functionality without strong justification, and I don't believe that "reducing visual noise" is a sufficiently strong justification in this case. Also, given indicating that it would likely be easy to add support for to the language and the fact that as far as I can tell we've not ruled that out, other than that nobody has attempted it, I would prefer seeing an attempt to implement support for importing trait methods in general to stabizing this API.
since its been a month and a half and we're still only at 2/6 in favor of merging, I'm going to go ahead and close the FCP, though I will not be starting a new FCP to close the tracking issue because I still think we should work to resolve this issue through trait method imports or at least rule that out as a possibility. cancel
proposal cancelled.
Related discussion on Internals (some people here are proposing a lint to recommend over , to clear up some confusion related to the functional update syntax, which would make an anti-pattern right out of the gate):
Bevy 0.7 introduced a similar function in their own prelude: , bevyengine/bevy.
Just wanted to say that I very much enjoy using bevy's function. It's fairly common in struct initialisation, so it does make a tangible difference to the enjoyment of rust have such a shorthand.
There are tons of other traits that contains a single method, for example . Do we want to create free functions for all the traits?
No, just this one. It's more readable than .. Default::default()
I have included in my utils. You can write: and get correct type suggestions on the fly. I like this style personally.
There is really no need for this extra function, just simply add to the prelude
Trait methods can't be imported directly
This came up with Bevy uses of a free function: The lint : "function cannot return without recursing" is not raised by using Does not raise a warning: Raises a warning: This is
There is one thing that I noticed: When I initialize a struct I often start with and then jump to the definition of (using rust-analyzer) to see what the defaults are and to decide which fields I want to change. That's possible with and , but that's not possible with the free function (e.g. the one from bevy, it just jumps to definition inside the bevy crate). That's very unfortunate because from a visual perspective I would prefer .
That’s ok, IDEs will get smarter. It’s not a reason to not do it. On Fri, 23 Jun 2023 at 19:12, Jakob Schikowski
We discussed this in the libs-api meeting today. We would prefer to see a language feature to import the method directly. The language team seems to be open to this, but someone needs to write up a language proposal and drive the design of this feature. Since we are unlikely to stabilize the function as-is, we would like to remove it from the standard library. fcp close
Team member has proposed to close this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
I am not familiar with the removal process, but if it is just another issue with, essentially, a revert of the original change, I can do that. Though, if someone happens to have a link to an example, I would appreciate it. Was the consensus to remove it now, or after support for importing trait methods is to the language? If someone wants to mentor me in writing a language proposal, I could probably do that as well. As I have not participated in the language processes in the past, it is not very likely I would manage it by myself.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to close, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
So, the feature has been removed in favor of a language change, but without actually formally proposing the language change? Disappointing.
TL;DR
maybe we can have a language feature (alias) specifically for when creating structs with to support which expands to . This makes sense because the language already has this syntax is places such as pattern matching
has there been any followup RFC/tracking issue for an eventual syntax?
For what it's worth, is an open issue on this, maybe we could have some discussion there to move things forward.

LL |     clone(); |     ^^^^^ help: you might have meant to call the method: `self.clone` <ins> error[E0425]: cannot find function `default` in this scope --> $DIR/issue-2356.rs:31:5 | LL |     default(); |     ^^^^^^^ help: you might have meant to call the associated function: `Self::default` </ins> error[E0425]: cannot find function `shave` in this scope --> $DIR/issue-2356.rs:41:5 |


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --reduced from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --repo @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Its a regression from but fortunately the fix is relatively easy. I'll provide a PR soon,

// As write_sub_paths, but does not process the last ident in the path (assuming it // will be processed elsewhere). See note on write_sub_paths about global. fn write_sub_paths_truncated(&mut self, path: &'tcx hir::Path<'tcx>) { <del> for seg in &path.segments[..path.segments.len() - 1] { if let Some(data) = self.save_ctxt.get_path_segment_data(seg) { self.dumper.dump_ref(data); </del> <ins> if let [segments @ .., _] = path.segments { for seg in segments { if let Some(data) = self.save_ctxt.get_path_segment_data(seg) { self.dumper.dump_ref(data); } </ins> } } }


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --reduced from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --repo @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Its a regression from but fortunately the fix is relatively easy. I'll provide a PR soon,

} } } <del> hir::ExprKind::Struct(hir::QPath::Resolved(_, path), ..) => { </del> <ins> hir::ExprKind::Struct(qpath, ..) => { let segment = match qpath { hir::QPath::Resolved(_, path) => path.segments.last().unwrap(), hir::QPath::TypeRelative(_, segment) => segment, }; </ins> match self.tables.expr_ty_adjusted(&hir_node).kind { ty::Adt(def, _) if !def.is_enum() => { <del> let sub_span = path.segments.last().unwrap().ident.span; </del> <ins> let sub_span = segment.ident.span; </ins> filter!(self.span_utils, sub_span); let span = self.span_from_span(sub_span); Some(Data::RefData(Ref {


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --reduced from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --repo @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Its a regression from but fortunately the fix is relatively easy. I'll provide a PR soon,

} _ => { // FIXME <del> bug!(); </del> <ins> bug!("invalid expression: {:?}", expr); </ins> } } }


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --reduced from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --repo @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Its a regression from but fortunately the fix is relatively easy. I'll provide a PR soon,

<ins> // compile-flags: -Zsave-analysis use {self}; //~ ERROR E0431 fn main () { } </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --reduced from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --repo @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Its a regression from but fortunately the fix is relatively easy. I'll provide a PR soon,

<ins> error[E0431]: `self` import can only appear in an import list with a non-empty prefix --> $DIR/issue-73020.rs:2:6 | LL | use {self}; |      ^^^^ can only appear in an import list with a non-empty prefix error: aborting due to previous error For more information about this error, try `rustc --explain E0431`. </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --reduced from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --repo @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Its a regression from but fortunately the fix is relatively easy. I'll provide a PR soon,

<ins> // build-pass // compile-flags: -Zsave-analysis enum Enum2 { Variant8 { _field: bool }, } impl Enum2 { fn new_variant8() -> Enum2 { Self::Variant8 { _field: true } } } fn main() {} </ins>


Question:
I was writing some code that does some x86 page table configuration, but then I noticed that Rust compiler started to panic with this code: And I did realize that I cannot use in since has attribute. If I rewrite the above code without crate: (Note that this is basically same thing as 's struct) This compiler error is displayed, which is normal: And here's output from (In this case, I'm trying to compile the first code): Looking at the backtrace, there's function and : While there's no line number(since the compiler is installed using ), thankfully there are only two calls to inside . And it seems like the first one is panicking since normal output has nothing more than , but I might be wrong. I ran about five minutes ago before submitting this issue, but result was the same. BTW: I initially found this bug in Clippy, but then I noticed that Rustc was doing the same thing.
Assigning [as discussed as part of the Prioritization WG procedure][link]. [link]: https://rust-(in.20some.20cases).20when.20repr(al
Would you please try this again for us?
The second one is one that does not panic rustc(The code that panics rustc is the first one). It is very similar to the first one except that it does not use external crate, and compiling it shows the error I was expecting. Also, the second code was one of my attempts to reproduce the same panic without external crate, but for some reason, it didn't panic the compiler. Only the first code does.

use rustc_hir::lang_items::{ FutureTraitLangItem, PinTypeLangItem, SizedTraitLangItem, VaListTypeLangItem, }; <del> use rustc_hir::{ExprKind, GenericArg, HirIdMap, Item, ItemKind, Node, PatKind, QPath}; </del> <ins> use rustc_hir::{ExprKind, GenericArg, HirIdMap, ItemKind, Node, PatKind, QPath}; </ins> use rustc_index::bit_set::BitSet; use rustc_index::vec::Idx; use rustc_infer::infer;


Question:
I was writing some code that does some x86 page table configuration, but then I noticed that Rust compiler started to panic with this code: And I did realize that I cannot use in since has attribute. If I rewrite the above code without crate: (Note that this is basically same thing as 's struct) This compiler error is displayed, which is normal: And here's output from (In this case, I'm trying to compile the first code): Looking at the backtrace, there's function and : While there's no line number(since the compiler is installed using ), thankfully there are only two calls to inside . And it seems like the first one is panicking since normal output has nothing more than , but I might be wrong. I ran about five minutes ago before submitting this issue, but result was the same. BTW: I initially found this bug in Clippy, but then I noticed that Rustc was doing the same thing.
Assigning [as discussed as part of the Prioritization WG procedure][link]. [link]: https://rust-(in.20some.20cases).20when.20repr(al
Would you please try this again for us?
The second one is one that does not panic rustc(The code that panics rustc is the first one). It is very similar to the first one except that it does not use external crate, and compiling it shows the error I was expecting. Also, the second code was one of my attempts to reproduce the same panic without external crate, but for some reason, it didn't panic the compiler. Only the first code does.

"packed type cannot transitively contain a `#[repr(align)]` type" ); <del> let hir = tcx.hir(); let hir_id = hir.as_local_hir_id(def_spans[0].0.expect_local()); if let Node::Item(Item { ident, .. }) = hir.get(hir_id) { err.span_note( tcx.def_span(def_spans[0].0), &format!("`{}` has a `#[repr(align)]` attribute", ident), ); } </del> <ins> err.span_note( tcx.def_span(def_spans[0].0), &format!( "`{}` has a `#[repr(align)]` attribute", tcx.item_name(def_spans[0].0) ), ); </ins> if def_spans.len() > 2 { let mut first = true; for (adt_def, span) in def_spans.iter().skip(1).rev() { <del> let hir_id = hir.as_local_hir_id(adt_def.expect_local()); if let Node::Item(Item { ident, .. }) = hir.get(hir_id) { err.span_note( *span, &if first { format!( "`{}` contains a field of type `{}`", tcx.type_of(def.did), ident ) } else { format!("...which contains a field of type `{}`", ident) }, ); first = false; } </del> <ins> let ident = tcx.item_name(*adt_def); err.span_note( *span, &if first { format!( "`{}` contains a field of type `{}`", tcx.type_of(def.did), ident ) } else { format!("...which contains a field of type `{}`", ident) }, ); first = false; </ins> } }


Question:
I was writing some code that does some x86 page table configuration, but then I noticed that Rust compiler started to panic with this code: And I did realize that I cannot use in since has attribute. If I rewrite the above code without crate: (Note that this is basically same thing as 's struct) This compiler error is displayed, which is normal: And here's output from (In this case, I'm trying to compile the first code): Looking at the backtrace, there's function and : While there's no line number(since the compiler is installed using ), thankfully there are only two calls to inside . And it seems like the first one is panicking since normal output has nothing more than , but I might be wrong. I ran about five minutes ago before submitting this issue, but result was the same. BTW: I initially found this bug in Clippy, but then I noticed that Rustc was doing the same thing.
Assigning [as discussed as part of the Prioritization WG procedure][link]. [link]: https://rust-(in.20some.20cases).20when.20repr(al
Would you please try this again for us?
The second one is one that does not panic rustc(The code that panics rustc is the first one). It is very similar to the first one except that it does not use external crate, and compiling it shows the error I was expecting. Also, the second code was one of my attempts to reproduce the same panic without external crate, but for some reason, it didn't panic the compiler. Only the first code does.

<ins> #[repr(transparent)] pub struct PageTableEntry { entry: u64, } #[repr(align(4096))] #[repr(C)] pub struct PageTable { entries: [PageTableEntry; 512], } </ins>


Question:
I was writing some code that does some x86 page table configuration, but then I noticed that Rust compiler started to panic with this code: And I did realize that I cannot use in since has attribute. If I rewrite the above code without crate: (Note that this is basically same thing as 's struct) This compiler error is displayed, which is normal: And here's output from (In this case, I'm trying to compile the first code): Looking at the backtrace, there's function and : While there's no line number(since the compiler is installed using ), thankfully there are only two calls to inside . And it seems like the first one is panicking since normal output has nothing more than , but I might be wrong. I ran about five minutes ago before submitting this issue, but result was the same. BTW: I initially found this bug in Clippy, but then I noticed that Rustc was doing the same thing.
Assigning [as discussed as part of the Prioritization WG procedure][link]. [link]: https://rust-(in.20some.20cases).20when.20repr(al
Would you please try this again for us?
The second one is one that does not panic rustc(The code that panics rustc is the first one). It is very similar to the first one except that it does not use external crate, and compiling it shows the error I was expecting. Also, the second code was one of my attempts to reproduce the same panic without external crate, but for some reason, it didn't panic the compiler. Only the first code does.

<ins> // aux-build:issue-73112.rs extern crate issue_73112; fn main() { use issue_73112::PageTable; #[repr(C, packed)] struct SomeStruct { //~^ ERROR packed type cannot transitively contain a `#[repr(align)]` type [E0588] page_table: PageTable, } } </ins>


Question:
I was writing some code that does some x86 page table configuration, but then I noticed that Rust compiler started to panic with this code: And I did realize that I cannot use in since has attribute. If I rewrite the above code without crate: (Note that this is basically same thing as 's struct) This compiler error is displayed, which is normal: And here's output from (In this case, I'm trying to compile the first code): Looking at the backtrace, there's function and : While there's no line number(since the compiler is installed using ), thankfully there are only two calls to inside . And it seems like the first one is panicking since normal output has nothing more than , but I might be wrong. I ran about five minutes ago before submitting this issue, but result was the same. BTW: I initially found this bug in Clippy, but then I noticed that Rustc was doing the same thing.
Assigning [as discussed as part of the Prioritization WG procedure][link]. [link]: https://rust-(in.20some.20cases).20when.20repr(al
Would you please try this again for us?
The second one is one that does not panic rustc(The code that panics rustc is the first one). It is very similar to the first one except that it does not use external crate, and compiling it shows the error I was expecting. Also, the second code was one of my attempts to reproduce the same panic without external crate, but for some reason, it didn't panic the compiler. Only the first code does.

<ins> error[E0588]: packed type cannot transitively contain a `#[repr(align)]` type --> $DIR/issue-73112.rs:9:5 | LL | /     struct SomeStruct { LL | | LL | |         page_table: PageTable, LL | |     } | |_____^ | note: `PageTable` has a `#[repr(align)]` attribute --> $DIR/auxiliary/issue-73112.rs:8:1 | LL | / pub struct PageTable { LL | |     entries: [PageTableEntry; 512], LL | | } | |_^ error: aborting due to previous error For more information about this error, try `rustc --explain E0588`. </ins>


Question:
We fail to parse this (admittedly questionable) code as of beta: This broke one repository (not crate) in the beta crater run: https://crater-
cc I personally suspect that we may want to ask T-lang if we're good accepting this as expected breakage. Alternatively I guess we can adjust the shebang detection to not require a non-empty shebang.
Assigning .
For reference, here's the code responsible for parsing shebang in Linux kernel - (Fully whitespace (including empty) line isn't considered a shebang.)
I am inclined to close as won't fix; let's cc as the author of that repository as well. I'm going to go ahead and nominate this so that we can get a :+1: (or not) at the T-compiler meeting confirming won't fix status.
I made a fix in , which also has a benefit of simplifying the rules slightly.
Thanks guys, was more of a spelling mistake/leftover from previous version than unclear explanation of how to use shebang with rust as your previous explanation on how to use it worked fine in something else I was playing around with. But thank you very much for letting me know. Sent with Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

/// but shebang isn't a part of rust syntax. pub fn strip_shebang(input: &str) -> Option<usize> { // Shebang must start with `#!` literally, without any preceding whitespace. <del> if input.starts_with("#!") { let input_tail = &input[2..]; // Shebang must have something non-whitespace after `#!` on the first line. let first_line_tail = input_tail.lines().next()?; if first_line_tail.contains(|c| !is_whitespace(c)) { // Ok, this is a shebang but if the next non-whitespace token is `[` or maybe // a doc comment (due to `TokenKind::(Line,Block)Comment` ambiguity at lexer level), // then it may be valid Rust code, so consider it Rust code. let next_non_whitespace_token = tokenize(input_tail).map(|tok| tok.kind).find(|tok| !matches!(tok, TokenKind::Whitespace | TokenKind::LineComment | TokenKind::BlockComment { .. }) ); if next_non_whitespace_token != Some(TokenKind::OpenBracket) { // No other choice than to consider this a shebang. return Some(2 + first_line_tail.len()); } </del> <ins> // For simplicity we consider any line starting with `#!` a shebang, // regardless of restrictions put on shebangs by specific platforms. if let Some(input_tail) = input.strip_prefix("#!") { // Ok, this is a shebang but if the next non-whitespace token is `[` or maybe // a doc comment (due to `TokenKind::(Line,Block)Comment` ambiguity at lexer level), // then it may be valid Rust code, so consider it Rust code. let next_non_whitespace_token = tokenize(input_tail).map(|tok| tok.kind).find(|tok| !matches!(tok, TokenKind::Whitespace | TokenKind::LineComment | TokenKind::BlockComment { .. }) ); if next_non_whitespace_token != Some(TokenKind::OpenBracket) { // No other choice than to consider this a shebang. return Some(2 + input_tail.lines().next().unwrap_or_default().len()); </ins> } } None


Question:
We fail to parse this (admittedly questionable) code as of beta: This broke one repository (not crate) in the beta crater run: https://crater-
cc I personally suspect that we may want to ask T-lang if we're good accepting this as expected breakage. Alternatively I guess we can adjust the shebang detection to not require a non-empty shebang.
Assigning .
For reference, here's the code responsible for parsing shebang in Linux kernel - (Fully whitespace (including empty) line isn't considered a shebang.)
I am inclined to close as won't fix; let's cc as the author of that repository as well. I'm going to go ahead and nominate this so that we can get a :+1: (or not) at the T-compiler meeting confirming won't fix status.
I made a fix in , which also has a benefit of simplifying the rules slightly.
Thanks guys, was more of a spelling mistake/leftover from previous version than unclear explanation of how to use shebang with rust as your previous explanation on how to use it worked fine in something else I was playing around with. But thank you very much for letting me know. Sent with Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

<ins> #! // check-pass fn main() {} </ins>


Question:
We fail to parse this (admittedly questionable) code as of beta: This broke one repository (not crate) in the beta crater run: https://crater-
cc I personally suspect that we may want to ask T-lang if we're good accepting this as expected breakage. Alternatively I guess we can adjust the shebang detection to not require a non-empty shebang.
Assigning .
For reference, here's the code responsible for parsing shebang in Linux kernel - (Fully whitespace (including empty) line isn't considered a shebang.)
I am inclined to close as won't fix; let's cc as the author of that repository as well. I'm going to go ahead and nominate this so that we can get a :+1: (or not) at the T-compiler meeting confirming won't fix status.
I made a fix in , which also has a benefit of simplifying the rules slightly.
Thanks guys, was more of a spelling mistake/leftover from previous version than unclear explanation of how to use shebang with rust as your previous explanation on how to use it worked fine in something else I was playing around with. But thank you very much for letting me know. Sent with Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

<ins> #! // check-pass // ignore-tidy-end-whitespace fn main() {} </ins>


Question:
We fail to parse this (admittedly questionable) code as of beta: This broke one repository (not crate) in the beta crater run: https://crater-
cc I personally suspect that we may want to ask T-lang if we're good accepting this as expected breakage. Alternatively I guess we can adjust the shebang detection to not require a non-empty shebang.
Assigning .
For reference, here's the code responsible for parsing shebang in Linux kernel - (Fully whitespace (including empty) line isn't considered a shebang.)
I am inclined to close as won't fix; let's cc as the author of that repository as well. I'm going to go ahead and nominate this so that we can get a :+1: (or not) at the T-compiler meeting confirming won't fix status.
I made a fix in , which also has a benefit of simplifying the rules slightly.
Thanks guys, was more of a spelling mistake/leftover from previous version than unclear explanation of how to use shebang with rust as your previous explanation on how to use it worked fine in something else I was playing around with. But thank you very much for letting me know. Sent with Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

<del> #!/usr/bin/env rustx // run-pass pub fn main() { println!("Hello World"); } </del>


Question:
Const generics and release mode and Hc128Rng::seedfromu64 and rustc 1.45.0-nightly ( 2020-05-29) or later cause cc linking error. To avoid the error, do any of: use rustc 1.45.0-nightly ( 2020-05-14) or earlier remove the remove the line compile in debug mode I'm guessing that Hc128Rng::seedfrom_u64 is not the only thing that will trigger this, but I have not been able to find any other examples.
I reduced it. works, but does not work. In both release and debug, it yields approximate the same error as before on: But compiles successfully on:
This fails with , but not .
This appears to be working now. I'll add a test.
and I were unable to reproduce an error with the examples here, but they still fail on extended CI (though not with the original error here). The PR is We'll have to revisit this one.
Note that on latest nightly, I am still encountering this issue. (Any time I use the crate and with , I trigger this.) Error:
Sorry to keep bumping. I continue to encounter this issue when I attempt to use with on latest nightly. <details<summaryCode</summary</details<details<summaryError</summary</details<details<summaryrustc --version --verbose</summary</details
Reliably reproduces for me using latest code. modify labels: -E-needs-mcve +E-needs-test
I encountered a different trigger for what I am guessing is the same underlying bug. Error message is ~identical. To work around, do one of: Have return an array instead of a . Replace with . rustc --version --verbose:
Different trigger. Allocating with causes an ICE, but simple works.
Manifest for installing rust and build-essentials on ubuntu 20.04.03 rustup self uninstall apt-get update sudo add-apt-repository "deb $(lsb_release -sc) main universe" apt-get -u dist-upgrade apt install aptitude sudo aptitude install libc6=2.31-0ubuntu9 sudo aptitude install build-essential apt-get update curl --proto '=https' --tlsv1.2 -sSf | sh -s -- --default-toolchain none -y rustup toolchain install nightly --allow-downgrade --profile minimal --component clippy rustup default stable rustup update nightly rustup update stable rustup target add wasm32-unknown-unknown --toolchain nightly sudo apt install -y cmake pkg-config libssl-dev git gcc build-essential clang libclang-dev rustc --version source $ [][1] #ArmanRiazi.Blockchain [1]:
still causes a linker error but passes with symbol mangling: I assume we end up mangling an unevaluated constant somewhere with ?

debug!("QueryNormalizer: result = {:#?}", result); debug!("QueryNormalizer: obligations = {:#?}", obligations); self.obligations.extend(obligations); <del> Ok(result.normalized_ty) </del> <ins> let res = result.normalized_ty; // `tcx.normalize_projection_ty` may normalize to a type that still has // unevaluated consts, so keep normalizing here if that's the case. if res != ty && res.has_type_flags(ty::TypeFlags::HAS_CT_PROJECTION) { Ok(res.try_super_fold_with(self)?) } else { Ok(res) } </ins> } ty::Projection(data) => {


Question:
Const generics and release mode and Hc128Rng::seedfromu64 and rustc 1.45.0-nightly ( 2020-05-29) or later cause cc linking error. To avoid the error, do any of: use rustc 1.45.0-nightly ( 2020-05-14) or earlier remove the remove the line compile in debug mode I'm guessing that Hc128Rng::seedfrom_u64 is not the only thing that will trigger this, but I have not been able to find any other examples.
I reduced it. works, but does not work. In both release and debug, it yields approximate the same error as before on: But compiles successfully on:
This fails with , but not .
This appears to be working now. I'll add a test.
and I were unable to reproduce an error with the examples here, but they still fail on extended CI (though not with the original error here). The PR is We'll have to revisit this one.
Note that on latest nightly, I am still encountering this issue. (Any time I use the crate and with , I trigger this.) Error:
Sorry to keep bumping. I continue to encounter this issue when I attempt to use with on latest nightly. <details<summaryCode</summary</details<details<summaryError</summary</details<details<summaryrustc --version --verbose</summary</details
Reliably reproduces for me using latest code. modify labels: -E-needs-mcve +E-needs-test
I encountered a different trigger for what I am guessing is the same underlying bug. Error message is ~identical. To work around, do one of: Have return an array instead of a . Replace with . rustc --version --verbose:
Different trigger. Allocating with causes an ICE, but simple works.
Manifest for installing rust and build-essentials on ubuntu 20.04.03 rustup self uninstall apt-get update sudo add-apt-repository "deb $(lsb_release -sc) main universe" apt-get -u dist-upgrade apt install aptitude sudo aptitude install libc6=2.31-0ubuntu9 sudo aptitude install build-essential apt-get update curl --proto '=https' --tlsv1.2 -sSf | sh -s -- --default-toolchain none -y rustup toolchain install nightly --allow-downgrade --profile minimal --component clippy rustup default stable rustup update nightly rustup update stable rustup target add wasm32-unknown-unknown --toolchain nightly sudo apt install -y cmake pkg-config libssl-dev git gcc build-essential clang libclang-dev rustc --version source $ [][1] #ArmanRiazi.Blockchain [1]:
still causes a linker error but passes with symbol mangling: I assume we end up mangling an unevaluated constant somewhere with ?

debug!("QueryNormalizer: result = {:#?}", result); debug!("QueryNormalizer: obligations = {:#?}", obligations); self.obligations.extend(obligations); <del> Ok(crate::traits::project::PlaceholderReplacer::replace_placeholders( </del> <ins> let res = crate::traits::project::PlaceholderReplacer::replace_placeholders( </ins> infcx, mapped_regions, mapped_types, mapped_consts, &self.universes, result.normalized_ty, <del> )) </del> <ins> ); // `tcx.normalize_projection_ty` may normalize to a type that still has // unevaluated consts, so keep normalizing here if that's the case. if res != ty && res.has_type_flags(ty::TypeFlags::HAS_CT_PROJECTION) { Ok(res.try_super_fold_with(self)?) } else { Ok(res) } </ins> } _ => ty.try_super_fold_with(self), })()?; self.cache.insert(ty, res); Ok(res) }


Question:
Const generics and release mode and Hc128Rng::seedfromu64 and rustc 1.45.0-nightly ( 2020-05-29) or later cause cc linking error. To avoid the error, do any of: use rustc 1.45.0-nightly ( 2020-05-14) or earlier remove the remove the line compile in debug mode I'm guessing that Hc128Rng::seedfrom_u64 is not the only thing that will trigger this, but I have not been able to find any other examples.
I reduced it. works, but does not work. In both release and debug, it yields approximate the same error as before on: But compiles successfully on:
This fails with , but not .
This appears to be working now. I'll add a test.
and I were unable to reproduce an error with the examples here, but they still fail on extended CI (though not with the original error here). The PR is We'll have to revisit this one.
Note that on latest nightly, I am still encountering this issue. (Any time I use the crate and with , I trigger this.) Error:
Sorry to keep bumping. I continue to encounter this issue when I attempt to use with on latest nightly. <details<summaryCode</summary</details<details<summaryError</summary</details<details<summaryrustc --version --verbose</summary</details
Reliably reproduces for me using latest code. modify labels: -E-needs-mcve +E-needs-test
I encountered a different trigger for what I am guessing is the same underlying bug. Error message is ~identical. To work around, do one of: Have return an array instead of a . Replace with . rustc --version --verbose:
Different trigger. Allocating with causes an ICE, but simple works.
Manifest for installing rust and build-essentials on ubuntu 20.04.03 rustup self uninstall apt-get update sudo add-apt-repository "deb $(lsb_release -sc) main universe" apt-get -u dist-upgrade apt install aptitude sudo aptitude install libc6=2.31-0ubuntu9 sudo aptitude install build-essential apt-get update curl --proto '=https' --tlsv1.2 -sSf | sh -s -- --default-toolchain none -y rustup toolchain install nightly --allow-downgrade --profile minimal --component clippy rustup default stable rustup update nightly rustup update stable rustup target add wasm32-unknown-unknown --toolchain nightly sudo apt install -y cmake pkg-config libssl-dev git gcc build-essential clang libclang-dev rustc --version source $ [][1] #ArmanRiazi.Blockchain [1]:
still causes a linker error but passes with symbol mangling: I assume we end up mangling an unevaluated constant somewhere with ?

<ins> // build-pass #![allow(incomplete_features)] #![feature(generic_const_exprs)] trait TraitOne { const MY_NUM: usize; type MyErr: std::fmt::Debug; fn do_one_stuff(arr: [u8; Self::MY_NUM]) -> Result<(), Self::MyErr>; } trait TraitTwo { fn do_two_stuff(); } impl<O: TraitOne> TraitTwo for O where [(); Self::MY_NUM]:, { fn do_two_stuff() { O::do_one_stuff([5; Self::MY_NUM]).unwrap() } } struct Blargotron; #[derive(Debug)] struct ErrTy<const N: usize>([(); N]); impl TraitOne for Blargotron { const MY_NUM: usize = 3; type MyErr = ErrTy<{ Self::MY_NUM }>; fn do_one_stuff(_arr: [u8; Self::MY_NUM]) -> Result<(), Self::MyErr> { Ok(()) } } fn main() { Blargotron::do_two_stuff(); } </ins>


Question:
Const generics and release mode and Hc128Rng::seedfromu64 and rustc 1.45.0-nightly ( 2020-05-29) or later cause cc linking error. To avoid the error, do any of: use rustc 1.45.0-nightly ( 2020-05-14) or earlier remove the remove the line compile in debug mode I'm guessing that Hc128Rng::seedfrom_u64 is not the only thing that will trigger this, but I have not been able to find any other examples.
I reduced it. works, but does not work. In both release and debug, it yields approximate the same error as before on: But compiles successfully on:
This fails with , but not .
This appears to be working now. I'll add a test.
and I were unable to reproduce an error with the examples here, but they still fail on extended CI (though not with the original error here). The PR is We'll have to revisit this one.
Note that on latest nightly, I am still encountering this issue. (Any time I use the crate and with , I trigger this.) Error:
Sorry to keep bumping. I continue to encounter this issue when I attempt to use with on latest nightly. <details<summaryCode</summary</details<details<summaryError</summary</details<details<summaryrustc --version --verbose</summary</details
Reliably reproduces for me using latest code. modify labels: -E-needs-mcve +E-needs-test
I encountered a different trigger for what I am guessing is the same underlying bug. Error message is ~identical. To work around, do one of: Have return an array instead of a . Replace with . rustc --version --verbose:
Different trigger. Allocating with causes an ICE, but simple works.
Manifest for installing rust and build-essentials on ubuntu 20.04.03 rustup self uninstall apt-get update sudo add-apt-repository "deb $(lsb_release -sc) main universe" apt-get -u dist-upgrade apt install aptitude sudo aptitude install libc6=2.31-0ubuntu9 sudo aptitude install build-essential apt-get update curl --proto '=https' --tlsv1.2 -sSf | sh -s -- --default-toolchain none -y rustup toolchain install nightly --allow-downgrade --profile minimal --component clippy rustup default stable rustup update nightly rustup update stable rustup target add wasm32-unknown-unknown --toolchain nightly sudo apt install -y cmake pkg-config libssl-dev git gcc build-essential clang libclang-dev rustc --version source $ [][1] #ArmanRiazi.Blockchain [1]:
still causes a linker error but passes with symbol mangling: I assume we end up mangling an unevaluated constant somewhere with ?

<ins> // build-pass #![allow(incomplete_features)] #![feature(generic_const_exprs)] use std::convert::AsMut; use std::default::Default; trait Foo: Sized { type Baz: Default + AsMut<[u8]>; fn bar() { Self::Baz::default().as_mut(); } } impl Foo for () { type Baz = [u8; 1 * 1]; //type Baz = [u8; 1]; } fn main() { <() as Foo>::bar(); } </ins>


Question:
Const generics and release mode and Hc128Rng::seedfromu64 and rustc 1.45.0-nightly ( 2020-05-29) or later cause cc linking error. To avoid the error, do any of: use rustc 1.45.0-nightly ( 2020-05-14) or earlier remove the remove the line compile in debug mode I'm guessing that Hc128Rng::seedfrom_u64 is not the only thing that will trigger this, but I have not been able to find any other examples.
I reduced it. works, but does not work. In both release and debug, it yields approximate the same error as before on: But compiles successfully on:
This fails with , but not .
This appears to be working now. I'll add a test.
and I were unable to reproduce an error with the examples here, but they still fail on extended CI (though not with the original error here). The PR is We'll have to revisit this one.
Note that on latest nightly, I am still encountering this issue. (Any time I use the crate and with , I trigger this.) Error:
Sorry to keep bumping. I continue to encounter this issue when I attempt to use with on latest nightly. <details<summaryCode</summary</details<details<summaryError</summary</details<details<summaryrustc --version --verbose</summary</details
Reliably reproduces for me using latest code. modify labels: -E-needs-mcve +E-needs-test
I encountered a different trigger for what I am guessing is the same underlying bug. Error message is ~identical. To work around, do one of: Have return an array instead of a . Replace with . rustc --version --verbose:
Different trigger. Allocating with causes an ICE, but simple works.
Manifest for installing rust and build-essentials on ubuntu 20.04.03 rustup self uninstall apt-get update sudo add-apt-repository "deb $(lsb_release -sc) main universe" apt-get -u dist-upgrade apt install aptitude sudo aptitude install libc6=2.31-0ubuntu9 sudo aptitude install build-essential apt-get update curl --proto '=https' --tlsv1.2 -sSf | sh -s -- --default-toolchain none -y rustup toolchain install nightly --allow-downgrade --profile minimal --component clippy rustup default stable rustup update nightly rustup update stable rustup target add wasm32-unknown-unknown --toolchain nightly sudo apt install -y cmake pkg-config libssl-dev git gcc build-essential clang libclang-dev rustc --version source $ [][1] #ArmanRiazi.Blockchain [1]:
still causes a linker error but passes with symbol mangling: I assume we end up mangling an unevaluated constant somewhere with ?

<ins> // build-pass #![allow(incomplete_features)] #![feature(generic_const_exprs)] trait Collate<Op> { type Pass; type Fail; fn collate(self) -> (Self::Pass, Self::Fail); } impl<Op> Collate<Op> for () { type Pass = (); type Fail = (); fn collate(self) -> ((), ()) { ((), ()) } } trait CollateStep<X, Prev> { type Pass; type Fail; fn collate_step(x: X, prev: Prev) -> (Self::Pass, Self::Fail); } impl<X, P, F> CollateStep<X, (P, F)> for () { type Pass = (X, P); type Fail = F; fn collate_step(x: X, (p, f): (P, F)) -> ((X, P), F) { ((x, p), f) } } struct CollateOpImpl<const MASK: u32>; trait CollateOpStep { type NextOp; type Apply; } impl<const MASK: u32> CollateOpStep for CollateOpImpl<MASK> where CollateOpImpl<{ MASK >> 1 }>: Sized, { type NextOp = CollateOpImpl<{ MASK >> 1 }>; type Apply = (); } impl<H, T, Op: CollateOpStep> Collate<Op> for (H, T) where T: Collate<Op::NextOp>, Op::Apply: CollateStep<H, (T::Pass, T::Fail)>, { type Pass = <Op::Apply as CollateStep<H, (T::Pass, T::Fail)>>::Pass; type Fail = <Op::Apply as CollateStep<H, (T::Pass, T::Fail)>>::Fail; fn collate(self) -> (Self::Pass, Self::Fail) { <Op::Apply as CollateStep<H, (T::Pass, T::Fail)>>::collate_step(self.0, self.1.collate()) } } fn collate<X, const MASK: u32>(x: X) -> (X::Pass, X::Fail) where X: Collate<CollateOpImpl<MASK>>, { x.collate() } fn main() { dbg!(collate::<_, 5>(("Hello", (42, ('!', ()))))); } </ins>


Question:
Const generics and release mode and Hc128Rng::seedfromu64 and rustc 1.45.0-nightly ( 2020-05-29) or later cause cc linking error. To avoid the error, do any of: use rustc 1.45.0-nightly ( 2020-05-14) or earlier remove the remove the line compile in debug mode I'm guessing that Hc128Rng::seedfrom_u64 is not the only thing that will trigger this, but I have not been able to find any other examples.
I reduced it. works, but does not work. In both release and debug, it yields approximate the same error as before on: But compiles successfully on:
This fails with , but not .
This appears to be working now. I'll add a test.
and I were unable to reproduce an error with the examples here, but they still fail on extended CI (though not with the original error here). The PR is We'll have to revisit this one.
Note that on latest nightly, I am still encountering this issue. (Any time I use the crate and with , I trigger this.) Error:
Sorry to keep bumping. I continue to encounter this issue when I attempt to use with on latest nightly. <details<summaryCode</summary</details<details<summaryError</summary</details<details<summaryrustc --version --verbose</summary</details
Reliably reproduces for me using latest code. modify labels: -E-needs-mcve +E-needs-test
I encountered a different trigger for what I am guessing is the same underlying bug. Error message is ~identical. To work around, do one of: Have return an array instead of a . Replace with . rustc --version --verbose:
Different trigger. Allocating with causes an ICE, but simple works.
Manifest for installing rust and build-essentials on ubuntu 20.04.03 rustup self uninstall apt-get update sudo add-apt-repository "deb $(lsb_release -sc) main universe" apt-get -u dist-upgrade apt install aptitude sudo aptitude install libc6=2.31-0ubuntu9 sudo aptitude install build-essential apt-get update curl --proto '=https' --tlsv1.2 -sSf | sh -s -- --default-toolchain none -y rustup toolchain install nightly --allow-downgrade --profile minimal --component clippy rustup default stable rustup update nightly rustup update stable rustup target add wasm32-unknown-unknown --toolchain nightly sudo apt install -y cmake pkg-config libssl-dev git gcc build-essential clang libclang-dev rustc --version source $ [][1] #ArmanRiazi.Blockchain [1]:
still causes a linker error but passes with symbol mangling: I assume we end up mangling an unevaluated constant somewhere with ?

<ins> // build-pass #![allow(incomplete_features)] #![feature(generic_const_exprs)] pub trait Foo { fn foo(&self); } pub struct FooImpl<const N: usize>; impl<const N: usize> Foo for FooImpl<N> { fn foo(&self) {} } pub trait Bar: 'static { type Foo: Foo; fn get() -> &'static Self::Foo; } struct BarImpl; impl Bar for BarImpl { type Foo = FooImpl< { { 4 } }, >; fn get() -> &'static Self::Foo { &FooImpl } } pub fn boom<B: Bar>() { B::get().foo(); } fn main() { boom::<BarImpl>(); } </ins>


Question:
Const generics and release mode and Hc128Rng::seedfromu64 and rustc 1.45.0-nightly ( 2020-05-29) or later cause cc linking error. To avoid the error, do any of: use rustc 1.45.0-nightly ( 2020-05-14) or earlier remove the remove the line compile in debug mode I'm guessing that Hc128Rng::seedfrom_u64 is not the only thing that will trigger this, but I have not been able to find any other examples.
I reduced it. works, but does not work. In both release and debug, it yields approximate the same error as before on: But compiles successfully on:
This fails with , but not .
This appears to be working now. I'll add a test.
and I were unable to reproduce an error with the examples here, but they still fail on extended CI (though not with the original error here). The PR is We'll have to revisit this one.
Note that on latest nightly, I am still encountering this issue. (Any time I use the crate and with , I trigger this.) Error:
Sorry to keep bumping. I continue to encounter this issue when I attempt to use with on latest nightly. <details<summaryCode</summary</details<details<summaryError</summary</details<details<summaryrustc --version --verbose</summary</details
Reliably reproduces for me using latest code. modify labels: -E-needs-mcve +E-needs-test
I encountered a different trigger for what I am guessing is the same underlying bug. Error message is ~identical. To work around, do one of: Have return an array instead of a . Replace with . rustc --version --verbose:
Different trigger. Allocating with causes an ICE, but simple works.
Manifest for installing rust and build-essentials on ubuntu 20.04.03 rustup self uninstall apt-get update sudo add-apt-repository "deb $(lsb_release -sc) main universe" apt-get -u dist-upgrade apt install aptitude sudo aptitude install libc6=2.31-0ubuntu9 sudo aptitude install build-essential apt-get update curl --proto '=https' --tlsv1.2 -sSf | sh -s -- --default-toolchain none -y rustup toolchain install nightly --allow-downgrade --profile minimal --component clippy rustup default stable rustup update nightly rustup update stable rustup target add wasm32-unknown-unknown --toolchain nightly sudo apt install -y cmake pkg-config libssl-dev git gcc build-essential clang libclang-dev rustc --version source $ [][1] #ArmanRiazi.Blockchain [1]:
still causes a linker error but passes with symbol mangling: I assume we end up mangling an unevaluated constant somewhere with ?

<ins> // build-pass #![feature(generic_const_exprs)] #![allow(incomplete_features)] trait Foo { type Output; fn foo() -> Self::Output; } impl Foo for [u8; 3] { type Output = [u8; 1 + 2]; fn foo() -> [u8; 3] { [1u8; 3] } } fn bug<const N: usize>() where [u8; N]: Foo, <[u8; N] as Foo>::Output: AsRef<[u8]>, { <[u8; N]>::foo().as_ref(); } fn main() { bug::<3>(); } </ins>


Question:
Const generics and release mode and Hc128Rng::seedfromu64 and rustc 1.45.0-nightly ( 2020-05-29) or later cause cc linking error. To avoid the error, do any of: use rustc 1.45.0-nightly ( 2020-05-14) or earlier remove the remove the line compile in debug mode I'm guessing that Hc128Rng::seedfrom_u64 is not the only thing that will trigger this, but I have not been able to find any other examples.
I reduced it. works, but does not work. In both release and debug, it yields approximate the same error as before on: But compiles successfully on:
This fails with , but not .
This appears to be working now. I'll add a test.
and I were unable to reproduce an error with the examples here, but they still fail on extended CI (though not with the original error here). The PR is We'll have to revisit this one.
Note that on latest nightly, I am still encountering this issue. (Any time I use the crate and with , I trigger this.) Error:
Sorry to keep bumping. I continue to encounter this issue when I attempt to use with on latest nightly. <details<summaryCode</summary</details<details<summaryError</summary</details<details<summaryrustc --version --verbose</summary</details
Reliably reproduces for me using latest code. modify labels: -E-needs-mcve +E-needs-test
I encountered a different trigger for what I am guessing is the same underlying bug. Error message is ~identical. To work around, do one of: Have return an array instead of a . Replace with . rustc --version --verbose:
Different trigger. Allocating with causes an ICE, but simple works.
Manifest for installing rust and build-essentials on ubuntu 20.04.03 rustup self uninstall apt-get update sudo add-apt-repository "deb $(lsb_release -sc) main universe" apt-get -u dist-upgrade apt install aptitude sudo aptitude install libc6=2.31-0ubuntu9 sudo aptitude install build-essential apt-get update curl --proto '=https' --tlsv1.2 -sSf | sh -s -- --default-toolchain none -y rustup toolchain install nightly --allow-downgrade --profile minimal --component clippy rustup default stable rustup update nightly rustup update stable rustup target add wasm32-unknown-unknown --toolchain nightly sudo apt install -y cmake pkg-config libssl-dev git gcc build-essential clang libclang-dev rustc --version source $ [][1] #ArmanRiazi.Blockchain [1]:
still causes a linker error but passes with symbol mangling: I assume we end up mangling an unevaluated constant somewhere with ?

<ins> // build-pass #![allow(incomplete_features)] #![feature(generic_const_exprs)] use std::marker::PhantomData; fn main() { let x = FooImpl::<BarImpl<1>> { phantom: PhantomData }; let _ = x.foo::<BarImpl<1>>(); } trait Foo<T> where T: Bar, { fn foo<U>(&self) where T: Operation<U>, <T as Operation<U>>::Output: Bar; } struct FooImpl<T> where T: Bar, { phantom: PhantomData<T>, } impl<T> Foo<T> for FooImpl<T> where T: Bar, { fn foo<U>(&self) where T: Operation<U>, <T as Operation<U>>::Output: Bar, { <<T as Operation<U>>::Output as Bar>::error_occurs_here(); } } trait Bar { fn error_occurs_here(); } struct BarImpl<const N: usize>; impl<const N: usize> Bar for BarImpl<N> { fn error_occurs_here() {} } trait Operation<Rhs> { type Output; } //// Part-A: This causes error. impl<const M: usize, const N: usize> Operation<BarImpl<M>> for BarImpl<N> where BarImpl<{ N + M }>: Sized, { type Output = BarImpl<{ N + M }>; } //// Part-B: This doesn't cause error. // impl<const M: usize, const N: usize> Operation<BarImpl<M>> for BarImpl<N> { //     type Output = BarImpl<M>; // } //// Part-C: This also doesn't cause error. // impl<const M: usize, const N: usize> Operation<BarImpl<M>> for BarImpl<N> { //     type Output = BarImpl<{ M }>; // } </ins>


Question: compiles fine. Constructing a literal doesn't work, listing two s gives , giving only one gives , with an empty list of missing fields.

generics: &Generics, fields: &[@struct_field], visitor: ResolveVisitor) { <ins> let mut ident_map = HashMap::new::<ast::ident, @struct_field>(); for fields.iter().advance |&field| { match field.node.kind { named_field(ident, _) => { match ident_map.find(&ident) { Some(&prev_field) => { let ident_str = self.session.str_of(ident); self.session.span_err(field.span, fmt!("field `%s` is already declared", ident_str)); self.session.span_note(prev_field.span, "Previously declared here"); }, None => { ident_map.insert(ident, field); } } } _ => () } } </ins> // If applicable, create a rib for the type parameters. do self.with_type_parameter_rib(HasTypeParameters (generics, id, 0,


Question: compiles fine. Constructing a literal doesn't work, listing two s gives , giving only one gives , with an empty list of missing fields.

<ins> // Copyright 2013 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. struct BuildData { foo: int, foo: int, //~ ERROR field `foo` is already declared } fn main() { } </ins>