Skip to content

Simplify #[derive(BuiltinTrait)] expansion wrt. lifetimes #61876

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Centril opened this issue Jun 15, 2019 · 3 comments
Closed

Simplify #[derive(BuiltinTrait)] expansion wrt. lifetimes #61876

Centril opened this issue Jun 15, 2019 · 3 comments
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-proc-macros Area: Procedural macros C-enhancement Category: An issue proposing an enhancement or a PR with one. I-compiletime Issue: Problems and improvements with respect to compile times. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Centril
Copy link
Contributor

Centril commented Jun 15, 2019

For example, given:

#[derive(Clone)]
struct A<'a>(&'a u8);

we generate:

impl<'a> Clone for A<'a> { ... }

but we should be able to generate:

impl Clone for A<'_> { ... }

This might lead to perf improvements by generating less tokens.

cc @zackmdavis @scottmcm @eddyb @petrochenkov
cc #61824

@Centril Centril added C-enhancement Category: An issue proposing an enhancement or a PR with one. A-syntaxext Area: Syntax extensions A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 15, 2019
@eddyb
Copy link
Member

eddyb commented Jun 16, 2019

If we need to generate any bounds, at all, this will be tricky as we'd have to check which lifetime names would show up in the bounds. Other than that, it seems straight-forward.
One thing we should make sure first is that we don't use A<'a> anywhere today other than the impl header (and that we're using Self everywhere else).

@Mark-Simulacrum Mark-Simulacrum added the I-compiletime Issue: Problems and improvements with respect to compile times. label Jun 24, 2019
@jyn514
Copy link
Member

jyn514 commented Jul 14, 2021

Is this useful? It seems awfully complicated, and I don't think the lexer is the slow part of the compiler ...

@jyn514 jyn514 added A-proc-macros Area: Procedural macros and removed A-syntaxext Area: Syntax extensions labels Jul 14, 2021
@petrochenkov
Copy link
Contributor

This kind of leads to a philosophical question - what is the purpose of an issue tracker? Should it track potentially nice ideas that nobody is going to implement, not even the author?

I'd personally close this, if someone is ready to invest work into proving usefulness of this idea and measure performance, then a PR is welcome, but otherwise we should not track this as an open issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-proc-macros Area: Procedural macros C-enhancement Category: An issue proposing an enhancement or a PR with one. I-compiletime Issue: Problems and improvements with respect to compile times. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants