https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.81.0 2024-07-19T18:52:07+00:00 2024-07-19T18:52:07+00:00 Yuri Astrakhan YuriAstrakhan@gmail.com 2024-07-19T15:51:21+00:00 urn:sha1:aef0e346de744faeaa522b9c08562bb3e1814adc Clean up a few minor refs in `format!` macro, as it has a performance cost. Apparently the compiler is unable to inline `format!("{}", &variable)`, and does a run-time double-reference instead (format macro already does one level referencing). Inlining format args prevents accidental `&` misuse. 2024-07-18T09:58:16+00:00 Ralf Jung post@ralfj.de 2024-07-13T16:03:05+00:00 urn:sha1:86ce911f90d9498b33738655c8cfed2f637c335a 2024-07-16T22:02:46+00:00 Nicholas Nethercote n.nethercote@gmail.com 2024-06-20T05:44:13+00:00 urn:sha1:75b6ec980059292faa9cdf538b552faf6b70fb29 There are some comments describing multiple subsequent `use` items. When the big `use` reformatting happens some of these `use` items will be reordered, possibly moving them away from the comment. With this additional level of formatting it's not really feasible to have comments of this type. This commit removes them in various ways: - merging separate `use` items when appropriate; - inserting blank lines between the comment and the first `use` item; - outright deletion (for comments that are relatively low-value); - adding a separate "top-level" comment. We also entirely skip formatting for four library files that contain nothing but `pub use` re-exports, where reordering would be painful. 2024-06-23T09:28:42+00:00 Trevor Gross tmgross@umich.edu 2024-03-26T10:01:09+00:00 urn:sha1:6fb6c19c961369b98e2dd9466c1a83ac2d783ae2 This section of code depends on `rustc_apfloat` rather than our internal types, so this is one potential ICE that we should be able to melt now. This also fixes some missing range and match handling in `rustc_middle`. 2024-06-19T23:23:20+00:00 Nicholas Nethercote n.nethercote@gmail.com 2024-06-19T19:04:30+00:00 urn:sha1:665821cb606076bcf159c47e3e8e72a14fa512e3 Most modules have such a blank line, but some don't. Inserting the blank line makes it clearer that the `//!` comments are describing the entire module, rather than the `use` declaration(s) that immediately follows. 2024-06-12T05:49:10+00:00 Nicholas Nethercote n.nethercote@gmail.com 2024-06-12T03:49:36+00:00 urn:sha1:75b164d836ff82b459dfb05646bf0328dd23d2fd We already do this for a number of crates, e.g. `rustc_middle`, `rustc_span`, `rustc_metadata`, `rustc_span`, `rustc_errors`. For the ones we don't, in many cases the attributes are a mess. - There is no consistency about order of attribute kinds (e.g. `allow`/`deny`/`feature`). - Within attribute kind groups (e.g. the `feature` attributes), sometimes the order is alphabetical, and sometimes there is no particular order. - Sometimes the attributes of a particular kind aren't even grouped all together, e.g. there might be a `feature`, then an `allow`, then another `feature`. This commit extends the existing sorting to all compiler crates, increasing consistency. If any new attribute line is added there is now only one place it can go -- no need for arbitrary decisions. Exceptions: - `rustc_log`, `rustc_next_trait_solver` and `rustc_type_ir_macros`, because they have no crate attributes. - `rustc_codegen_gcc`, because it's quasi-external to rustc (e.g. it's ignored in `rustfmt.toml`). 2024-06-10T11:43:16+00:00 Ralf Jung post@ralfj.de 2024-06-08T14:13:45+00:00 urn:sha1:3c57ea0df79c8ee2ad1ff99881f80ab87b186935 2024-06-05T21:25:41+00:00 Boxy supbscripter@gmail.com 2024-06-03T03:46:24+00:00 urn:sha1:60a5bebbe591f228bf83f3c48f5f60fe87dedaad 2024-05-23T02:08:35+00:00 León Orell Valerian Liehr me@fmease.dev 2024-05-22T14:46:05+00:00 urn:sha1:06bc4fc67145e3a7be9b5a2cf2b5968cef36e587 * instead simply set the primary message inside the lint decorator functions * it used to be this way before [#]101986 which introduced `msg` to prevent good path delayed bugs (which no longer exist) from firing under certain circumstances when lints were suppressed / silenced * this is no longer necessary for various reasons I presume * it shaves off complexity and makes further changes easier to implement 2024-05-02T23:42:31+00:00 Ross Smyth 18294397+RossSmyth@users.noreply.github.com 2024-04-28T00:35:32+00:00 urn:sha1:6967d1c0fcea4ade223bf3ae443a87d504005cbf