https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.74.0 2023-09-13T15:00:31+00:00 2023-09-13T15:00:31+00:00 Matthew Jasper mjjasper1@gmail.com 2023-09-13T15:00:31+00:00 urn:sha1:e324a59eb6ba1a7883bf23ff42d425ca96960f2a - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name 2023-09-11T16:17:06+00:00 Matthew Jasper mjjasper1@gmail.com 2023-09-11T16:16:59+00:00 urn:sha1:b011a0a13b4354080b3add0bb3f4445ddb8fd13b Previously some invalid let expressions would result in both a feature error and a parsing error. Avoid this and ensure that we only emit the parsing error when this happens. 2023-09-11T15:51:18+00:00 Matthew Jasper mjjasper1@gmail.com 2023-09-08T10:14:36+00:00 urn:sha1:333388fd3c9fa03362a3c2a2675ab521c4ddb1ff There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions. 2023-08-28T09:31:45+00:00 Matthew Jasper mjjasper1@gmail.com 2023-08-28T09:31:45+00:00 urn:sha1:89235fd8379d6b1b0bcea704e162ba3d314906da This is consistent with normal match guards. 2023-08-19T11:11:16+00:00 John Kåre Alsaker john.kare.alsaker@gmail.com 2023-08-19T10:55:01+00:00 urn:sha1:1e87ef66f4695d650672c8db0f60128f5024df18 2023-08-18T06:50:41+00:00 Nicholas Nethercote n.nethercote@gmail.com 2023-08-15T00:35:42+00:00 urn:sha1:9167eea553d00a790c10ebc0a821e3fa1b13d93c 2023-08-18T06:50:41+00:00 Nicholas Nethercote n.nethercote@gmail.com 2023-08-14T23:01:22+00:00 urn:sha1:dee6c9241f7402b5122266f8f59f6b731678b50a It's much more complicated than it needs to be, and it doesn't modify the expression. We can do the `Result` handling outside of it, and change it to just return a span. Also fix an errant comma that makes the comment hard to read. 2023-08-04T19:31:57+00:00 Matthias Krüger matthias.krueger@famsik.de 2023-08-04T19:31:57+00:00 urn:sha1:99e4127d8506656b0a414728a809e64e3414886c Improve spans for indexing expressions fixes #114388 Indexing is similar to method calls in having an arbitrary left-hand-side and then something on the right, which is the main part of the expression. Method calls already have a span for that right part, but indexing does not. This means that long method chains that use indexing have really bad spans, especially when the indexing panics and that span in coverted into a panic location. This does the same thing as method calls for the AST and HIR, storing an extra span which is then put into the `fn_span` field in THIR. r? compiler-errors 2023-08-04T11:17:39+00:00 Nilstrieb 48135649+Nilstrieb@users.noreply.github.com 2023-08-03T19:43:17+00:00 urn:sha1:5706be1854db74d0aafcc4658423884689f139e9 Indexing is similar to method calls in having an arbitrary left-hand-side and then something on the right, which is the main part of the expression. Method calls already have a span for that right part, but indexing does not. This means that long method chains that use indexing have really bad spans, especially when the indexing panics and that span in coverted into a panic location. This does the same thing as method calls for the AST and HIR, storing an extra span which is then put into the `fn_span` field in THIR. 2023-08-03T15:29:07+00:00 Matthias Krüger matthias.krueger@famsik.de 2023-08-03T15:29:07+00:00 urn:sha1:51d1dacdc20d83cc4573d4f6226f422a3e725672 Suggests turbofish in patterns Fixes #114112 r? ```@estebank```