delegation: do not always generate first argument (pt. 1) by aerooneqq · Pull Request #156798 · rust-lang/rust

aerooneqq · 2026-05-21T12:41:46Z

This PR supports not generating delegation's "dead code" - situation when there is no parameters in a source function or we expanded a reuse of a static function without self, in this case we do not have to generate delegation's block even if the user has explicitly specified it.

We generate block:

If there is a single delegation and source function has first param, otherwise error is emitted,
If there is a glob delegation we generate block if the source function has first param and it is method or free function.

Fixes #154427. Part of #118212.
r? @petrochenkov

aerooneqq · 2026-05-22T06:51:46Z

+struct F(S);
+// In glob delegations silently remove first arg if no params or generate default
+// first arg (`arg0`) if it is a static function.
+reuse impl Trait for F { self.0 }


Desugaring:

impl Trait for F { #[attr = Inline(Hint)] fn value(self: _) -> _ { self.0.value() } #[attr = Inline(Hint)] fn r#ref(self: _) -> _ { self.0.r#ref() } #[attr = Inline(Hint)] fn mut_ref(self: _) -> _ { self.0.mut_ref() } #[attr = Inline(Hint)] fn static_empty() -> _ { Trait::static_empty() } #[attr = Inline(Hint)] fn static_one_param(arg0: _) -> _ { Trait::static_one_param(arg0) } }

First arg transformation is not generated even if a static function has first param.

View changes since the review

aerooneqq · 2026-05-22T06:52:22Z

+struct F2(S);
+impl F2 {
+    // In list delegations silently remove first arg if it is not a method.
+    reuse <S as Trait>::{value, r#ref, mut_ref, static_empty, static_one_param} { self.0 }


Desugaring:

#[attr = Inline(Hint)] fn value(self: _) -> _ { <S as Trait>::value(self.0) } #[attr = Inline(Hint)] fn r#ref(self: _) -> _ { <S as Trait>::r#ref(self.0) } #[attr = Inline(Hint)] fn mut_ref(self: _) -> _ { <S as Trait>::mut_ref(self.0) } #[attr = Inline(Hint)] fn static_empty() -> _ { <S as Trait>::static_empty() } #[attr = Inline(Hint)] fn static_one_param(arg0: _) -> _ { <S as Trait>::static_one_param(arg0) }

First arg transformation is not generated even if a static function has first param.

View changes since the review

aerooneqq · 2026-05-22T06:52:48Z

+reuse to_reuse::one_param { self + 1 }
+
+// In list delegations silently remove first arg if there are no params.
+reuse to_reuse::{empty as empty1, one_param as one_param1} { self + 1 }


Desugaring:

// In list delegations silently remove first arg if there are no params. #[attr = Inline(Hint)] fn empty1() -> _ { to_reuse::empty() } #[attr = Inline(Hint)] fn one_param1(arg0: _) -> _ { to_reuse::one_param(self + 1) }

We generated first arg transformation as it is a free function.

View changes since the review

aerooneqq · 2026-05-22T07:16:56Z

+
+struct F3(S);
+impl Trait for F3 {
+    reuse trait_to_reuse::{value, r#ref, mut_ref, static_empty, static_one_param} { self.0 }


Desugaring:

#[attr = Inline(Hint)] fn value(self: _) -> _ { trait_to_reuse::value(self.0) } #[attr = Inline(Hint)] fn r#ref(self: _) -> _ { trait_to_reuse::r#ref(self.0) } #[attr = Inline(Hint)] fn mut_ref(self: _) -> _ { trait_to_reuse::mut_ref(self.0) } #[attr = Inline(Hint)] fn static_empty() -> _ { trait_to_reuse::static_empty() } #[attr = Inline(Hint)] fn static_one_param(arg0: _) -> _ { trait_to_reuse::static_one_param(arg0) } //~^ ERROR: mismatched types //~| ERROR: mismatched types

self resolves to F3.

View changes since the review

aerooneqq · 2026-05-22T07:18:58Z

+
+struct F4(S);
+impl F4 {
+    reuse trait_to_reuse::{value, r#ref, mut_ref, static_empty, static_one_param} { self.0 }


Desugaring:

#[attr = Inline(Hint)] fn value<impl Trait>(arg0: _) -> _ { trait_to_reuse::value(self.0) } #[attr = Inline(Hint)] fn r#ref<impl Trait>(arg0: _) -> _ { trait_to_reuse::r#ref(self.0) } #[attr = Inline(Hint)] fn mut_ref<impl Trait>(arg0: _) -> _ { trait_to_reuse::mut_ref(self.0) } #[attr = Inline(Hint)] fn static_empty() -> _ { trait_to_reuse::static_empty() } #[attr = Inline(Hint)] fn static_one_param(arg0: _) -> _ { trait_to_reuse::static_one_param(self.0) }

self resolves to first argument, as it is a plain impl and sig_id resolves to free functions not to a trait method in contrast to case with F3. We generated block for static_one_param as it is a free function, in F3 it is an associated function so we generate arg0.

View changes since the review

rustbot · 2026-05-22T07:22:47Z

The parser was modified, potentially altering the grammar of (stable) Rust
which would be a breaking change.

cc @fmease

petrochenkov · 2026-05-22T13:00:03Z

I think the solution for the dead code problem here brings much worse problems than the initial problem itself.

If the target expression is unused, we can generate something like

fn static_method() {
  let _ = target_expr;
  static_method()
}

instead of messing with the definition hierarchy.

@rustbot author

rustbot · 2026-05-22T13:00:09Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

petrochenkov · 2026-05-22T13:08:18Z

Ah, the question is what self in target_expr refers to, if there's no first parameter in the signature.
Let's keep it an error for now, we'll come up with something, anything is better than messing with the definition hierarchy.

petrochenkov · 2026-05-23T14:47:48Z

Ah, the question is what self in target_expr refers to, if there's no first parameter in the signature. Let's keep it an error for now, we'll come up with something, anything is better than messing with the definition hierarchy.

Although leaving e.g. self.field as dead code will be almost as harmful as passing it, 99% chance that it won't pass type checking.
I think need to discuss this in more detail on Monday before doing anything.

petrochenkov · 2026-05-27T09:51:46Z

I just realized that removing code here is a future compatibility hazard.
Consider this:

reuse {foo} { std::something_unstable() };

If std::something_unstable() is removed at AST lowering stage, then it will go through name resolution, but won't go through stability checking, and the code will compile.
If later the API is removed instead of being stabilized, then the code will stop compiling due to failing at name resolution stage.

petrochenkov · 2026-05-27T09:58:55Z

Also, removing or not removing the target expression depending on whether the delegation is a part of the list or not is probably not a good language design.

// now do two different things.
reuse foo;
reuse {foo};

I think we'll eventually need to remove the target expression either always, or always for associated functions.
But now we are in experimentation phase, so can try the single-or-not criterion too, it still goes into the right direction.

aerooneqq · 2026-06-03T08:44:19Z

I want to split this work into 4 parts:

The first one (this PR) - removal of target expression without defs inside, emitting errors if target expression is specified in case of a single delegation and if an attempt to delete target expression was made when there are definitions inside,
Emitting error if target expression is specified for glob delegation when all expanded delegations do not require target expression,
Same as (2) but apply it to list delegations (need to set ExpnId for expanded list delegations),
(Optional): create a universal engine which will allow deletion of target expressions with definitions inside, this will require significant infrastructural changes.

petrochenkov · 2026-06-03T11:05:43Z

I want to split this work into 4 parts:

The plan sounds good.

petrochenkov · 2026-06-03T11:25:00Z

            let expansion = self.parent_scope.expansion;
            self.r.define_local(parent, ident, ns, self.res(def_id), vis, item.span, expansion);
-        } else if !matches!(&item.kind, AssocItemKind::Delegation(deleg) if deleg.from_glob)
+        } else if !matches!(&item.kind, AssocItemKind::Delegation(d) if matches!(d.source, DelegationSource::Glob))


Suggested change

} else if !matches!(&item.kind, AssocItemKind::Delegation(d) if matches!(d.source, DelegationSource::Glob))

} else if let AssocItemKind::Delegation(d) = &item.kind && d.source == DelegationSource::Glob

View changes since the review

petrochenkov · 2026-06-03T11:26:38Z

    item: &'a ast::Item<Node::ItemKind>,
    suffixes: &'a [(Ident, Option<Ident>)],
    item_span: Span,
    from_glob: bool,


Suggested change

source: DelegationSource,

View changes since the review

petrochenkov · 2026-06-03T11:30:52Z

+            && self
+                .resolver
+                .delegation_info(self.owner.def_id)
+                .is_some_and(|i| i.block_contains_defs)


Would it possible to detect this post-factum, instead of tracking things in advance through def collector?
Like add a small AST visitor to visit delegation.body and check if there's anything with definitions?
This visitor would only run for delegations where performance is not much of a concern at the moment.
This would avoid polluting the general-purpose infra like def collector with delegation-specific concerns.

View changes since the review

petrochenkov · 2026-06-03T11:53:32Z

+
+        // Report an error if user has explicitly specified delegation's target expression
+        // in a single delegation when reused function has no params.
+        if param_count == 0 && matches!(delegation.source, DelegationSource::Single) {


Suggested change

if param_count == 0 && matches!(delegation.source, DelegationSource::Single) {

if param_count == 0 && should_generate_block {

Otherwise we are missing e.g. a free function with zero params in a list.

View changes since the review

petrochenkov · 2026-06-03T11:57:10Z

                let (param_count, c_variadic) = self.param_count(sig_id);

+                if !self.check_block_soundness(delegation, sig_id, is_method, param_count) {
+                    return self.generate_delegation_error(span, delegation);


Similarly to #157248 (comment) this is sub-optimal from error recovery / diagnostics point of view, but that's not a first concern right now.

View changes since the review

petrochenkov · 2026-06-03T11:58:36Z

Also let's merge #157248 and #157296 first.
@rustbot blocked

rustbot assigned petrochenkov May 21, 2026

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 21, 2026

aerooneqq force-pushed the delegation-dont-generate-first-arg branch 5 times, most recently from 303d29a to c400cb5 Compare May 22, 2026 06:49

aerooneqq commented May 22, 2026

View reviewed changes

Comment thread compiler/rustc_resolve/src/build_reduced_graph.rs Outdated

aerooneqq force-pushed the delegation-dont-generate-first-arg branch from c400cb5 to 3983a7b Compare May 22, 2026 07:15

aerooneqq commented May 22, 2026

View reviewed changes

aerooneqq marked this pull request as ready for review May 22, 2026 07:22

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 22, 2026

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label May 22, 2026

petrochenkov added the F-fn_delegation `#![feature(fn_delegation)]` label May 22, 2026

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 22, 2026

aerooneqq marked this pull request as draft May 25, 2026 11:13

petrochenkov mentioned this pull request May 27, 2026

definitions: remove DefPathTable, use LocalDefId instead of DefIndex #156963

Merged

aerooneqq force-pushed the delegation-dont-generate-first-arg branch from 5200e14 to ee1c893 Compare May 29, 2026 11:24

This comment has been minimized.

Sign in to view

aerooneqq added 6 commits June 2, 2026 10:32

Do not always generate first delegation argument

b12acb0

Check if the delegation itself is a dead code

474cf3a

from_glob_or_list -> DelegationSource

376032f

Simplifying delegation's block deletion logic

72bdcbb

Cleanups

f75e1e6

After-rebase fixes

eb94990

aerooneqq force-pushed the delegation-dont-generate-first-arg branch from da21a60 to eb94990 Compare June 2, 2026 07:43

aerooneqq mentioned this pull request Jun 2, 2026

delegation: split resolution and lowering #157296

Open

Cleanups

a51d4b9

aerooneqq changed the title ~~delegation: do not always generate first argument~~ delegation: do not always generate first argument (pt. 1) Jun 3, 2026

aerooneqq marked this pull request as ready for review June 3, 2026 08:44

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 3, 2026

petrochenkov reviewed Jun 3, 2026

View reviewed changes

rustbot added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 3, 2026

	} else if !matches!(&item.kind, AssocItemKind::Delegation(d) if matches!(d.source, DelegationSource::Glob))
	} else if let AssocItemKind::Delegation(d) = &item.kind && d.source == DelegationSource::Glob

	if param_count == 0 && matches!(delegation.source, DelegationSource::Single) {
	if param_count == 0 && should_generate_block {

Uh oh!

Conversation

aerooneqq commented May 21, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aerooneqq May 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aerooneqq May 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aerooneqq May 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

aerooneqq May 22, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aerooneqq May 22, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented May 22, 2026

Uh oh!

petrochenkov commented May 22, 2026

Uh oh!

rustbot commented May 22, 2026

Uh oh!

petrochenkov commented May 22, 2026

Uh oh!

petrochenkov commented May 23, 2026

Uh oh!

petrochenkov commented May 27, 2026

Uh oh!

petrochenkov commented May 27, 2026

Uh oh!

This comment has been minimized.

aerooneqq commented Jun 3, 2026

Uh oh!

petrochenkov commented Jun 3, 2026

Uh oh!

petrochenkov Jun 3, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petrochenkov Jun 3, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petrochenkov Jun 3, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petrochenkov Jun 3, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petrochenkov Jun 3, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petrochenkov commented Jun 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

aerooneqq commented May 21, 2026 •

edited by rustbot

Loading

aerooneqq May 22, 2026 •

edited

Loading

aerooneqq May 22, 2026 •

edited

Loading

aerooneqq May 22, 2026 •

edited

Loading

aerooneqq May 22, 2026 •

edited by rustbot

Loading

aerooneqq May 22, 2026 •

edited by rustbot

Loading

petrochenkov Jun 3, 2026 •

edited by rustbot

Loading

petrochenkov Jun 3, 2026 •

edited by rustbot

Loading

petrochenkov Jun 3, 2026 •

edited by rustbot

Loading

petrochenkov Jun 3, 2026 •

edited by rustbot

Loading

petrochenkov Jun 3, 2026 •

edited by rustbot

Loading