upgrade rustc-ap-* version to v642

[calebcartwright]

I structured the changes into several smaller commits that were focused on a specific change/related set of changes in the upstream rustc crates, and included details about the upstream change in the commit messages (hope this makes it somewhat easier to review!).

I decided to focus on getting rustfmt to just "work" with the latest rustc crate versions, and defer making certain other changes (like refactoring, supporting the new half open range syntax - #4009, etc.) to future PRs. My thinking is defering those other changes will hopefully make this easier to merge since there's already a decent sized diff just from upgrading the rustc-ap versions, and I suspect this PR has a higher potential than normal for merge conflicts

[calebcartwright]

@topecongiro - most of the tests that are failing are due to an extra semicolon being inserted on macros that have a paren or bracket delim, and I'm not sure why that's happening 🤔

 impl Foo {
-    add_fun!();
+    add_fun!();;
 }

Any suggestions on the best way to address that? I could fix most of them by removing the explicit semicolon insertion but I don't think that's the right solution.

rustfmt/rustfmt-core/rustfmt-lib/src/macros.rs

Lines 272 to 279 in cbebfb2

	if ts.is_empty() && !has_comment {
	return match style {
	DelimToken::Paren if position == MacroPosition::Item => {
	Some(format!("{}();", macro_name))
	}
	DelimToken::Bracket if position == MacroPosition::Item => {
	Some(format!("{}[];", macro_name))
	}

[topecongiro]

@calebcartwright I had a similar issue in the past, and IIRC it was due to the change to the span. In this case, it could be that in 610, the span of macro didn't contain the trailing semicolon, whereas, in 638, the span contains it.

[calebcartwright]

You are right @topecongiro, that is exactly what's happening

[calebcartwright]

apparently the trailing whitespace is now actually being trimmed, so creating a test file under source directory with the trailing whitepsace to keep the test case valid since the end formatting result in the file under target has the whitepsace removed

[calebcartwright]

This is to address the change in this version of the rustc-ap creates where the span no longer includes the associated ; (#4022 (comment)). Wasn't sure what the best solution to this would be, so figured I'd try to just get the "correct" span to include the ; when warranted, so that Mac items that have whitespace between the closing delim and the semicolon are still formatted correctly (i.e. ) ; is still formatted to );)

[calebcartwright]

This was done to fix two snippets that were failing in the tests due to the ; being stripped. I think that was related to the same span change around missing semis so correcting it here.

The two failing snippets without this were:

rustfmt/rustfmt-core/rustfmt-lib/tests/target/macros.rs

Lines 239 to 242 in facba6a

	gfx_pipeline!(pipe {
	vbuf: gfx::VertexBuffer<Vertex> = (),
	out: gfx::RenderTarget<ColorFormat> = "Target0",
	});

and

rustfmt/rustfmt-core/rustfmt-lib/tests/target/issue-2916.rs

Lines 1 to 2 in facba6a

	a_macro!(name<Param1, Param2>,
	);

[calebcartwright]

Note that on both master and rustfmt 1.x that any whitespace between the closing delim and semi is not currently removed for these two snippets, so I think this actually fixes a very minor existing issue.

For example with the below/linked snippet, the whitespace between the delim and semi remains after formatting with 1.x and master:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=649ebcbc83ba416d42392084d91ba266

gfx_pipeline!(pipe { 
     vbuf: gfx::VertexBuffer<Vertex> = (), 
     out: gfx::RenderTarget<ColorFormat> = "Target0", 
 })       ;

I enhanced those two test snippets to ensure that rustfmt removes that extra whitespace

[topecongiro]

Thank you for the PR! Looks good to me with some minor nits addressed.

[matthiaskrgr]

Rustfmt in the rustc repo just broke rust-lang/rust#68917
I guess we'd need to update to 64*.0.0 to get it working again.

[calebcartwright]

I'll work on bumping this up to a 64*.0.0 version, and hopefully @topecongiro will be available to merge.

I believe I'd likely then need to backport this on top of the 1.4.11 branch though to fix the issue in the rustc repo, since this is targetting the new 2.x version of rustfmt on master which I don't believe is ready for release

[calebcartwright]

Believe we'll need an early bump of the rustc-ap-* crates to pull in the box_region changes for rustc_data_structures to be able to compile, otherwise we'll have to wait for v642 to get published on Tuesday.

Refs: alexcrichton/rustc-auto-publish#16

[topecongiro]

@calebcartwright My apologies for the late reply, I have been busy with my private life. Thank you so much for all the work!

[calebcartwright]

@calebcartwright My apologies for the late reply, I have been busy with my private life. Thank you so much for all the work!

No worries, and my pleasure!

[karyon]

Backport not needed