https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.78.0 2024-03-13T08:11:16+00:00 2024-03-13T08:11:16+00:00 bohan bohan-zhang@foxmail.com 2024-03-12T02:55:17+00:00 urn:sha1:8fcdf54a6b98c129e951caf3a97cbf20db677ee3 2024-03-05T01:15:10+00:00 Nicholas Nethercote n.nethercote@gmail.com 2024-02-29T05:40:44+00:00 urn:sha1:7aa0eea19caee96c9c811105b3df610e2759dd49 Not the dropping of the trailing `s` -- this type describes a single diagnostic and its name should be singular. 2024-02-27T21:55:35+00:00 Nicholas Nethercote n.nethercote@gmail.com 2024-02-22T23:20:45+00:00 urn:sha1:899cb40809a85eb9d89f6da3268713b83175360a Much better! Note that this involves renaming (and updating the value of) `DIAGNOSTIC_BUILDER` in clippy. 2024-02-25T21:24:31+00:00 Lieselotte 52315535+she3py@users.noreply.github.com 2024-02-25T21:22:11+00:00 urn:sha1:c440a5b814005c85ec903f9b9e44e25bf5c9c565 2024-02-20T13:13:30+00:00 clubby789 jamie@hill-daniel.co.uk 2024-02-13T23:44:33+00:00 urn:sha1:4850ae84422569747901c14169b5ed6dfbfb96a3 2024-01-25T17:12:09+00:00 Oli Scherer git-spam-no-reply9815368754983@oli-obk.de 2024-01-25T17:12:09+00:00 urn:sha1:3042da02485920f5a9d4c4149cc9e2a7d7ef69d0 2024-01-21T23:14:01+00:00 Nicholas Nethercote n.nethercote@gmail.com 2024-01-14T23:40:54+00:00 urn:sha1:1f9fa2305a099cbbf9858e3eb777495a7246e84a We have several methods indicating the presence of errors, lint errors, and delayed bugs. I find it frustrating that it's very unclear which one you should use in any particular spot. This commit attempts to instill a basic principle of "use the least general one possible", because that reflects reality in practice -- `has_errors` is the least general one and has by far the most uses (esp. via `abort_if_errors`). Specifics: - Add some comments giving some usage guidelines. - Prefer `has_errors` to comparing `err_count` to zero. - Remove `has_errors_or_span_delayed_bugs` because it's a weird one: in the cases where we need to count delayed bugs, we should really be counting lint errors as well. - Rename `is_compilation_going_to_fail` as `has_errors_or_lint_errors_or_span_delayed_bugs`, for consistency with `has_errors` and `has_errors_or_lint_errors`. - Change a few other `has_errors_or_lint_errors` calls to `has_errors`, as per the "least general" principle. This didn't turn out to be as neat as I hoped when I started, but I think it's still an improvement. 2024-01-08T04:24:49+00:00 Nicholas Nethercote n.nethercote@gmail.com 2024-01-03T01:17:35+00:00 urn:sha1:b1b9278851a9512a0c934c12f9c1800169c336f7 This works for most of its call sites. This is nice, because `emit` very much makes sense as a consuming operation -- indeed, `DiagnosticBuilderState` exists to ensure no diagnostic is emitted twice, but it uses runtime checks. For the small number of call sites where a consuming emit doesn't work, the commit adds `DiagnosticBuilder::emit_without_consuming`. (This will be removed in subsequent commits.) Likewise, `emit_unless` becomes consuming. And `delay_as_bug` becomes consuming, while `delay_as_bug_without_consuming` is added (which will also be removed in subsequent commits.) All this requires significant changes to `DiagnosticBuilder`'s chaining methods. Currently `DiagnosticBuilder` method chaining uses a non-consuming `&mut self -> &mut Self` style, which allows chaining to be used when the chain ends in `emit()`, like so: ``` struct_err(msg).span(span).emit(); ``` But it doesn't work when producing a `DiagnosticBuilder` value, requiring this: ``` let mut err = self.struct_err(msg); err.span(span); err ``` This style of chaining won't work with consuming `emit` though. For that, we need to use to a `self -> Self` style. That also would allow `DiagnosticBuilder` production to be chained, e.g.: ``` self.struct_err(msg).span(span) ``` However, removing the `&mut self -> &mut Self` style would require that individual modifications of a `DiagnosticBuilder` go from this: ``` err.span(span); ``` to this: ``` err = err.span(span); ``` There are *many* such places. I have a high tolerance for tedious refactorings, but even I gave up after a long time trying to convert them all. Instead, this commit has it both ways: the existing `&mut self -> Self` chaining methods are kept, and new `self -> Self` chaining methods are added, all of which have a `_mv` suffix (short for "move"). Changes to the existing `forward!` macro lets this happen with very little additional boilerplate code. I chose to add the suffix to the new chaining methods rather than the existing ones, because the number of changes required is much smaller that way. This doubled chainging is a bit clumsy, but I think it is worthwhile because it allows a *lot* of good things to subsequently happen. In this commit, there are many `mut` qualifiers removed in places where diagnostics are emitted without being modified. In subsequent commits: - chaining can be used more, making the code more concise; - more use of chaining also permits the removal of redundant diagnostic APIs like `struct_err_with_code`, which can be replaced easily with `struct_err` + `code_mv`; - `emit_without_diagnostic` can be removed, which simplifies a lot of machinery, removing the need for `DiagnosticBuilderState`. 2023-12-23T21:17:47+00:00 Nicholas Nethercote n.nethercote@gmail.com 2023-12-21T05:26:09+00:00 urn:sha1:8a9db2545919f945ffbb215e4325917e0bfc5b3a 2023-12-23T20:24:52+00:00 Nicholas Nethercote n.nethercote@gmail.com 2023-12-18T09:54:03+00:00 urn:sha1:d86a48278f7bcd069a56870a70c6376e77bd4ee5