https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.77.2 2024-01-30T19:22:04+00:00 2024-01-30T19:22:04+00:00 bors bors@rust-lang.org 2024-01-30T19:22:04+00:00 urn:sha1:cb4d9a1902b3ea17e93872dafb76d24aa6295c47 Normalize region obligation in lexical region resolution with next-gen solver This normalizes region obligations when we `resolve_regions`, since they may be unnormalized with deferred projection equality. It's pretty hard to add tests that exercise this without also triggering MIR borrowck errors (because we don't normalize there yet). I've added one test with two revisions that should test that we both 1. normalize region obligations in the param env, and 2. normalize registered region obligations during lexical region resolution. 2024-01-30T10:19:20+00:00 Guillaume Gomez guillaume1.gomez@gmail.com 2024-01-30T10:19:20+00:00 urn:sha1:f99b510429f90723105d9773f4ca9a6085685c3c Diagnostic lifetimes cleanups Some diagnostic simplifications. r? `@oli-obk` 2024-01-30T07:46:06+00:00 Nicholas Nethercote n.nethercote@gmail.com 2024-01-30T04:27:16+00:00 urn:sha1:5350edb9e8f4e194a2cad9a41b81d97a8ed52fab Because it's almost always static. This makes `impl IntoDiagnosticArg for DiagnosticArgValue` trivial, which is nice. There are a few diagnostics constructed in `compiler/rustc_mir_build/src/check_unsafety.rs` and `compiler/rustc_mir_transform/src/errors.rs` that now need symbols converted to `String` with `to_string` instead of `&str` with `as_str`, but that' no big deal, and worth it for the simplifications elsewhere. 2024-01-30T00:09:58+00:00 Michael Goulet michael@errs.io 2024-01-26T19:18:14+00:00 urn:sha1:720d7a7a03b9997644fe28a12a80a910b2652760 2024-01-30T00:06:53+00:00 Michael Goulet michael@errs.io 2023-12-25T21:37:29+00:00 urn:sha1:fef38a6337c6acf14eb70bf013717f484aa57eec 2024-01-29T12:56:53+00:00 Dylan DPC 99973273+Dylan-DPC@users.noreply.github.com 2024-01-29T12:56:53+00:00 urn:sha1:549eeb077d482734f623c3769333fed71e1e7fca Borrow check inline const patterns Add type annotations to MIR so that borrowck can pass constraints from inline constants in patterns to the containing function. Also enables some inline constant pattern tests that were fixed by the THIR unsafeck stabilization. cc #76001 2024-01-29T09:17:00+00:00 Matthew Jasper mjjasper1@gmail.com 2024-01-26T13:23:55+00:00 urn:sha1:83fa46fe5bcf8324aaa0614212080486623d672b Add type annotations to MIR so that borrowck can pass constraints from inline constants in patterns to the containing function. 2024-01-28T20:41:41+00:00 Nicholas Nethercote n.nethercote@gmail.com 2024-01-13T23:57:07+00:00 urn:sha1:5d9dfbd08f38c2a9bc71d39de8f5c7776afe0f9e Error codes are integers, but `String` is used everywhere to represent them. Gross! This commit introduces `ErrCode`, an integral newtype for error codes, replacing `String`. It also introduces a constant for every error code, e.g. `E0123`, and removes the `error_code!` macro. The constants are imported wherever used with `use rustc_errors::codes::*`. With the old code, we have three different ways to specify an error code at a use point: ``` error_code!(E0123) // macro call struct_span_code_err!(dcx, span, E0123, "msg"); // bare ident arg to macro call \#[diag(name, code = "E0123")] // string struct Diag; ``` With the new code, they all use the `E0123` constant. ``` E0123 // constant struct_span_code_err!(dcx, span, E0123, "msg"); // constant \#[diag(name, code = E0123)] // constant struct Diag; ``` The commit also changes the structure of the error code definitions: - `rustc_error_codes` now just defines a higher-order macro listing the used error codes and nothing else. - Because that's now the only thing in the `rustc_error_codes` crate, I moved it into the `lib.rs` file and removed the `error_codes.rs` file. - `rustc_errors` uses that macro to define everything, e.g. the error code constants and the `DIAGNOSTIC_TABLES`. This is in its new `codes.rs` file. 2024-01-25T14:01:33+00:00 clubby789 jamie@hill-daniel.co.uk 2024-01-14T20:08:47+00:00 urn:sha1:fd29f74ff8d787f707a40bc5dbcd8f7827100f5e 2024-01-23T11:56:30+00:00 bors bors@rust-lang.org 2024-01-23T11:56:30+00:00 urn:sha1:0e4243538b9119654c22dce688f8a63c81864de9 Only use dense bitsets in dataflow analyses When a dataflow state has the size close to the number of locals, we should prefer a dense bitset, like we already store locals in a dense vector. Other occurrences of `ChunkedBitSet` need to be justified by the size of the dataflow state.