Skip to content
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

expand: Implement something similar to #[cfg(accessible(path))] #69870

Merged
merged 3 commits into from
Mar 17, 2020

Conversation

petrochenkov
Copy link
Contributor

cc #64797

The feature is implemented as a #[cfg_accessible(path)] attribute macro rather than as #[cfg(accessible(path))] because it needs to wait until path becomes resolvable, and cfg cannot wait, but macros can wait.

Later we can think about desugaring or not desugaring #[cfg(accessible(path))] into #[cfg_accessible(path)].

This implementation is also incomplete in the sense that it never returns "false" from cfg_accessible(path), it requires some tweaks to resolve, which is not quite ready to answer queries like this during early resolution.

However, the most important part of this PR is not cfg_accessible itself, but expansion infrastructure for retrying expansions.
Before this PR we could say "we cannot resolve this macro path, let's try it later", with this PR we can say "we cannot expand this macro, let's try it later" as well.

This is a pre-requisite for

  • turning #[derive(...)] into a regular attribute macro,
  • properly supporting eager expansion for macros that cannot yet be resolved like
    fn main() {
        println!(not_available_yet!());
    }
    
    macro_rules! make_available {
        () => { #[macro_export] macro_rules! not_available_yet { () => { "Hello world!" } }}
    }
    
    make_available!();
    

@rust-highfive
Copy link
Collaborator

r? @estebank

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 9, 2020
@petrochenkov
Copy link
Contributor Author

r? @matthewjasper, I guess.

Some([nmi]) => match nmi.meta_item() {
None => ecx.span_err(nmi.span(), "`cfg_accessible` path cannot be a literal"),
Some(mi) => {
if !mi.is_word() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method could do with a better name

@matthewjasper
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Mar 11, 2020

📌 Commit 2e65289 has been approved by matthewjasper

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 11, 2020
Centril added a commit to Centril/rust that referenced this pull request Mar 16, 2020
expand: Implement something similar to `#[cfg(accessible(path))]`

cc rust-lang#64797

The feature is implemented as a `#[cfg_accessible(path)]` attribute macro rather than as `#[cfg(accessible(path))]` because it needs to wait until `path` becomes resolvable, and `cfg` cannot wait, but macros can wait.

Later we can think about desugaring or not desugaring `#[cfg(accessible(path))]` into `#[cfg_accessible(path)]`.

This implementation is also incomplete in the sense that it never returns "false" from `cfg_accessible(path)`, it requires some tweaks to resolve, which is not quite ready to answer queries like this during early resolution.

However, the most important part of this PR is not `cfg_accessible` itself, but expansion infrastructure for retrying expansions.
Before this PR we could say "we cannot resolve this macro path, let's try it later", with this PR we can say "we cannot expand this macro, let's try it later" as well.

This is a pre-requisite for
- turning `#[derive(...)]` into a regular attribute macro,
- properly supporting eager expansion for macros that cannot yet be resolved like
    ```
    fn main() {
        println!(not_available_yet!());
    }

    macro_rules! make_available {
        () => { #[macro_export] macro_rules! not_available_yet { () => { "Hello world!" } }}
    }

    make_available!();
    ```
bors added a commit that referenced this pull request Mar 16, 2020
Rollup of 7 pull requests

Successful merges:

 - #69870 (expand: Implement something similar to `#[cfg(accessible(path))]`)
 - #69881 (VariantSizeDifferences: bail on SizeOverflow)
 - #70000 (resolve: Fix regression in resolution of raw keywords in paths)
 - #70029 (Bump the bootstrap compiler)
 - #70046 (Use sublice patterns to avoid computing the len)
 - #70049 (Fiddle `ParamEnv` through to a place that used to use `ParamEnv::empty` in a buggy manner)
 - #70051 (Allow `hir().find` to return `None`)

Failed merges:

r? @ghost
bors added a commit that referenced this pull request Mar 17, 2020
Rollup of 7 pull requests

Successful merges:

 - #69811 (resolve: Print import chains on privacy errors)
 - #69870 (expand: Implement something similar to `#[cfg(accessible(path))]`)
 - #69881 (VariantSizeDifferences: bail on SizeOverflow)
 - #70000 (resolve: Fix regression in resolution of raw keywords in paths)
 - #70029 (Bump the bootstrap compiler)
 - #70046 (Use sublice patterns to avoid computing the len)
 - #70049 (Fiddle `ParamEnv` through to a place that used to use `ParamEnv::empty` in a buggy manner)

Failed merges:

r? @ghost
@bors bors merged commit 9fc5c2d into rust-lang:master Mar 17, 2020
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 7, 2021
expand/resolve: Turn `#[derive]` into a regular macro attribute

This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros`, like it was previously done with other "active" attributes in rust-lang#62086, rust-lang#62735 and other PRs.
This PR is also a continuation of rust-lang#65252, rust-lang#69870 and other PRs linked from them, which layed the ground for converting `#[derive]` specifically.

`#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)`, and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later), but otherwise `#[derive]` is treated as any other macro attributes, which simplifies the resolution-expansion infra pretty significantly.

The change has several observable effects on language and library.
Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](rust-lang#81119).

#### Library

- `derive` is now available through standard library as `{core,std}::prelude::v1::derive`.

#### Language

- `derive` now goes through name resolution, so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`.
- `derive` now goes through name resolution, so this resolution can fail in corner cases. Crater found one such regression, where import `use foo as derive` goes into a cycle with `#[derive(Something)]`.
- **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (rust-lang/reference#566). The following macro attributes become a part of the derive's input (this is not a change, non-macro attributes following `#[derive]` were treated in the same way previously).
- `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference, except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope, but previously both `Foo` and `Bar` were required to be resolved before expanding any of them.
- **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input, eagerly evaluating `cfg` everywhere in its target, for example on fields.
Expansion infra doesn't do that for other attributes, but now when macro attributes attributes are allowed to be written after `#[derive]`, it means that derive can *fully configure* items for them.
    ```rust
	#[derive()]
	#[my_attr]
	struct S {
		#[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]`
		field: u8
	}
    ```
- `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past, but was warned about since early 2018 (rust-lang#50092), despite that crater found a few such cases in unmaintained crates.
- Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization, rust-lang#52226 (comment)), but it was hard to do without fixing expansion order for derives. The deprecation is tracked by rust-lang#79202.
```rust
    #[trait_helper] // warning: derive helper attribute is used before it is introduced
    #[derive(Trait)]
    struct S {}
```

Crater analysis: rust-lang#79078 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants