-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-macrosArea: All kinds of macros (custom derive, macro_rules!, proc macros, ..)Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)C-bugCategory: This is a bug.Category: This is a bug.E-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.Call for participation: An issue has been fixed and does not reproduce, but no test has been added.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.Performance or correctness regression from one stable version to another.
Milestone
Description
I tried this code:
#[derive(Debug)]
pub struct Foo<T>(pub T);
impl<T> Access for T {}
pub trait Access {
fn field<N, T, Name: 'static>(&self) -> &T {
todo!()
}
fn field_mut<N, T, Name: 'static>(&mut self) -> &mut T {
todo!()
}
fn take_field<N, T, Name>(self) {
todo!()
}
}
I expected it to compile, but it doesn't because the Debug
macro expands to something like foo.field("field_name", &value)
, which incorrectly resolves to Access::field
instead of DebugTuple::field
(which is an inherent method).
error message
error[E0061]: this function takes 0 arguments but 1 argument was supplied
--> src/lib.rs:1:10
|
1 | #[derive(Debug)]
| ^^^^^ expected 0 arguments
2 | pub struct Foo<T>(pub T);
| ----- supplied 1 argument
|
note: associated function defined here
--> src/lib.rs:6:8
|
6 | fn field<N, T, Name: 'static>(&self) -> &T {
| ^^^^^ -----
= note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0277]: the size for values of type `Self` cannot be known at compilation time
--> src/lib.rs:14:31
|
14 | fn take_field<N, T, Name>(self) {
| ^^^^ doesn't have a size known at compile-time
|
= help: unsized fn params are gated as an unstable feature
help: consider further restricting `Self`
|
14 | fn take_field<N, T, Name>(self) where Self: Sized {
| ^^^^^^^^^^^^^^^^^
help: function arguments must have a statically known size, borrowed types always have a known size
|
14 | fn take_field<N, T, Name>(&self) {
| ^
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0061, E0277.
For more information about an error, try `rustc --explain E0061`.
error: could not compile `playground`
To learn more, run the command again with --verbose.
Metadata
Metadata
Assignees
Labels
A-macrosArea: All kinds of macros (custom derive, macro_rules!, proc macros, ..)Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)C-bugCategory: This is a bug.Category: This is a bug.E-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.Call for participation: An issue has been fixed and does not reproduce, but no test has been added.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.Performance or correctness regression from one stable version to another.
Type
Projects
Relationships
Development
Select code repository
Activity
master
isn't compiling RustyYato/generic-field-projection#51SNCPlay42 commentedon Jan 20, 2021
This works on stable and beta (as in, it compiles without error if you add a
: Sized
supertrait toAccess
) , but not on nightly.@rustbot label regression-from-stable-to-nightly
SNCPlay42 commentedon Jan 20, 2021
searched nightlies: from nightly-2020-12-25 to nightly-2021-01-20
regressed nightly: nightly-2021-01-18
searched commits: from 8a65184 to 4253153
regressed commit: edeb631
bisected with cargo-bisect-rustc v0.6.0
Host triple: x86_64-unknown-linux-gnu
Reproduce with:
SNCPlay42 commentedon Jan 20, 2021
I think part of the problem is that
f.field(...)
looks for methods on&DebugTuple
and sees the<DebugTuple as Access>::field(&self)
before it looks for methods on&mut DebugTuple
and findsDebugTuple::field(&mut self, ...)
. This issue with autoref/autoderef interacting poorly with inherent method's precedence over trait methods has cropped up before, e.g. in #39232 (where the compiler finds<T as BorrowMut>::borrow_mut(self)
before trying autoref and findingRefCell::borrow_mut(&self)
). But I don't have an explanation for why this started being a problem recently.On another note, I notice that
#[derive(Debug)]
appears to be the only built-in derive that ever uses.
method calls instead of UFCS with fully qualified paths, is there a reason for that? This issue could be fixed by changing#[derive(Debug)]
to not use.
calls, but I'm concerned that the root cause might have broken something else.SNCPlay42 commentedon Jan 20, 2021
Looking at the rollup that this regressed in, #80765 seems like it might be the cause.
cc @petrochenkov
petrochenkov commentedon Jan 20, 2021
Minimized:
derive(Debug)
should certainly use UFCS instead of method calls, regardless of #80765.If #80765 causes other issues we'll find out sooner or later, in theory it shouldn't change any behavior unless macros 2.0 (which are unstable) or built-in macros (which we can fix) are involved.
petrochenkov commentedon Jan 20, 2021
(I'll leave the fix itself to someone else, unassigning myself.)
29 remaining items
Auto merge of rust-lang#81294 - pnkfelix:issue-81211-use-ufcs-in-deri…
Mark-Simulacrum commentedon Mar 19, 2021
No one ended up triaging this crater run, but I think the only possible additional breakage is in hlist - https://crater-reports.s3.amazonaws.com/pr-81211/master%23edeb631ad0cd6fdf31e2e31ec90e105d1768be28/reg/typsy-0.1.0/log.txt - and I'd guess the fix would be similar there. Ultimately this is 'just' a form of inference breakage in some sense, so I think it's OK to let this slip. It seems to affect only 2 crates in the crater run, so breakage is very minor.
jackh726 commentedon Feb 3, 2022
This is fixed on current nightly. Removing priority and marking as E-needs-test.
pnkfelix commentedon Nov 23, 2022
I actually added tests, I think, in #81294. Namely:
From reviewing the comment thread here, I know there were lots of various concerns noted, and ideas for enhancements to the language documentation (I've filed rust-lang/reference#1308 for the latter). But I think the issue described here is resolved and has corresponding tests.