https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.25.0 2018-02-06T14:43:01+00:00 2018-02-06T14:43:01+00:00 Alex Burka alex@alexburka.com 2018-02-06T14:43:01+00:00 urn:sha1:3cf73f40fb7217471dfe7394b73e67f53cfefc49 2018-01-12T10:00:09+00:00 bors bors@rust-lang.org 2018-01-12T10:00:09+00:00 urn:sha1:0b90e4e8cd068910f604f3e1fb5d03cc01f1658f macros: improve 1.0/2.0 interaction This PR supports using unhygienic macros from hygienic macros without breaking the latter's hygiene. ```rust // crate A: #[macro_export] macro_rules! m1 { () => { f(); // unhygienic: this macro needs `f` in its environment fn g() {} // (1) unhygienic: `g` is usable outside the macro definition } } // crate B: #![feature(decl_macro)] extern crate A; use A::m1; macro m2() { fn f() {} // (2) m1!(); // After this PR, `f()` in the expansion resolves to (2), not (3) g(); // After this PR, this resolves to `fn g() {}` from the above expansion. // Today, it is a resolution error. } fn test() { fn f() {} // (3) m2!(); // Today, `m2!()` can see (3) even though it should be hygienic. fn g() {} // Today, this conflicts with `fn g() {}` from the expansion, even though it should be hygienic. } ``` Once this PR lands, you can make an existing unhygienic macro hygienic by wrapping it in a hygienic macro. There is an [example](https://github.com/rust-lang/rust/pull/46551/commits/b766fa887dc0e4b923a38751fe4d570e35a75710) of this in the tests. r? @nrc 2018-01-06T12:02:36+00:00 bors bors@rust-lang.org 2018-01-06T12:02:36+00:00 urn:sha1:a9a03d9bfb0e82322439fe6c252ebd4ba6f23d98 Add 'Span::parent()' and 'Span::source()' to proc_macro API. As the title suggests: a couple of useful methods for `proc_macro`. 2018-01-05T09:22:08+00:00 kennytm kennytm@gmail.com 2018-01-05T09:22:08+00:00 urn:sha1:5a5b16ad065aa4fdd21f4ad696ab91a825f8f781 Return None from Span::join if in different files Fixes #47148. r? @abonander 2018-01-03T08:20:33+00:00 Sergio Benitez sb@sergio.bz 2018-01-01T02:30:13+00:00 urn:sha1:ab365be1406919d4da42442b70c153296980ba52 2018-01-03T07:43:52+00:00 David Tolnay dtolnay@gmail.com 2018-01-03T07:29:11+00:00 urn:sha1:000e907c1fc73ca249252cba3b2c9b1a20de857d Proc macro spans serve two mostly unrelated purposes: controlling name resolution and controlling error messages. It can be useful to mix the name resolution behavior of one span with the line/column error message locations of a different span. In particular, consider the case of a trait brought into scope within the def_site of a custom derive. I want to invoke trait methods on the fields of the user's struct. If the field type does not implement the right trait, I want the error message to underline the corresponding struct field. Generating the method call with the def_site span is not ideal -- it compiles and runs but error messages sadly always point to the derive attribute like we saw with Macros 1.1. ``` | 4 | #[derive(HeapSize)] | ^^^^^^^^ ``` Generating the method call with the same span as the struct field's ident or type is not correct -- it shows the right underlines but fails to resolve to the trait in scope at the def_site. ``` | 7 | bad: std::thread::Thread, | ^^^^^^^^^^^^^^^^^^^^^^^^ ``` The correct span for the method call is one that combines the def_site's name resolution with the struct field's line/column. ``` field.span.resolved_at(Span::def_site()) // equivalently Span::def_site().located_at(field.span) ``` Adding both because which one is more natural will depend on context. 2018-01-03T07:37:36+00:00 David Tolnay dtolnay@gmail.com 2018-01-03T07:37:36+00:00 urn:sha1:2b9add2c165c4e397aeb02e1d11c57621ad11dbe 2017-12-15T14:26:58+00:00 Steve Klabnik steve@steveklabnik.com 2017-12-15T14:26:58+00:00 urn:sha1:1375be833af1ee94edac08cad87e1f64c9ab827f Expose the line and column fields from the proc_macro::LineColumn struct Right now the `LineColumn` struct is pretty useless because the fields are private. This patch just marks the fields as public, which seems like the easiest solution. 2017-12-14T10:22:08+00:00 Oliver Schneider git-spam-no-reply9815368754983@oli-obk.de 2017-12-14T07:09:19+00:00 urn:sha1:d732da813bac73d2c81caddd06df3df3d9609e3d 2017-12-13T21:33:03+00:00 Jeffrey Seyfried jeffrey.seyfried@gmail.com 2017-11-29T09:05:31+00:00 urn:sha1:d052d28d70b31fac942765da137f794835e6536e