rust/src/test/ui/proc-macro/auxiliary, branch masterhttps://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=master2023-01-11T09:32:08+00:00Move /src/test to /tests2023-01-11T09:32:08+00:00Albert Larsan74931857+albertlarsan68@users.noreply.github.com2023-01-05T08:13:28+00:00urn:sha1:cf2dff2b1e3fa55fa5415d524200070d0d7aacfefix #104884, Avoid Invalid code suggested when encountering unsatisfied trait bounds in derive macro code2022-11-29T04:38:39+00:00yukangmoorekang@gmail.com2022-11-29T04:38:39+00:00urn:sha1:3980945ab1cd0815ba6bcd19143943b3a39c0593proc_macro/bridge: use the cross-thread executor for nested proc-macros2022-09-04T18:06:26+00:00Nika Layzellnika@thelayzells.com2022-09-04T16:53:29+00:00urn:sha1:efda49712b35009c0096217ce2aa262fc5ab8174
While working on some other changes in the bridge, I noticed that when
running a nested proc-macro (which is currently only possible using
the unstable `TokenStream::expand_expr`), any symbols held by the
proc-macro client would be invalidated, as the same thread would be used
for the nested macro by default, and the interner doesn't handle nested
use.
After discussing with @eddyb, we decided the best approach might be to
force the use of the cross-thread executor for nested invocations, as it
will never re-use thread-local storage, avoiding the issue. This
shouldn't impact performance, as expand_expr is still unstable, and
infrequently used.
This was chosen rather than making the client symbol interner handle
nested invocations, as that would require replacing the internal
interner `Vec` with a `BTreeMap` (as valid symbol id ranges could now be
disjoint), and the symbol interner is known to be fairly perf-sensitive.
This patch adds checks to the execution strategy to use the cross-thread
executor when doing nested invocations. An alternative implementation
strategy could be to track this information in the `ExtCtxt`, however a
thread-local in the `proc_macro` crate was chosen to add an assertion so
that `rust-analyzer` is aware of the issue if it implements
`expand_expr` in the future.
r? @eddyb
add regression test for #791482022-08-08T10:50:10+00:00Takayuki Maedatakoyaki0316@gmail.com2022-08-08T10:50:10+00:00urn:sha1:b3bc2111accc45af73ac50d537a679520cf1fc83Remove workarounds for issue 599982022-07-31T10:33:44+00:00bjorn317426603+bjorn3@users.noreply.github.com2022-07-31T10:03:44+00:00urn:sha1:df13721863253f6298264165348a60dfb9783f94proc_macro: Fix expand_expr expansion of bool literals2022-06-24T17:43:26+00:00Nika Layzellnika@thelayzells.com2022-06-19T17:56:04+00:00urn:sha1:fb5b7b4af2c46a2ac2117a49b3209569e7b6ddad
Previously, the expand_expr method would expand bool literals as a
`Literal` token containing a `LitKind::Bool`, rather than as an `Ident`.
This is not a valid token, and the `LitKind::Bool` case needs to be
handled seperately.
Tests were added to more deeply compare the streams in the expand-expr
test suite to catch mistakes like this in the future.
Do not suggest adding semicolon/changing delimiters for macros in item position that originates in macros2022-06-16T02:19:31+00:00Chayim Refael Friedmanchayimfr@gmail.com2022-05-24T23:41:34+00:00urn:sha1:0ef4098a540f0e8b91f64e1a5670b4e3ff1f48f3Revert #96682.2022-06-02T01:22:16+00:00Nicholas Nethercoten.nethercote@gmail.com2022-06-02T00:49:22+00:00urn:sha1:77e1069a5dfcc662ca2b0e731fa2fca2b6ee073b
The change was "Show invisible delimiters (within comments) when pretty
printing". It's useful to show these delimiters, but is a breaking
change for some proc macros.
Fixes #97608.
Show invisible delimeters (within comments) when pretty printing.2022-05-04T00:06:06+00:00Nicholas Nethercoten.nethercote@gmail.com2022-04-29T07:58:41+00:00urn:sha1:5022d764cfbdeacbaacbfb9361917cd3d58020d9Use str and char's Debug impl to format literals2022-03-26T20:15:48+00:00David Tolnaydtolnay@gmail.com2022-03-26T20:08:50+00:00urn:sha1:f383134acc48c97bbf2389aa62d51b9a51535482