Add lib section to rustc_lexer's Cargo.toml
This is required to fix the rustc-ap-syntax build error in the recent version. The error could also be fixed on the [rustc-auto-publish](https://github.com/alexcrichton/rustc-auto-publish) side by manually adding `[lib]` section if one does not exist. The latter approach, however, may have a surprising side effect, so I am opting for a simpler solution for now.
r? @alexcrichton
Stop bare trait lint applying to macro call sites
Fixes#61963. Apologies for the delay with in fixing this. If anyone has a better idea how to detect this macro call site case, I'd be happy to fix this in a more robust, less hacky way.
r? @estebank
add `repr(transparent)` to `IoSliceMut` where missing
tried using `IoSliceMut` in FFI, got `improper_ctypes` warning.
according to the docs: `IoSliceMut` is "guaranteed to be ABI compatible with the `iovec` type" so it should be usable in FFI.
`IoSlice` is also `repr(transparent)` for every platform where these types contain `iovec`-like types.
vxworks also has `IoSliceMut` as transparent so its not even consistently one or the other.
no comment about this next to the types or in the PR that introduced the types, so assuming this was just missed.
r? @sfackler
Fix cycle error with existential types
Fixes#61863
We now allow uses of `existential type`'s that aren't defining uses - that is, uses which don't constrain the underlying concrete type.
To make this work correctly, we also modify `eq_opaque_type_and_type` to not try to apply additional constraints to an opaque type. If we have code like this:
```rust
existential type Foo;
fn foo1() -> Foo { ... }
fn foo2() -> Foo { foo1() }
```
then `foo2` doesn't end up constraining `Foo`, which means that `foo2` will end up using the type `Foo` internally - that is, an actual `TyKind::Opaque`. We don't want to equate this to the underlying concrete type - we just need to enforce the basic equality constraint between the two types (here, the return type of `foo1` and the return type of `foo2`)
Optimize RefCell read borrowing
Instead of doing two comparisons we can do only one with a bit of cleverness.
LLVM currently can't do this optimization itself on x86-64.
Define built-in macros through libcore
This PR defines built-in macros through libcore using a scheme similar to lang items (attribute `#[rustc_builtin_macro]`).
All the macro properties (stability, visibility, etc.) are taken from the source code in libcore, with exception of the expander function transforming input tokens/AST into output tokens/AST, which is still provided by the compiler.
The macros are made available to user code through the standard library prelude (`{core,std}::prelude::v1`), so they are still always in scope.
As a result **built-in macros now have stable absolute addresses in the library**, like `core::prelude::v1::line!()`, this is an insta-stable change.
Right now `prelude::v1` is the only publicly available absolute address for these macros, but eventually they can be moved into more appropriate locations with library team approval (e.g. `Clone` derive -> `core::clone::Clone`).
Now when built-in macros have canonical definitions they can be imported or reexported without issues (https://github.com/rust-lang/rust/issues/61687).
Other changes:
- You can now define a derive macro with a name matching one of the built-in derives (https://github.com/rust-lang/rust/issues/52269). This was an artificial restriction that could be worked around with import renaming anyway.
Known regressions:
- Empty library crate with a crate-level `#![test]` attribute no longer compiles without `--test`. Previously it didn't compile *with* `--test` or with the bin crate type.
Fixes https://github.com/rust-lang/rust/issues/61687
Fixes https://github.com/rust-lang/rust/issues/61804
r? @eddyb
