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

Stabilize attribute macros on inline modules #64273

Open
wants to merge 1 commit into
base: master
from

Conversation

@petrochenkov
Copy link
Contributor

petrochenkov commented Sep 7, 2019

While still gating non-inline modules in proc macro input.

Split from #63931
cc #54727

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Sep 7, 2019

r? @eddyb

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

@petrochenkov

This comment has been minimized.

Copy link
Contributor Author

petrochenkov commented Sep 7, 2019

Stabilization report

Macro attributes are now supported on inline module items (mod m { ... }), the behavior is the same as for attributes on any other items available on stable.

The feature is a part of the franken-feature #![feature(proc_macro_hygiene)].
The feature was implemented together with all other proc macro attributes on items somewhere in 2017-2018.
Its current instability is a collateral damage from attributes on out-of-line modules, which actually have unresolved questions (like whether the mod file should be loaded before expanding the macro or after, and what should proc macros do if they need to load files themselves).

@petrochenkov petrochenkov force-pushed the petrochenkov:stabattrmod branch from 8a0f68f to 6377801 Sep 8, 2019
@rust-highfive

This comment was marked as resolved.

Copy link
Collaborator

rust-highfive commented Sep 8, 2019

The job x86_64-gnu-llvm-6.0 of your PR failed (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
2019-09-08T00:02:35.3611710Z ##[command]git remote add origin https://github.com/rust-lang/rust
2019-09-08T00:02:35.3820954Z ##[command]git config gc.auto 0
2019-09-08T00:02:35.3909782Z ##[command]git config --get-all http.https://github.com/rust-lang/rust.extraheader
2019-09-08T00:02:36.0035859Z ##[command]git config --get-all http.proxy
2019-09-08T00:02:36.0043542Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --force --tags --prune --progress --no-recurse-submodules --depth=2 origin +refs/heads/*:refs/remotes/origin/* +refs/pull/64273/merge:refs/remotes/pull/64273/merge
---
2019-09-08T01:09:07.7366820Z .................................................................................................... 1500/9009
2019-09-08T01:09:14.0874375Z .................................................................................................... 1600/9009
2019-09-08T01:09:28.3111027Z ......................................................i...............i............................. 1700/9009
2019-09-08T01:09:36.8526039Z .................................................................................................... 1800/9009
2019-09-08T01:09:52.5366466Z .............................................iiiii.................................................. 1900/9009
2019-09-08T01:10:04.4780681Z .................................................................................................... 2100/9009
2019-09-08T01:10:07.3301462Z .................................................................................................... 2200/9009
2019-09-08T01:10:11.2168267Z .................................................................................................... 2300/9009
2019-09-08T01:10:19.8000138Z .................................................................................................... 2400/9009
---
2019-09-08T01:13:31.6177436Z .................................i...............i.................................................. 4700/9009
2019-09-08T01:13:44.3696159Z .................................................................................................... 4800/9009
2019-09-08T01:13:50.9928092Z .................................................................................................... 4900/9009
2019-09-08T01:14:02.5119979Z .................................................................................................... 5000/9009
2019-09-08T01:14:08.9431992Z ...............ii.ii................................................................................ 5100/9009
2019-09-08T01:14:20.3946145Z .................................................................................................... 5300/9009
2019-09-08T01:14:31.2637166Z ..............................................................................i..................... 5400/9009
2019-09-08T01:14:39.4092847Z .................................................................................................... 5500/9009
2019-09-08T01:14:45.9681552Z .................................................................................................... 5600/9009
2019-09-08T01:14:45.9681552Z .................................................................................................... 5600/9009
2019-09-08T01:14:57.3140184Z ........................................................................ii...i..ii...........i...... 5700/9009
2019-09-08T01:15:24.6483034Z .................................................................................................... 5900/9009
2019-09-08T01:15:35.5439649Z .................................................................................................... 6000/9009
2019-09-08T01:15:35.5439649Z .................................................................................................... 6000/9009
2019-09-08T01:15:46.4070941Z ..........................................................................i..ii..................... 6100/9009
2019-09-08T01:16:18.1159681Z .................................................................................................... 6300/9009
2019-09-08T01:16:20.3684792Z .................................i.................................................................. 6400/9009
2019-09-08T01:16:22.7064928Z .................................................................................................... 6500/9009
2019-09-08T01:16:25.5448714Z .....i.............................................................................................. 6600/9009
---
2019-09-08T01:20:46.1416442Z 
2019-09-08T01:20:46.1417485Z ---- [ui] ui/proc-macro/attributes-on-modules-fail.rs stdout ----
2019-09-08T01:20:46.1417746Z diff of stderr:
2019-09-08T01:20:46.1417889Z 
2019-09-08T01:20:46.1418424Z - error: `derive` may only be applied to structs, enums and unions
2019-09-08T01:20:46.1418900Z -   --> $DIR/attributes-on-modules-fail.rs:16:1
2019-09-08T01:20:46.1419355Z + error: couldn't read $DIR/outer/../module.rs: No such file or directory (os error 2)
2019-09-08T01:20:46.1419796Z +   --> $DIR/attributes-on-modules-fail.rs:25:9
2019-09-08T01:20:46.1420986Z - LL | #[derive(Copy)]
2019-09-08T01:20:46.1421715Z -    | ^^^^^^^^^^^^^^^
2019-09-08T01:20:46.1422099Z - 
2019-09-08T01:20:46.1422411Z - error[E0658]: non-inline modules in proc macro input are unstable
2019-09-08T01:20:46.1422411Z - error[E0658]: non-inline modules in proc macro input are unstable
2019-09-08T01:20:46.1422688Z -   --> $DIR/attributes-on-modules-fail.rs:20:1
2019-09-08T01:20:46.1422902Z -    |
2019-09-08T01:20:46.1423131Z - LL | mod module;
2019-09-08T01:20:46.1423542Z -    |
2019-09-08T01:20:46.1423542Z -    |
2019-09-08T01:20:46.1423972Z -    = note: for more information, see ***/issues/54727
2019-09-08T01:20:46.1424287Z -    = help: add `#![feature(proc_macro_hygiene)]` to the crate attributes to enable
2019-09-08T01:20:46.1424752Z - error[E0658]: non-inline modules in proc macro input are unstable
2019-09-08T01:20:46.1425019Z -   --> $DIR/attributes-on-modules-fail.rs:25:5
2019-09-08T01:20:46.1425219Z -    |
2019-09-08T01:20:46.1425274Z 19 LL |     mod module;
2019-09-08T01:20:46.1425274Z 19 LL |     mod module;
2019-09-08T01:20:46.1425506Z -    |     ^^^^^^^^^^^
2019-09-08T01:20:46.1425703Z -    |
2019-09-08T01:20:46.1426009Z -    = note: for more information, see ***/issues/54727
2019-09-08T01:20:46.1426339Z -    = help: add `#![feature(proc_macro_hygiene)]` to the crate attributes to enable
2019-09-08T01:20:46.1426690Z 24 
2019-09-08T01:20:46.1427785Z - error[E0412]: cannot find type `Y` in this scope
2019-09-08T01:20:46.1428080Z -   --> $DIR/attributes-on-modules-fail.rs:10:14
2019-09-08T01:20:46.1428283Z -    |
2019-09-08T01:20:46.1428283Z -    |
2019-09-08T01:20:46.1428519Z - LL |     type A = Y;
2019-09-08T01:20:46.1428978Z - help: a type alias with a similar name exists
2019-09-08T01:20:46.1429178Z -    |
2019-09-08T01:20:46.1429178Z -    |
2019-09-08T01:20:46.1429409Z - LL |     type A = A;
2019-09-08T01:20:46.1429897Z - help: possible candidate is found in another module, you can import it into scope
2019-09-08T01:20:46.1430628Z -    |
2019-09-08T01:20:46.1430854Z - LL |     use Y;
2019-09-08T01:20:46.1431049Z -    |
2019-09-08T01:20:46.1431049Z -    |
2019-09-08T01:20:46.1431599Z + error: aborting due to previous error
2019-09-08T01:20:46.1431680Z 38 
2019-09-08T01:20:46.1432015Z - error[E0412]: cannot find type `X` in this scope
2019-09-08T01:20:46.1432274Z -   --> $DIR/attributes-on-modules-fail.rs:14:10
2019-09-08T01:20:46.1432499Z -    |
2019-09-08T01:20:46.1432706Z - LL | type A = X;
2019-09-08T01:20:46.1433397Z - help: a type alias with a similar name exists
2019-09-08T01:20:46.1433608Z -    |
2019-09-08T01:20:46.1433608Z -    |
2019-09-08T01:20:46.1433813Z - LL | type A = A;
2019-09-08T01:20:46.1434346Z - help: possible candidate is found in another module, you can import it into scope
2019-09-08T01:20:46.1434547Z -    |
2019-09-08T01:20:46.1434547Z -    |
2019-09-08T01:20:46.1434751Z - LL | use m::X;
2019-09-08T01:20:46.1435154Z - 
2019-09-08T01:20:46.1435388Z - error: aborting due to 5 previous errors
2019-09-08T01:20:46.1435597Z - 
2019-09-08T01:20:46.1435851Z - Some errors have detailed explanations: E0412, E0658.
2019-09-08T01:20:46.1435851Z - Some errors have detailed explanations: E0412, E0658.
2019-09-08T01:20:46.1436400Z - For more information about an error, try `rustc --explain E0412`.
2019-09-08T01:20:46.1436475Z 57 
2019-09-08T01:20:46.1436510Z 
2019-09-08T01:20:46.1436539Z 
2019-09-08T01:20:46.1436599Z The actual stderr differed from the expected stderr.
2019-09-08T01:20:46.1436983Z Actual stderr saved to /checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/proc-macro/attributes-on-modules-fail/attributes-on-modules-fail.stderr
2019-09-08T01:20:46.1437262Z To update references, rerun the tests and pass the `--bless` flag
2019-09-08T01:20:46.1437605Z To only update this specific test, also pass `--test-args proc-macro/attributes-on-modules-fail.rs`
2019-09-08T01:20:46.1437724Z error: 1 errors occurred comparing output.
2019-09-08T01:20:46.1437778Z status: exit code: 1
2019-09-08T01:20:46.1437778Z status: exit code: 1
2019-09-08T01:20:46.1438665Z command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/ui/proc-macro/attributes-on-modules-fail.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/proc-macro/attributes-on-modules-fail" "-Crpath" "-O" "-Cdebuginfo=0" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/proc-macro/attributes-on-modules-fail/auxiliary" "-A" "unused"
2019-09-08T01:20:46.1439056Z ------------------------------------------
2019-09-08T01:20:46.1439096Z 
2019-09-08T01:20:46.1439354Z ------------------------------------------
2019-09-08T01:20:46.1439409Z stderr:
2019-09-08T01:20:46.1439409Z stderr:
2019-09-08T01:20:46.1439681Z ------------------------------------------
2019-09-08T01:20:46.1440522Z error: couldn't read /checkout/src/test/ui/proc-macro/outer/../module.rs: No such file or directory (os error 2)
2019-09-08T01:20:46.1440982Z    |
2019-09-08T01:20:46.1440982Z    |
2019-09-08T01:20:46.1441281Z LL |     mod module; //~ ERROR non-inline modules in proc macro input are unstable
2019-09-08T01:20:46.1441389Z 
2019-09-08T01:20:46.1441689Z error: aborting due to previous error
2019-09-08T01:20:46.1441736Z 
2019-09-08T01:20:46.1441764Z 
---
2019-09-08T01:20:46.1464984Z thread 'main' panicked at 'Some tests failed', src/tools/compiletest/src/main.rs:536:22
2019-09-08T01:20:46.1465335Z note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
2019-09-08T01:20:46.1491944Z 
2019-09-08T01:20:46.1492036Z 
2019-09-08T01:20:46.1494538Z command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/ui" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "ui" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-6.0/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "6.0.0\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
2019-09-08T01:20:46.1495258Z 
2019-09-08T01:20:46.1495289Z 
2019-09-08T01:20:46.1498318Z failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
2019-09-08T01:20:46.1498572Z Build completed unsuccessfully in 1:10:50
2019-09-08T01:20:46.1498572Z Build completed unsuccessfully in 1:10:50
2019-09-08T01:20:46.1552454Z == clock drift check ==
2019-09-08T01:20:46.1572084Z   local time: Sun Sep  8 01:20:46 UTC 2019
2019-09-08T01:20:46.3091063Z   network time: Sun, 08 Sep 2019 01:20:46 GMT
2019-09-08T01:20:46.3091499Z == end clock drift check ==
2019-09-08T01:20:47.0791558Z ##[error]Bash exited with code '1'.
2019-09-08T01:20:47.0831656Z ##[section]Starting: Checkout
2019-09-08T01:20:47.0833822Z ==============================================================================
2019-09-08T01:20:47.0833897Z Task         : Get sources
2019-09-08T01:20:47.0833944Z Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@petrochenkov petrochenkov force-pushed the petrochenkov:stabattrmod branch from 6377801 to 10df935 Sep 8, 2019
@petrochenkov

This comment has been minimized.

Copy link
Contributor Author

petrochenkov commented Sep 9, 2019

@rust-highfive rust-highfive assigned Centril and unassigned eddyb Sep 9, 2019
@JohnCSimon

This comment was marked as resolved.

Copy link
Member

JohnCSimon commented Sep 14, 2019

Ping from triage:
@Centril Can you please review this pr?
Thanks.

@jonas-schievink jonas-schievink added this to the 1.39 milestone Sep 15, 2019
@Centril

This comment has been minimized.

Copy link
Member

Centril commented Sep 19, 2019

(triage: I'll look at this PR during the weekend.)

@Centril Centril modified the milestones: 1.39, 1.40 Sep 26, 2019
@bors

This comment was marked as resolved.

Copy link
Contributor

bors commented Sep 27, 2019

☔️ The latest upstream changes (presumably #64813) made this pull request unmergeable. Please resolve the merge conflicts.

Centril added a commit to Centril/rust that referenced this pull request Oct 1, 2019
Stabilize macros in some more positions

- Fn-like macros and attribute macros in `extern` blocks
- Fn-like procedural macros in type positions
- ~Attribute macros on inline modules~ (moved to rust-lang#64273)

Stabilization report: rust-lang#63931 (comment).

Closes rust-lang#49476
cc rust-lang#54727
Centril added a commit to Centril/rust that referenced this pull request Oct 1, 2019
Stabilize macros in some more positions

- Fn-like macros and attribute macros in `extern` blocks
- Fn-like procedural macros in type positions
- ~Attribute macros on inline modules~ (moved to rust-lang#64273)

Stabilization report: rust-lang#63931 (comment).

Closes rust-lang#49476
cc rust-lang#54727
@Centril

This comment has been minimized.

Copy link
Member

Centril commented Oct 1, 2019

Declaring reviewer bankruptcy on this PR (sorry!) and reassigning to r? @pnkfelix who is considering the macro related changes together.

(I'm a bit bummed by the visitor approach that is unfortunately necessary to land this. From a compiler POV it's trivial but from a spec POV it's not.)

@rust-highfive rust-highfive assigned pnkfelix and unassigned Centril Oct 1, 2019
@petrochenkov

This comment has been minimized.

Copy link
Contributor Author

petrochenkov commented Oct 1, 2019

I'm a bit bummed by the visitor approach that is unfortunately necessary to land this.

FWIW, that's the same approach that is used for gating macro-expanded macro_rules until #64035 lands.

@JohnCSimon

This comment was marked as resolved.

Copy link
Member

JohnCSimon commented Oct 5, 2019

Ping from triage
@petrochenkov Can you please address the merge conflicts?
Thanks

@petrochenkov

This comment was marked as resolved.

Copy link
Contributor Author

petrochenkov commented Oct 5, 2019

Can you please address the merge conflicts?

Will do, after a review and FCP.

@joelpalmer

This comment was marked as resolved.

Copy link

joelpalmer commented Oct 14, 2019

Ping from triage: @Centril @pnkfelix @petrochenkov any updates? Should this have an FCP label?

@pnkfelix

This comment has been minimized.

Copy link
Member

pnkfelix commented Nov 20, 2019

We discussed this in recent lang team meetings.

The general agreement was that in the long term, we should resolve the semantics for how expansion interacts with out-of-line modules, which raises issues (aka technical artifacts, aka warts) such as the ones documented at #64197.

  • The feeling of the room was that we probably want a "lazy loading" semantics for out-of-line modules
  • The decision there should probably be handled by some shepherded group (it does not need to involve the entire lang team).

But we don't have to solve the problem of out-of-line modules now: The semantics that is being stabilized here for attributes on inline modules seems like the reasonable one to adopt, and however we resolve the out-of-line module case should be compatible with what is being stabilized here.

The notes from the language team meeting include the following suggestion for the documentation:

Documentation: “Note that an out-of-line module, mod foo;, appears to any macro as just that item; the macro does not run over the contents of the module.”

  • I'll be honest here: I, pnkfelix, had thought (and still think) that the state proposed by this PR was that procedural macros simply could not be be stably applied to an item that contains any out-of-line module declaration. So I don't know if the above suggestion was meant to enhance documentation of the unstable feature, or if I actually misunderstand what is being stabilized here.
  • In any case, we do need to make sure that the documentation for this includes some text about the behavior of how (in stable Rust) out-of-line modules declarations mod foo; within other items are treated, even if the answer is "It is a static error to have an out-of-line module declaration within an item that fed as input to a procedural attribute macro."

In case you cannot tell, I was writing the above up as notes to prepare an FCP merge command.

But given the questions I ended up posing to myself at the end of the notes, I want to hold off on actually issuing the FCP merge request until I have privately resolved my questions. I'm going to download this branch and play with it locally to try to ensure I understand the implications before firing off the FCP merge.

@pnkfelix

This comment has been minimized.

Copy link
Member

pnkfelix commented Nov 21, 2019

Okay, I think I have reconciled the points that I noted in my earlier comment.

The reason it probably makes sense to include documentation about the current semantics, even though the feature is unstable, is that the procedural macros are executed with the given inputs, before the stability error is issued. In other words, the macros observe the current token streams you get for out-of-line modules (and may exhibit some behavior based upon them), and thus it makes sense for us to document that.

I also double-checked the current test suite. The tests that are affected by this are:

  • #[identity_attr]
    mod m {
    pub struct X;
    type A = Y; //~ ERROR cannot find type `Y` in this scope
    }
    struct Y;
    type A = X; //~ ERROR cannot find type `X` in this scope
    #[derive(Copy)] //~ ERROR `derive` may only be applied to structs, enums and unions
    mod n {}
    #[empty_attr]
    mod module; //~ ERROR non-inline modules in proc macro input are unstable
    #[empty_attr]
    mod outer {
    mod inner; //~ ERROR non-inline modules in proc macro input are unstable
    mod inner_inline {} // OK
    }
  • #[identity_attr]
    mod m {
    pub struct S;
    }

It would be good for the test suite to be expanded to include the case of modules within non-module blocks, like this:

// A failing test
#[identity_attr]
fn bar() { #[path="outline_f.rs"] mod outline_f; } //~ ERROR ...

// A passing test
#[identity_attr]
fn baz() { mod inline_g { } }

(More information about what I did in the details block.)

I built this branch locally, made an attribute macro named #[styx] (that just clones the input, prints it, and returns the original input), and ran it on a test like this:

#[styx]
mod inline_a { }

// OKAY
#[styx]
mod inline_b { mod inline_b1 {  } }

// OKAY
#[styx]
fn foo() { mod inline_c { } }

// Got: error[E0658]: non-inline modules in proc macro input are unstable
#[styx]
mod outline_d;

// Got: error[E0658]: non-inline modules in proc macro input are unstable
#[styx]
mod inline_e { mod outline_e1; }

// FYI: Without a `path` attribute, this gets "Cannot declare a non-inline module inside a block unless it has a path attribute" (which seems good to me)
//
// Got: error[E0658]: non-inline modules in proc macro input are unstable
#[styx]
fn bar() { #[path="outline_f.rs"] mod outline_f; }

// OKAY
//
// Contains the text:
// ```
// use styx::styx;
//
// #[styx]
// mod inline_g1 { }
// ```
mod outline_g;
@pnkfelix

This comment has been minimized.

Copy link
Member

pnkfelix commented Nov 21, 2019

I had originally written that merging this PR need not be held up on waiting for the addition of the test case I requested above. (And I still do believe that to be true.)

However, I do think the requested documentation addition should be part of the stabilization here.

I don't have time at the moment to try to figure out where that documentation addition belongs.

@petrochenkov , if you have time in the next 24 hours or so to add that sentence in the appropriate place (and, if you can, the test I requested), then I'll issue an FCP merge request.

Otherwise, if you don't have time, I'll try to figure it out myself tomorrow.

@Robbepop

This comment has been minimized.

Copy link
Contributor

Robbepop commented Nov 21, 2019

The reason it probably makes sense to include documentation about the current semantics, even though the feature is unstable, is that the procedural macros are executed with the given inputs, before the stability error is issued. In other words, the macros observe the current token streams you get for out-of-line modules (and may exhibit some behavior based upon them), and thus it makes sense for us to document that.

What probably some proc. macros might want to do is to load those out-of-line modules into their attributed module definition. Would it make sense to also provide documentation about how those users should probably be tackling this issues as long as there are no stable alternatives? Recommendations how to tackle this potentially very common use case might be of use.

For example, they might make use of #[path = ...] attributes out-of-line modules because that's what stable Rust already provides. But then users also might think that maybe this is going to potentially conflict with future stable improvements and will do something like #[my_namespace(path = ...)] instead to identify the paths of those out-of-line modules.

@pnkfelix

This comment has been minimized.

Copy link
Member

pnkfelix commented Nov 21, 2019

What probably some proc. macros might want to do is to load those out-of-line modules into their attributed module definition. Would it make sense to also provide documentation about how those users should probably be tackling this issues as long as there are no stable alternatives? Recommendations how to tackle this potentially very common use case might be of use.

Hmm. Establishing what the best-practices/recommendations are for those scenarios sounds like something that could be done with this PR, but it could also wait until later, no?

Or at least, I personally don't feel comfortable trying to devise what the best-practices are there, but I also don't feel comfortable blocking stabilization of the inline module case on the development of those best-practices.

@pnkfelix

This comment has been minimized.

Copy link
Member

pnkfelix commented Nov 21, 2019

Further discussion in tonight's lang team meeting led the T-lang members present to conclude that the FCP merge request does not need to be blocked on either of the points (the test I requested and the documentation addition).

So, having said that:

@rfcbot fcp merge

@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Nov 21, 2019

Team member @pnkfelix has proposed to merge this. The next step is review by the rest of the tagged team members:

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 this document for info about what commands tagged team members can give me.

@petrochenkov

This comment has been minimized.

Copy link
Contributor Author

petrochenkov commented Nov 22, 2019

Updated with the requested tests.

@petrochenkov

This comment has been minimized.

Copy link
Contributor Author

petrochenkov commented Nov 22, 2019

@pnkfelix

The reason it probably makes sense to include documentation about the current semantics, even though the feature is unstable, is that the procedural macros are executed with the given inputs

I'm not even sure what the current semantics are, it may depend on whether expansion goes through pretty-printing or not, and whether nested modules are involved.
I don't want to spend time investigating the details now, but once #64197 is implemented, the macros will certainly get tokens mod name ; as an input.

@Robbepop

What probably some proc. macros might want to do is to load those out-of-line modules into their attributed module definition. Would it make sense to also provide documentation about how those users should probably be tackling this issues as long as there are no stable alternatives?

#64273 (comment) mentions a practice that can hardly be named "best", but works (including on stable, after this PR is merged).

// lib.rs
include!("my_file.rs");

// my_file.rs
#[my_attr]
mod inline { /* ... */ }
@bors

This comment was marked as resolved.

Copy link
Contributor

bors commented Dec 3, 2019

☔️ The latest upstream changes (presumably #66982) made this pull request unmergeable. Please resolve the merge conflicts.

@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Dec 5, 2019

🔔 This is now entering its final comment period, as per the review above. 🔔

@petrochenkov petrochenkov force-pushed the petrochenkov:stabattrmod branch from 43f4962 to a58e024 Dec 12, 2019
@petrochenkov

This comment has been minimized.

Copy link
Contributor Author

petrochenkov commented Dec 12, 2019

Okay, I'm going to beta nominate this since there's still chance to get this into 1.40.

Q: Why we should backport this to beta.
A: To get all the recent macro stabilizations into one release, which can be a new reference point for macro authors. This will also make a better announcement post.
The PR was submitted more than 3 months and 2 releases ago and was supposed to land together with other macro features (#63931, #64035, #63674) that went through review faster.

Q: Why we can backport this to beta.
A: The change (excluding tests) is tiny and trivial.

@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

Mark-Simulacrum commented Dec 12, 2019

If this is to get accepted into beta before branching (and I don't really want to, but do see that it could plausibly be done) it would need to happen in the next ~4 days or so before beta branches next week. It would likely be best to bring it up for acceptance at tomorrow's compiler team (planning) meeting; cc @pnkfelix @nikomatsakis

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Dec 13, 2019

We decided against backport in today's design meeting on the basis of the the general rule of "don't backport stabilizations without a very strong reason".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.