David Wood
David Wood
Sure, we can leave that to a follow-up. @bors r+ rollup=never (likely to conflict with other translation pull requests)
@bors r+ p=1 (this will conflict with a lot of other pull requests)
> @davidtwco How would I untangle `emit_ffi_unsafe_type_lint` and `FfiResult`? Would I only modify `emit_ffi_unsafe_type_lint`, create separate `LintDiagnostic` types for each lint, or just leave it? I think `emit_ffi_unsafe_type_lint`/`FfiResult` might be...
> @davidtwco How would I migrate usages of `struct_lint` and `struct_lint_level` in `levels.rs`? We have `emit_spanned_lint` and `#[derive(LintDiagnostic)]` - I think that covers what you need for `struct_lint`? `struct_lint_level` might...
> @davidtwco There's no `emit_spanned_lint` for `LintLevelsBuilder`, should I add one? For `struct_lint_level`, in `levels.rs`, it only uses `LintLevelsBuilder.sess` for the `Session` and `LintLevelsBuilder.lint_level(..)` or `LintLevelsBuilder.provider.get_lint_level(..)` for the `Level` and...
> @davidtwco Also, should I make a new PR for refactoring the diagnostic structs in `errors.rs` since I've gotten more accustomed to migrating them, or can I add them to...
> @davidtwco Mostly the diagnostics in `levels.rs`. All of them are either `struct_lint` (one instance) or `struct_lint_level` (6 instances). > There's a usage of `struct_lint` in `context.rs` at line 1013,...
> @davidtwco Is it fine to leave the other diagnostics in `builtin.rs` without Diagnostic structs? Also, the `rustc::diagnostic_outside_of_impl` and `rustc::untranslatable_diagnostic` don't seem to work since #101986. Apologies for the delay...