<feed xmlns='http://www.w3.org/2005/Atom'>
<title>rust/compiler/rustc_parse/src/parser, branch 1.51.0</title>
<subtitle>https://github.com/rust-lang/rust
</subtitle>
<id>http://git.dreamy.place/mirrors/rust/atom?h=1.51.0</id>
<link rel='self' href='http://git.dreamy.place/mirrors/rust/atom?h=1.51.0'/>
<link rel='alternate' type='text/html' href='http://git.dreamy.place/mirrors/rust/'/>
<updated>2021-02-13T15:43:07+00:00</updated>
<entry>
<title>parser: Fix panic in 'const impl' recovery</title>
<updated>2021-02-13T15:43:07+00:00</updated>
<author>
<name>Ömer Sinan Ağacan</name>
<email>omeragacan@gmail.com</email>
</author>
<published>2021-02-08T07:43:54+00:00</published>
<link rel='alternate' type='text/html' href='http://git.dreamy.place/mirrors/rust/commit/?id=853f7875a2258f11b62a6ea386d1ca289bb2a13d'/>
<id>urn:sha1:853f7875a2258f11b62a6ea386d1ca289bb2a13d</id>
<content type='text'>
The panic happens when in recovery parsing a full `impl`
(`parse_item_impl`) fails and we drop the `DiagnosticBuilder` for the
recovery suggestion and return the `parse_item_impl` error.

We now raise the original error "expected identifier found `impl`" when
parsing the `impl` fails.

Note that the regression test is slightly simplified version of the
original repro in #81806, to make the error output smaller and more
resilient to unrelated changes in parser error messages.

Fixes #81806
</content>
</entry>
<entry>
<title>Auto merge of #81405 - bugadani:ast, r=cjgillot</title>
<updated>2021-02-02T17:34:08+00:00</updated>
<author>
<name>bors</name>
<email>bors@rust-lang.org</email>
</author>
<published>2021-02-02T17:34:08+00:00</published>
<link rel='alternate' type='text/html' href='http://git.dreamy.place/mirrors/rust/commit/?id=3182375e064b8fa90437aee1465bccafd8187d89'/>
<id>urn:sha1:3182375e064b8fa90437aee1465bccafd8187d89</id>
<content type='text'>
Box the biggest ast::ItemKind variants

This PR is a different approach on https://github.com/rust-lang/rust/pull/81400, aiming to save memory in humongous ASTs.

The three affected item kind enums are:
 - `ast::ItemKind` (208 -&gt; 112 bytes)
 - `ast::AssocItemKind` (176 -&gt; 72 bytes)
 - `ast::ForeignItemKind` (176 -&gt; 72 bytes)
</content>
</entry>
<entry>
<title>Auto merge of #80843 - Mark-Simulacrum:fmt-bump, r=petrochenkov</title>
<updated>2021-02-02T14:52:53+00:00</updated>
<author>
<name>bors</name>
<email>bors@rust-lang.org</email>
</author>
<published>2021-02-02T14:52:53+00:00</published>
<link rel='alternate' type='text/html' href='http://git.dreamy.place/mirrors/rust/commit/?id=b81f5811f96fe750ab28c15219d1b0dba6b1dc90'/>
<id>urn:sha1:b81f5811f96fe750ab28c15219d1b0dba6b1dc90</id>
<content type='text'>
Bump rustfmt version
</content>
</entry>
<entry>
<title>Bump rustfmt version</title>
<updated>2021-02-02T14:09:52+00:00</updated>
<author>
<name>Mark Rousskov</name>
<email>mark.simulacrum@gmail.com</email>
</author>
<published>2021-01-09T17:00:45+00:00</published>
<link rel='alternate' type='text/html' href='http://git.dreamy.place/mirrors/rust/commit/?id=d5b760ba62b40dd770c09e704b8a3af64c1fd058'/>
<id>urn:sha1:d5b760ba62b40dd770c09e704b8a3af64c1fd058</id>
<content type='text'>
Also switches on formatting of the mir build module
</content>
</entry>
<entry>
<title>Rollup merge of #81608 - Aaron1011:macro-res-parse-err, r=davidtwco</title>
<updated>2021-02-02T11:15:02+00:00</updated>
<author>
<name>Jonas Schievink</name>
<email>jonasschievink@gmail.com</email>
</author>
<published>2021-02-02T11:15:02+00:00</published>
<link rel='alternate' type='text/html' href='http://git.dreamy.place/mirrors/rust/commit/?id=255e0764c071d73a43a0c88181cb4cf667a74bff'/>
<id>urn:sha1:255e0764c071d73a43a0c88181cb4cf667a74bff</id>
<content type='text'>
Improve handling of spans around macro result parse errors

Fixes #81543

After we expand a macro, we try to parse the resulting tokens as a AST
node. This commit makes several improvements to how we handle spans when
an error occurs:

