Migrate rustc_driver to SessionDiagnostic
First timer noob here 👋🏽 I'm having a problem understanding how I can retrieve the span, and how to properly construct the error structs to avoid the current compilation errors.
Any help pointing me in the right direction would be much appreciated 🙌🏽
Migrate `rustc_ty_utils` to `SessionDiagnostic`
I have migrated the `rustc_ty_utils` crate to use `SessionDiagnostic`, motivated by the [recent blog post about the diagnostic translation effort](https://blog.rust-lang.org/inside-rust/2022/08/16/diagnostic-effort.html).
This is my first PR to the Rust repository, so if I have missed anything, or anything needs to be changed, please let me know! 😄
`@rustbot` label +A-translation
Migrate ast lowering to session diagnostic
I migrated the whole rustc_ast_lowering crate to session diagnostic *except* the for the use of `span_fatal` at /compiler/rustc_ast_lowering/src/expr.rs#L1268 because `#[fatal(...)]` is not yet supported (see https://github.com/rust-lang/rust/pull/100694).
Migrate `rustc_plugin_impl` to `SessionDiagnostic`
Migration of the `rustc_plugin_impl` crate.
~Draft PR because it is blocked on #100694 for `#[fatal(...)]` support~ (this has been merged, and I've changed over to `#[diag(...)]` now too), but I would also like to know if what I did with `LoadPluginError` is okay, because all it does is display the error message from `libloading` ([See conversation on zulip](https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/.23100717.20diagnostic.20translation/near/294327843)). This crate is apparently for a deprecated feature which is used by servo, so I don't know how much this matters anyway.
Update cargo
3 commits in efd4ca3dc0b89929dc8c5f5c023d25978d76cb61..9809f8ff33c2b998919fd0432c626f0f7323697a
2022-08-12 01:28:28 +0000 to 2022-08-16 22:10:06 +0000
- Improve error message for an array value in the manifest (rust-lang/cargo#10944)
- Fix file locking being not supported on Android raising an error (rust-lang/cargo#10975)
- Bump to 0.66.0, update changelog (rust-lang/cargo#10983)
Migrate emoji identifier diagnostics to `SessionDiagnostic` in rustc_interface
* Migrate emoji identifier diagnostics to `interface_ferris_identifier` and `interface_emoji_identifier`.
This is my first PR! I'm learning how to migrate these diagnostics. Thanks in advance.
r? rust-lang/diagnostics
Update cargo
8 commits in ce40690a5e4e315d3dab0aae1eae69d0252c52ac..efd4ca3dc0b89929dc8c5f5c023d25978d76cb61
2022-08-09 22:32:17 +0000 to 2022-08-12 01:28:28 +0000
- Use `std:🧵:scope` to replace crossbeam (rust-lang/cargo#10977)
- [docs] Remove extra "in" from `cargo-test.md` (rust-lang/cargo#10978)
- Enable two windows tests (rust-lang/cargo#10930)
- Improve error msg for get target runner (rust-lang/cargo#10968)
- Ensure rustc-echo-wrapper works with an overridden build.target-dir (rust-lang/cargo#10962)
- Switch back to `available_parallelism` (rust-lang/cargo#10969)
- Only override published resolver when the workspace is different (rust-lang/cargo#10961)
- Add `CARGO_LOG` to "Environment variables Cargo reads" (rust-lang/cargo#10967)
compiletest: use target cfg instead of hard-coded tables
This changes compiletest to use `rustc --print=cfg` to dynamically determine the properties of a target when matching `ignore` and `only` rules instead of using hard-coded tables or target-triple parsing (which don't always follow the `<arch><sub>-<vendor>-<sys>-<abi>` pattern). The benefit here is that it will more accurately match the target properties, and not require maintaining these extra tables.
This also adds matching the `target_family` in ignore rules. The primary benefit here is so that `ignore-wasm` works as expected (matching all wasm-like targets). There were already several tests that had `ignore-wasm` in them (which previously had no effect), so it is evident that some people expected that to work. This also adds `ignore-unix/only-unix`.
There is some risk that this changes the behavior from before since the tables aren't quite the same as the target properties. However, I did fairly extensive comparisons to see what would be different. https://gist.github.com/ehuss/5bf7ab347605160cefb6f84ba5ea5f6b contains a full list of differences for all targets for all tests. I do not think any of the affected target/test combinations are things that are actually tested in CI. I tested several of the more unusual test images (test-various, dist-various-1, wasm32), and they seem fine.
A summary of most of the reasons behind the differences:
- wasm64-unknown-unknown wasm32-wasi now match "wasm"
- Targets now match "gnu" because they have target_env=gnu
- aarch64-wrs-vxworks
- armv7-wrs-vxworks-eabihf
- i686-wrs-vxworks
- powerpc-wrs-vxworks
- powerpc64-wrs-vxworks
- x86_64-wrs-vxworks
- wasm64-unknown-unknown now matches wasm64
- x86_64-unknown-none-linuxkernel no longer matches "linux", but will match "gnu" and "none"
- Various arm targets now match "aarch64" or "arm":
- arm64_32-apple-watchos
- armebv7r-none-eabi
- armv6-unknown-freebsd
- armv6-unknown-netbsd-eabihf
- armv6k-nintendo-3ds
- armv7-wrs-vxworks-eabihf
- armv7a-kmc-solid_asp3-eabi
- armv7a-kmc-solid_asp3-eabihf
- armv7a-none-eabi
- armv7a-none-eabihf
- armv7k-apple-watchos
- armv7r-none-eabi
- armv7r-none-eabihf
- Now matches "thumb" and "arm"
- thumbv4t-none-eabi
- thumbv6m-none-eabi
- thumbv7a-pc-windows-msvc
- thumbv7a-uwp-windows-msvc
- thumbv7em-none-eabi
- thumbv7em-none-eabihf
- thumbv7m-none-eabi
- thumbv7neon-linux-androideabi
- thumbv7neon-unknown-linux-gnueabihf
- thumbv7neon-unknown-linux-musleabihf
- thumbv8m.base-none-eabi
- thumbv8m.main-none-eabi
- asmjs-unknown-emscripten now matches "wasm32" because that it is its defined arch
- avr-unknown-gnu-atmega328 now matches "none" (because target_os="none")
- now matches 64bit:
- bpfeb-unknown-none
- bpfel-unknown-none
- sparcv9-sun-solaris
- now matches endian-big:
- m68k-unknown-linux-gnu
- now matches 16bit:
- msp430-none-elf
- now matches 32bit:
- arm64_32-apple-watchos
- now matches riscv32 (and needs-asm-support):
- riscv32gc-unknown-linux-gnu
- riscv32gc-unknown-linux-musl
- riscv32i-unknown-none-elf
- riscv32im-unknown-none-elf
- riscv32imac-unknown-none-elf
- riscv32imac-unknown-xous-elf
- riscv32imc-esp-espidf
- riscv32imc-unknown-none-elf
- riscv64imac-unknown-none-elf
Implement `#[rustc_default_body_unstable]`
This PR implements a new stability attribute — `#[rustc_default_body_unstable]`.
`#[rustc_default_body_unstable]` controls the stability of default bodies in traits.
For example:
```rust
pub trait Trait {
#[rustc_default_body_unstable(feature = "feat", isssue = "none")]
fn item() {}
}
```
In order to implement `Trait` user needs to either
- implement `item` (even though it has a default implementation)
- enable `#![feature(feat)]`
This is useful in conjunction with [`#[rustc_must_implement_one_of]`](https://github.com/rust-lang/rust/pull/92164), we may want to relax requirements for a trait, for example allowing implementing either of `PartialEq::{eq, ne}`, but do so in a safe way — making implementation of only `PartialEq::ne` unstable.
r? `@Aaron1011`
cc `@nrc` (iirc you were interested in this wrt `read_buf`), `@danielhenrymantilla` (you were interested in the related `#[rustc_must_implement_one_of]`)
P.S. This is my first time working with stability attributes, so I'm not sure if I did everything right 😅
Rollup of 5 pull requests
Successful merges:
- #100071 (deps: dedupe `annotate-snippets` crate versions)
- #100127 (Remove Windows function preloading)
- #100130 (Avoid pointing out `return` span if it has nothing to do with type error)
- #100169 (Optimize `pointer::as_aligned_to`)
- #100175 (ascii -> ASCII in code comment)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Bump cc version in bootstrap
Among other changes, the newer cc release pulls in this fix:
b2792e33ff
This fixes errors when building compiler_builtins for UEFI targets.
Eric Huss