| Age | Commit message (Collapse) | Author | Lines |
|
|
|
This would have avoided a bug in https://github.com/rust-lang/rust/pull/104860.
In practice this shouldn't matter since nothing uses the query other than the `dead_code` lint,
but this isn't documented as an internal-only query so it seems nice for it to be accurate.
I think for `dead_code` it doesn't matter because the relevant code is generated by `rustc_builtin_macros` and isn't linted.
|
|
|
|
available
|
|
This migrates everything but the `mbe` and `proc_macro` modules. It also
contains a few cleanups and drive-by/accidental diagnostic improvements
which can be seen in the diff for the UI tests.
|
|
trait bounds in derive macro code
|
|
Co-authored-by: Daniel Henry-Mantilla <daniel.henry.mantilla@gmail.com>
|
|
|
|
|
|
Make PROC_MACRO_DERIVE_RESOLUTION_FALLBACK a hard error
r? `@ghost`
|
|
|
|
|
|
The latest version of `rental` (v0.5.6) contains a fix that allows it to
compile without relying on the pretty-print back-compat hack.
Hopefully, there are no longer any crates relying on the affected
versions of the (much less popular) `procedural-masquerade` crate. This
should allow us to target the pretty-print back-compat hack specifically
to older versions of `rental`, and specifically mention upgrading to
`rental` v0.5.6 in the lint message.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This test case actually requires std::process.
|
|
Adding needs-unwind arg to applicable compiler ui tests
Adding `needs-unwind` arg to applicable compiler ui tests
|
|
|
|
|
|
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
|
|
Make trait bound not satisfied specify kind
Closes #99875
|
|
This PR will fix some typos detected by [typos].
I only picked the ones I was sure were spelling errors to fix, mostly in
the comments.
[typos]: https://github.com/crate-ci/typos
|
|
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #97183 (wf-check generators)
- #98320 (Mention first and last macro in backtrace)
- #99335 (Use split_once in FromStr docs)
- #99347 (Use `LocalDefId` in `OpaqueTypeKey`)
- #99392 (Fix debuginfo tests.)
- #99404 (Use span_bug for unexpected field projection type)
- #99410 (Update invalid atomic ordering lint)
- #99434 (Fix `Skip::next` for non-fused inner iterators)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Doing this for all unicode identifiers would require a dependency on
`unicode-normalization` and `rustc_lexer`, which is currently not
possible for `proc_macro` due to it being built concurrently with `std`
and `core`. Instead, ASCII identifiers are validated locally, and an RPC
message is used to validate unicode identifiers when needed.
String values are interned on the both the server and client when
deserializing, to avoid unnecessary copies and keep Ident cheap to copy and
move. This appears to be important for performance.
The client-side interner is based roughly on the one from rustc_span, and uses
an arena inspired by rustc_arena.
RPC messages passing symbols always include the full value. This could
potentially be optimized in the future if it is revealed to be a
performance bottleneck.
Despite now having a relevant implementaion of Display for Ident, ToString is
still specialized, as it is a hot-path for this object.
The symbol infrastructure will also be used for literals in the next
part.
|
|
r=cjgillot
gather body owners
Issue #96341
|
|
Signed-off-by: Miguel Guarniz <mi9uel9@gmail.com>
|
|
proc_macro: Fix expand_expr expansion of bool literals
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.
|
|
|
|
|
|
Unbreak stage1 tests via ignore-stage1 in `proc-macro/invalid-punct-ident-1.rs`.
#98188 broke `./x.py test --stage 1` (which I thought we ran in PR CI, cc `@rust-lang/infra)` i.e. the default `./x.py test` in dev checkouts, as the panic in `src/test/ui/proc-macro/invalid-punct-ident-1.rs` moved from the server (`rustc`) to the client (proc macro), and that means it's now affected by #59998.
I made the test look like `src/test/ui-fulldeps/issue-76270-panic-in-libproc-macro.rs` tho I'm a bit confused why that one is in `src/test/ui-fulldeps`, it should still work in `src/test/ui`, no? (cc `@Aaron1011)`
|
|
Clean up arg mismatch diagnostic, generalize tuple wrap suggestion
This is based on top of #97542, so just look at the last commit which contains the relevant changes.
1. Remove `final_arg_types` which was one of the last places we were using raw (`usize`) indices instead of typed indices in the arg mismatch suggestion code.
2. Improve the tuple wrap suggestion, now we suggest things like `call(a, b, c, d)` -> `call(a, (b, c), d)` :smiley_cat:
3. Folded in fix #98645
|
|
|
|
|
|
This greatly reduces round-trips to fetch relevant extra information about the
token in proc macro code, and avoids RPC messages to create Punct tokens.
|
|
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 macros
Fixes #91800.
|
|
position that originates in macros
|
|
|