* Only ovewrite the original `Span` if it's a dummy span. This preserves
  a more-specific span if one is available.
* Use `self.prev_token` instead of `self.token` when emitting an error
  message after encountering EOF, since an EOF token always has a dummy
  span
* Make `SourceMap::next_point` leave dummy spans unused. A dummy span
  does not have a logical 'next point', since it's a zero-length span.
  Re-using the span span preserves its 'dummy-ness' for other checks
</content>
</entry>
<entry>
<title>Box the biggest ast::ItemKind variants</title>
<updated>2021-02-01T08:23:39+00:00</updated>
<author>
<name>Dániel Buga</name>
<email>bugadani@gmail.com</email>
</author>
<published>2021-01-29T07:31:08+00:00</published>
<link rel='alternate' type='text/html' href='http://git.dreamy.place/mirrors/rust/commit/?id=b87e1ecdf05d4fb2d14f13d760bb37098c58b06e'/>
<id>urn:sha1:b87e1ecdf05d4fb2d14f13d760bb37098c58b06e</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Improve handling of spans around macro result parse errors</title>
<updated>2021-01-31T20:24:34+00:00</updated>
<author>
<name>Aaron Hill</name>
<email>aa1ronham@gmail.com</email>
</author>
<published>2021-01-31T20:21:28+00:00</published>
<link rel='alternate' type='text/html' href='http://git.dreamy.place/mirrors/rust/commit/?id=6c14aad58e65c9c50faa45ed88369c5c72d6d0d7'/>
<id>urn:sha1:6c14aad58e65c9c50faa45ed88369c5c72d6d0d7</id>
<content type='text'>
Fixes #81543

After we expand a macro, we try to parse the resulting tokens as a AST
node. This commit makes several improvements to how we handle spans when
an error occurs:

* Only ovewrite the original `Span` if it's a dummy span. This preserves
  a more-specific span if one is available.
* Use `self.prev_token` instead of `self.token` when emitting an error
  message after encountering EOF, since an EOF token always has a dummy
  span
* Make `SourceMap::next_point` leave dummy spans unused. A dummy span
  does not have a logical 'next point', since it's a zero-length span.
  Re-using the span span preserves its 'dummy-ness' for other checks
</content>
</entry>
<entry>
<title>Rollup merge of #81472 - Aaron1011:fix/revert-cursor-clone, r=petrochenkov</title>
<updated>2021-01-31T00:47:34+00:00</updated>
<author>
<name>Jonas Schievink</name>
<email>jonasschievink@gmail.com</email>
</author>
<published>2021-01-31T00:47:34+00:00</published>
<link rel='alternate' type='text/html' href='http://git.dreamy.place/mirrors/rust/commit/?id=3e8ae5dcba4e5ad2f9a543df8da1ea679d84e4ce'/>
<id>urn:sha1:3e8ae5dcba4e5ad2f9a543df8da1ea679d84e4ce</id>
<content type='text'>
Clone entire `TokenCursor` when collecting tokens

Reverts PR #80830
Fixes taiki-e/pin-project#312

We can have an arbitrary number of `None`-delimited group frames pushed
on the stack due to proc-macro invocations, which can legally be exited.
Attempting to account for this would add a lot of complexity for a tiny
performance gain, so let's just use the original strategy.
</content>
</entry>
<entry>
<title>Fix typo in pat.rs</title>
<updated>2021-01-29T14:30:55+00:00</updated>
<author>
<name>Ikko Ashimine</name>
<email>eltociear@gmail.com</email>
</author>
<published>2021-01-29T14:30:55+00:00</published>
<link rel='alternate' type='text/html' href='http://git.dreamy.place/mirrors/rust/commit/?id=718398ccafaa45ed6a08ec550155150b9564eeed'/>
<id>urn:sha1:718398ccafaa45ed6a08ec550155150b9564eeed</id>
<content type='text'>
parentesized -&gt; parenthesized</content>
</entry>
<entry>
<title>Clone entire `TokenCursor` when collecting tokens</title>
<updated>2021-01-28T14:47:59+00:00</updated>
<author>
<name>Aaron Hill</name>
<email>aa1ronham@gmail.com</email>
</author>
<published>2021-01-28T14:47:59+00:00</published>
<link rel='alternate' type='text/html' href='http://git.dreamy.place/mirrors/rust/commit/?id=5d739180cde7f7350b7a90e8a7542bd9c4cd6783'/>
<id>urn:sha1:5d739180cde7f7350b7a90e8a7542bd9c4cd6783</id>
<content type='text'>
Reverts PR #80830
Fixes taiki-e/pin-project#312

We can have an arbitrary number of `None`-delimited group frames pushed
on the stack due to proc-macro invocations, which can legally be exited.
Attempting to account for this would add a lot of complexity for a tiny
performance gain, so let's just use the original strategy.
</content>
</entry>
</feed>
