{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":24516823,"defaultBranch":"main","name":"dart_style","ownerLogin":"dart-lang","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2014-09-26T22:04:21.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/1609975?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1724892523.0","currentOid":""},"activityList":{"items":[{"before":"7ec041ae87173b8b1b5522f673f7a2a36f6c69fd","after":null,"ref":"refs/heads/import-as-and-if","pushedAt":"2024-08-29T00:48:43.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"}},{"before":"1101f6559ec30e9ce7e19e64c2523f0fdf5c4803","after":"953ecbc02d368793558f8ca9a7519d134e8e4190","ref":"refs/heads/main","pushedAt":"2024-08-29T00:48:42.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"Correctly format imports with both `as` and `if` clauses. (#1550)\n\nIt would output the `as` clause after the `if` clauses, which isn't\r\nsyntactically valid. Apparently no one has ever had a conditional import\r\nwith as prefix because this was a bug in both the old and new\r\nformatters and has been a bug in the old formatter forever.\r\n\r\nFix #1544.","shortMessageHtmlLink":"Correctly format imports with both as and if clauses. (#1550)"}},{"before":"4a61a265a892486315589b823d0072aee32211ee","after":null,"ref":"refs/heads/1533-regression","pushedAt":"2024-08-29T00:38:51.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"}},{"before":"05d08d928bb850888144cbe7b2f3b72d24fccb92","after":"1101f6559ec30e9ce7e19e64c2523f0fdf5c4803","ref":"refs/heads/main","pushedAt":"2024-08-29T00:38:49.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"Add regression test for #1533. (#1549)\n\nThis was fixed by #1548.\r\n\r\nFix #1533.","shortMessageHtmlLink":"Add regression test for #1533. (#1549)"}},{"before":null,"after":"7ec041ae87173b8b1b5522f673f7a2a36f6c69fd","ref":"refs/heads/import-as-and-if","pushedAt":"2024-08-28T23:45:08.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"Correctly format imports with both `as` and `if` clauses.\n\nIt would output the `as` clause after the `if` clauses, which isn't\nsyntactically valid. Apparently no one has ever had a conditional import\nwith as prefix because this was a bug in both the old and new\nformatters and has been a bug in the old formatter forever.\n\nFix #1544.","shortMessageHtmlLink":"Correctly format imports with both as and if clauses."}},{"before":null,"after":"4a61a265a892486315589b823d0072aee32211ee","ref":"refs/heads/1533-regression","pushedAt":"2024-08-28T23:36:00.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"Add regression test for #1533.\n\nThis was fixed by #1548.\n\nFix #1533.","shortMessageHtmlLink":"Add regression test for #1533."}},{"before":"210b073276b1edd800ca245d6e2915f639567717","after":null,"ref":"refs/heads/tweak-block-argument-heuristics","pushedAt":"2024-08-28T23:26:00.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"}},{"before":"494a1d71a6d95964cc11bb590d38f90380defd24","after":"05d08d928bb850888144cbe7b2f3b72d24fccb92","ref":"refs/heads/main","pushedAt":"2024-08-28T23:25:59.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"Tweak block argument heuristics (#1548)\n\nChange the block format heuristics.\r\n\r\nThis produces output that better matches what users expected in the associated issues. I think it also looks better in the affected regression tests. And I ran this on a large corpus and looking at the diffs, these rules seem to be much better across the board.\r\n\r\nThe new rules are basically:\r\n\r\n* A block formatted argument list can't end up with named arguments on multiple lines.\r\n\r\n* Only one trailing argument is allowed after the block argument.\r\n\r\nThe existing rules are also kept:\r\n\r\n* Prefer a function block argument over a collection one.\r\n\r\n* Only allow a single block argument.\r\n\r\n* Allow the first argument to be adjacent strings with a later function block argument (to handle stuff like test() and group()).\r\n\r\nFix #1527.\r\nFix #1528.\r\nFix #1543.","shortMessageHtmlLink":"Tweak block argument heuristics (#1548)"}},{"before":null,"after":"210b073276b1edd800ca245d6e2915f639567717","ref":"refs/heads/tweak-block-argument-heuristics","pushedAt":"2024-08-28T01:15:54.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"Change the block format heuristics.\n\nThis produces output that better matches what users expected in the associated issues. I think it also looks better in the affected regression tests. And I ran this on a large corpus and looking at the diffs, these rules seem to be much better across the board.\n\nThe new rules are basically:\n\n* A block formatted argument list can't end up with named arguments on multiple lines.\n\n* Only one trailing argument is allowed after the block argument.\n\nThe existing rules are also kept:\n\n* Prefer a function block argument over a collection one.\n\n* Only allow a single block argument.\n\n* Allow the first argument to be adjacent strings with a later function block argument (to handle stuff like test() and group()).\n\nFix #1527.\nFix #1528.\nFix #1543.","shortMessageHtmlLink":"Change the block format heuristics."}},{"before":"58e96a99e0f01047010e3977bf5eb700e701aeab","after":"494a1d71a6d95964cc11bb590d38f90380defd24","ref":"refs/heads/main","pushedAt":"2024-08-27T23:33:50.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"stereotype441","name":"Paul Berry","path":"/stereotype441","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/306375?s=80&v=4"},"commit":{"message":"Delete unreachable `default` clause. (#1547)\n\nThe Dart analyzer will soon be changed so that if the `default` clause\r\nof a `switch` statement is determined to be unreachable by the\r\nexhaustiveness checker, a new warning of type\r\n`unreachable_switch_default` will be issued. This parallels the\r\nbehavior of the existing `unreachable_switch_case` warning, which is\r\nissued whenever a `case` clause of a `switch` statement is determined\r\nto be unreachable.\r\n\r\nThis PR deletes an unreachable `default` clause from `dart_style` now,\r\nto avoid a spurious warning when the analyzer change lands.","shortMessageHtmlLink":"Delete unreachable default clause. (#1547)"}},{"before":"2c3c58efbedfc7498063c493ebedc6b8998c2f47","after":null,"ref":"refs/heads/large-regression","pushedAt":"2024-08-21T18:41:48.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"}},{"before":"80ecef5014f87da9ffbb8fb22e624d5628a6c874","after":"58e96a99e0f01047010e3977bf5eb700e701aeab","ref":"refs/heads/main","pushedAt":"2024-08-21T18:41:46.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"Add a regression test for a large statement. (#1546)\n\nThis is a sanitized statement from internal code that was causing the\r\nold formatter to choke.","shortMessageHtmlLink":"Add a regression test for a large statement. (#1546)"}},{"before":null,"after":"2c3c58efbedfc7498063c493ebedc6b8998c2f47","ref":"refs/heads/large-regression","pushedAt":"2024-08-21T00:44:00.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"Add a regression test for a large statement.\n\nThis is a sanitized statement from internal code that was causing the\nold formatter to choke.","shortMessageHtmlLink":"Add a regression test for a large statement."}},{"before":"2db57d2509d47d12f8f59e48012135abe5296819","after":null,"ref":"refs/heads/block-format-await","pushedAt":"2024-08-19T21:09:50.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"}},{"before":"5749a942237423cd8223ed4e89e818a1f71da5e5","after":"80ecef5014f87da9ffbb8fb22e624d5628a6c874","ref":"refs/heads/main","pushedAt":"2024-08-19T21:09:49.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"Block-format await expressions if the inner expression allows it. (#1538)\n\nBlock-format await expressions if the inner expression allows it.\r\n\r\nIn assignment-like context, if the RHS is an await expression and the\r\ninner expression can be block formatted, then let the whole await\r\nexpression be block formatted.\r\n\r\nThis comes into play in assignments, but not in argument lists which are\r\nthe other place where block formatting is a thing. That's because in\r\nargument lists, we *don't* treat function calls as block formattable.\r\n(This is both for performance and style reasons). There's no point in\r\nawaiting any of the other kinds of block-formattable expressions:\r\ncollection literals or function expressions.\r\n\r\nSo this really just benefits assignments, named argument expressions,\r\nand `=>` bodies. But it definitely makes those look better.\r\n\r\nFix #1531.","shortMessageHtmlLink":"Block-format await expressions if the inner expression allows it. (#1538"}},{"before":"50d440347897e0593502881eb962a21865b90f5f","after":null,"ref":"refs/heads/always-split-switch-expressions","pushedAt":"2024-08-19T18:42:24.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"}},{"before":"02d5bc2a34a1a6bdc23db24777dddc8001ce8407","after":"5749a942237423cd8223ed4e89e818a1f71da5e5","ref":"refs/heads/main","pushedAt":"2024-08-19T18:42:22.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"Always split switch expressions (#1537)\n\nAlways split switch expressions.\r\n\r\nI figured that since other comma-delimited expression forms don't split\r\nif they don't have to, switch expressions should be the same. But I\r\nwent and checked on a huge corpus and every single place where a switch\r\nexpression wasn't split was clearly much worse than splitting it would\r\nbe.\r\n\r\nFix #1529.","shortMessageHtmlLink":"Always split switch expressions (#1537)"}},{"before":"72b016fb4f6180adc1091ecba5f6729e2b2e9907","after":"2db57d2509d47d12f8f59e48012135abe5296819","ref":"refs/heads/block-format-await","pushedAt":"2024-08-17T01:09:14.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"Add regression test.","shortMessageHtmlLink":"Add regression test."}},{"before":null,"after":"72b016fb4f6180adc1091ecba5f6729e2b2e9907","ref":"refs/heads/block-format-await","pushedAt":"2024-08-17T01:01:38.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"Block-format await expressions if the inner expression allows it.\n\nIn assignment-like context, if the RHS is an await expression and the\ninner expression can be block formatted, then let the whole await\nexpression be block formatted.\n\nThis comes into play in assignments, but not in argument lists which are\nthe other place where block formatting is a thing. That's because in\nargument lists, we *don't* treat function calls as block formattable.\n(This is both for performance and style reasons). There's no point in\nawaiting any of the other kinds of block-formattable expressions:\ncollection literals or function expressions.\n\nSo this really just benefits assignments, named argument expressions,\nand `=>` bodies. But it definitely makes those look better.\n\nFix #1531.","shortMessageHtmlLink":"Block-format await expressions if the inner expression allows it."}},{"before":"c8081440660ef19b0177f2a9c1f0214fb19d4e22","after":"50d440347897e0593502881eb962a21865b90f5f","ref":"refs/heads/always-split-switch-expressions","pushedAt":"2024-08-17T00:33:18.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"Fix regression test.","shortMessageHtmlLink":"Fix regression test."}},{"before":null,"after":"c8081440660ef19b0177f2a9c1f0214fb19d4e22","ref":"refs/heads/always-split-switch-expressions","pushedAt":"2024-08-17T00:32:26.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"Always split switch expressions.\n\nI figured that since other comma-delimited expression forms don't split\nif they don't have to, switch expressions should be the same. But I\nwent and checked on a huge corpus and every single place where a switch\nexpression wasn't split was clearly much worse than splitting it would\nbe.\n\nFix #1529.","shortMessageHtmlLink":"Always split switch expressions."}},{"before":"bc95fd894517911fdc2013e86a3212bd263fade8","after":null,"ref":"refs/heads/split-after-arrow","pushedAt":"2024-08-15T19:24:03.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"}},{"before":"92b2fa8c6499b4ae2ad82dff418c9f48c117be0e","after":"02d5bc2a34a1a6bdc23db24777dddc8001ce8407","ref":"refs/heads/main","pushedAt":"2024-08-15T19:24:01.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"When the RHS of `=>` is a function call, prefer to split at the `=>`. (#1523)\n\nWe use the same AssignPiece rule for `=`, `=>`, and `:`. And that rule uniformly handles all kinds of block-formattable right hand sides: collection literals, switch expressions, and function calls. For the most part, that works well and provides nice consistent formatting. Users generally like:\r\n\r\n```dart\r\n// Better:\r\nvariable = [\r\n long,\r\n list,\r\n literal,\r\n];\r\n\r\n// Worse:\r\nvariable =\r\n [long, list, literal];\r\n```\r\n\r\nAnd:\r\n\r\n```dart\r\n// Better:\r\nSomeWidget(\r\n children: [\r\n long,\r\n list,\r\n literal,\r\n ],\r\n);\r\n\r\n// Worse:\r\nSomeWidget(\r\n children:\r\n [long, list, literal],\r\n);\r\n```\r\n\r\nAnd (with somewhat less consensus):\r\n\r\n```dart\r\n// Better:\r\nvariable = function(\r\n long,\r\n argument,\r\n list,\r\n);\r\n\r\n// Worse:\r\nvariable =\r\n function(long, argument, list);\r\n```\r\n\r\nAlso, users have long requested and seem to like:\r\n\r\n```dart\r\n// Better:\r\nclass C {\r\n List makeStuff() => [\r\n long,\r\n list,\r\n literal,\r\n ];\r\n}\r\n\r\n// Worse:\r\nclass C {\r\n List makeStuff() =>\r\n [long, list, literal];\r\n}\r\n```\r\n\r\nSo based on all that, I just used uniform rules for all combinations of assignment constructs and delimited constructs. That means that this behavior falls out implicitly:\r\n\r\n```dart\r\n// Better:\r\nclass C {\r\n String doThing() => function(\r\n long,\r\n argument,\r\n list,\r\n );\r\n}\r\n\r\n// Worse:\r\nclass C {\r\n String doThing() =>\r\n function(long, argument, list);\r\n}\r\n```\r\n\r\nBut it turns out that that particular combination of `=>` with a function call on the right doesn't get the same user sentiment. Instead, most (including me) prefer:\r\n\r\n```dart\r\nclass C {\r\n String doThing() =>\r\n function(long, argument, list);\r\n}\r\n```\r\n\r\nI think it's because this keeps the function name next to its arguments. With the other block-like forms: list literals, etc. there isn't really anything particularly interesting going on in the opening delimiter, so it makes sense to keep it on the same line as the `=>` since it's pretty much just punctuation. But a function call is a single coherent operation including the function and its arguments.\r\n\r\nSo this PR tweaks the cost rule for AssignPiece. When the operator is `=>` and the RHS is a function call, we prefer to split at the `=>` if that lets the RHS stay unsplit.","shortMessageHtmlLink":"When the RHS of => is a function call, prefer to split at the =>. ("}},{"before":"f9a5617ef2f9feb3aa14c7324889b2d95f5f1d1d","after":null,"ref":"refs/heads/empty-unit","pushedAt":"2024-08-14T21:21:52.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"}},{"before":"dd1f7d9695782111da03fee53dba531d114b13ef","after":"92b2fa8c6499b4ae2ad82dff418c9f48c117be0e","ref":"refs/heads/main","pushedAt":"2024-08-14T21:21:50.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"Don't crash when formatting an empty source file. (#1524)\n\n(Strangely, yes, I found several of these in the wild on pub.)","shortMessageHtmlLink":"Don't crash when formatting an empty source file. (#1524)"}},{"before":"472d013ebf3e42c0d5a6bac73aa6fa2a264decb0","after":null,"ref":"refs/heads/disable-region","pushedAt":"2024-08-14T21:18:17.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"}},{"before":"8c0e44e0fbce0f625a7cbca479886c1ea0f583d8","after":"dd1f7d9695782111da03fee53dba531d114b13ef","ref":"refs/heads/main","pushedAt":"2024-08-14T21:18:15.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"Allow disabling formatting for a region of code. (#1522)\n\nAllow disabling formatting for a region of code.\r\n\r\nThere are two special line comments:\r\n\r\n```\r\n// dart format off\r\n// dart format on\r\n```\r\n\r\nAny code between those keeps its original formatting completely,\r\nincluding indentation. It just splats the original unformatted code into\r\nthe output.","shortMessageHtmlLink":"Allow disabling formatting for a region of code. (#1522)"}},{"before":"1f59e987e6c49e2f167fa47967f4716bad1cdf69","after":"472d013ebf3e42c0d5a6bac73aa6fa2a264decb0","ref":"refs/heads/disable-region","pushedAt":"2024-08-14T14:25:56.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"Update lib/src/back_end/code.dart\n\nCo-authored-by: Nate Bosch ","shortMessageHtmlLink":"Update lib/src/back_end/code.dart"}},{"before":"393d0a44170652e9a11b924a1052547c76d20257","after":"1f59e987e6c49e2f167fa47967f4716bad1cdf69","ref":"refs/heads/disable-region","pushedAt":"2024-08-14T02:00:45.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"Fix offsets in comment.","shortMessageHtmlLink":"Fix offsets in comment."}},{"before":null,"after":"f9a5617ef2f9feb3aa14c7324889b2d95f5f1d1d","ref":"refs/heads/empty-unit","pushedAt":"2024-08-14T01:58:48.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"munificent","name":"Bob Nystrom","path":"/munificent","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/46275?s=80&v=4"},"commit":{"message":"Don't crash when formatting an empty source file.\n\n(Strangely, yes, I found several of these in the wild on pub.)","shortMessageHtmlLink":"Don't crash when formatting an empty source file."}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEpxIvTgA","startCursor":null,"endCursor":null}},"title":"Activity · dart-lang/dart_style"}