Test EII UI tests with prefer-dynamic
Tracking issue: rust-lang/rust#125418
Remove `no-prefer-dynamic` from the EII UI tests now that rust-lang/rust#153648 fixed exporting EII declaration aliases from dylibs.
Fixesrust-lang/rust#151271.
Tested with:
```sh
python3 x.py test tests/ui/eii --force-rerun
```
The linker will complain about undefined symbols otherwise and on object
file formats with two level namespaces (Mach-O and PE/COFF) it is
required to know which dylib a symbol will be imported from when linking
a dylib or executable.
Fix ICE when combining #[eii] with #[core::contracts::ensures]
Fixesrust-lang/rust#153745
Builtin attribute macros like #[eii] generate AST items programmatically without collected tokens. When another attribute macro was present on the same item, the compiler would panic in TokenStream::from_ast() trying to tokenize the generated items during subsequent attribute expansion.
Generate fake token streams (via pretty-print and re-parse) for Item and ForeignItem nodes that lack collected tokens, following the existing pattern used for Crate and out-of-line modules.
The previous test used `fn implementation() {}` with a body, which caused
`generate_default_impl` to generate a `const _: () = { fn implementation() {} }`
item containing `self::implementation`. On Linux (aarch64-gnu-llvm-21), the
resolver's `suggest_ident_hidden_by_hygiene` emitted an extra help span on the
resulting E0425 error that did not appear on macOS, causing a stderr mismatch.
Switch the declaration to `fn implementation();` (no body) so that
`generate_default_impl` is not called and no `self::implementation` path is
emitted. The test still validates that `#[eii]` + `#[core::contracts::ensures]`
produces graceful errors instead of an ICE, via the two contract-annotation
errors on the generated foreign item.
When a function has `eii_impls` set (via `eii_shared_macro`), the `#[hello]`
attribute is consumed from `node.attrs()`. A subsequent `AttrProcMacro` expander
like `contracts::requires` calls `item.to_tokens()` which uses the current
`node.attrs()` — so `#[hello]` is missing from the token stream. After the
roundtrip and `parse_ast_fragment`, the new AST item has empty `eii_impls`
and the EII link is broken.
Fix this by using `fake_token_stream_for_item` when the item is a function
with non-empty `eii_impls`. The pretty-printer re-emits `eii_impls` as
`#[hello]` in `print_fn_full`, which survives the roundtrip and gets
re-expanded by `eii_shared_macro` on the resulting item.
Add a run-pass test to verify EII + contract annotation works correctly
at runtime.
Builtin attribute macros like #[eii] generate AST items
programmatically without collected tokens. When another attribute macro
was present on the same item, the compiler would panic in
TokenStream::from_ast() trying to tokenize the generated items during
subsequent attribute expansion.
Generate fake token streams (via pretty-print and re-parse) for Item
and ForeignItem nodes that lack collected tokens, following the
existing pattern used for Crate and out-of-line modules.
Remove "failed to resolve" and use the same format we use in other resolution errors "cannot find `name`".
```
error[E0433]: cannot find `nonexistent` in `existent`
--> $DIR/custom_attr_multisegment_error.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ could not find `nonexistent` in `existent`
```
Disallow eii in statement position
With how v2 macros resolve, and the name resolution of `super` works, I realized with @WaffleLapkin that there's actually no way to consistently expand EIIs in statement position.
r? @WaffleLapkin
move eii tests
Just a little housekeeping. This feature is getting a lot of tests, so it felt good to put some tests for type checking in its own folder to organise a little. Should be trivial!
Jonathan Brouwer