Specific error for positional args after named args in `format!()`
When writing positional arguments after named arguments in the
`format!()` and `println!()` macros, provide a targeted diagnostic.
Follow up to https://github.com/rust-lang/rust/pull/57522/files#r247278885
Add meta-variable checks in macro definitions
This is an implementation of #61053. It is not sound (some errors are not reported) and not complete (reports may not be actual errors). This is due to the possibility to define macros in macros in indirect ways. See module documentation of `macro_check` for more details.
What remains to be done:
- [x] Migrate from an error to an allow-by-default lint.
- [x] Add more comments in particular for the handling of nested macros.
- [x] Add more tests if needed.
- [x] Try to avoid cloning too much (one idea is to use lists on the stack).
- [ ] Run crater with deny-by-default lint (measure rate of false positives).
- [ ] Remove extra commit for deny-by-default lint
- [x] Create a PR to remove the old `question_mark_macro_sep` lint #62160
libsyntax: Rename `Mark` into `ExpnId`
"`Mark`" is an ID that identifies both a macro invocation (`foo!()`), and expansion process, and expansion result of that macro invocation.
The problem is that it's pretty hard to infer that from its name.
This PR renames it into `ExpnId` reflecting its meaning in most contexts.
(The contexts where it's meaning is closer to "macro invocation ID" are rarer.)
I've kept "mark" in the names of functions that add or remove marks to/from syntactic contexts, those marks are not just expansion IDs, but something more complex.
This is needed for having complete error messages where reporting macro variable
errors. Here is what they would look like:
error: meta-variable repeats with different kleene operator
--> $DIR/issue-61053-different-kleene.rs:3:57
|
LL | ( $( $i:ident = $($j:ident),+ );* ) => { $( $( $i = $j; )* )* };
| - expected repetition ^^ - conflicting repetition
azure: Prepare configuration for 4-core machines
This commit updates some of our assorted Azure/CI configuration to
prepare for some 4-core machines coming online. We're still in the
process of performance testing them to get final numbers, but some
changes are worth landing ahead of this. The updates here are:
* Use `C:/` instead of `D:/` for submodule checkout since it should have
plenty of space and the 4-core machines won't have `D:/`
* Update `lzma-sys` to 0.1.14 which has support for VS2019, where 0.1.10
doesn't.
* Update `src/ci/docker/run.sh` to work when it itself is running inside
of a docker container (see the comment in the file for more info)
* Print step timings on the `try` branch in addition to the `auto`
branch in. The logs there should be seen by similarly many humans (not
many) and can be useful for performance analysis after a `try` build
runs.
* Install the WIX and InnoSetup tools manually on Windows instead of
relying on pre-installed copies on the VM. This gives us more control
over what's being used on the Azure cloud right now (we control the
version) and in the 4-core machines these won't be pre-installed. Note
that on AppVeyor we actually already were installing InnoSetup, we
just didn't carry that over on Azure!
This commit updates some of our assorted Azure/CI configuration to
prepare for some 4-core machines coming online. We're still in the
process of performance testing them to get final numbers, but some
changes are worth landing ahead of this. The updates here are:
* Use `C:/` instead of `D:/` for submodule checkout since it should have
plenty of space and the 4-core machines won't have `D:/`
* Update `lzma-sys` to 0.1.14 which has support for VS2019, where 0.1.10
doesn't.
* Update `src/ci/docker/run.sh` to work when it itself is running inside
of a docker container (see the comment in the file for more info)
* Print step timings on the `try` branch in addition to the `auto`
branch in. The logs there should be seen by similarly many humans (not
many) and can be useful for performance analysis after a `try` build
runs.
* Install the WIX and InnoSetup tools manually on Windows instead of
relying on pre-installed copies on the VM. This gives us more control
over what's being used on the Azure cloud right now (we control the
version) and in the 4-core machines these won't be pre-installed. Note
that on AppVeyor we actually already were installing InnoSetup, we
just didn't carry that over on Azure!
