or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Do you want to remove this version name and description?
Syncing
xxxxxxxxxx
Crater analysis for #124141
The second recent crater run in #124141 ("Remove Nonterminal and TokenKind::Interpolated") had 18 failures. They all involve edge cases with declarative macros, and I believe they are all cases where the current compiler is buggy, and the new behaviour of failing to compile is the correct behaviour.
I will use "rustc0" to refer to the compiler with the current behaviour, and "rustc1" to refer to the compiler with the new behaviour introduced by this PR.
Summary
In every case, there is a declarative macro with some kind of complexity: a
cfg
attribute, or a cross-crate boundary, or a nested macro, or some combination. In every case, rust0 accepts the complex declarative macro while rejecting a simpler form of the same macro, e.g. with thecfg
removed, or in an intra-crate case. In every case rustc1 rejects both the more complex and simpler forms, for improved consistency. I believe that rustc0 is buggy in its current behaviour, and that the inconsistencies arise because of the complexity of the internal handling ofInterpolated
.None of the failing crates are particularly high profile. I expect fixing the compilation failures would be easy for some or most of them, though I haven't taken the time to check this.
hostfxr-sys-0.11.0
I minimized this to the following:
rustc0 and rustc1 both reject this, because the
WrapperApi
proc macro (from thedlopen2
crate) can't handle the invisible delimiters around$ty
and aborts. However, if you uncomment thecfg
line, rustc0 will accept it, because thecfg
(which evaluates to true) causes the invisible delimiters to get stripped and so the proc macro suceeds. There is no good reason for the invisible delimiters to be stripped, it's just an unintentional behaviour of rustc0. Therefore, rustc1 increases consistency by treating this code the same whether thecfg
is present or not.enclave-runner-0.6.0, dcap-provider-0.4.0, dcap-ql-0.4.0, fortanix-sgx-tools-0.5.1, report-test-0.4.0
I minimized this to the following. In
enclave-runner/src/lib.rs
:In
fortanix-sgx-abi/src/lib.rs
:If all this code is in a single crate, both rustc0 and rustc1 reject it. Because the
!
input tomk_invoke_with_ty_bang
is pasted as aty
which gets invisible delmiters around it. That then ends up as an input toconsume_bang
, and it doesn't match the(!)
rule because of the invisible delimiters, so the($r:tt)
rule matches, andOption<!>
is produced, which triggers an error message "error: the!
type is experimental".However, if the code is split across two crates, rustc0 will accept it, while rustc1 rejects it. I don't 100% understand why, but I assume that the invisible delimiters somehow are stripped when writing the
mk_invoke_with_ty_bang
macro into metadata. There is no good reason for the behaviour to be different when crossing crate boundaries, it's unintentional. Therefore, rustc1 increases consistency by treating this code the same whether it's intra-crate or inter-crate.aver-0.1.5
I minimized this, the key part is this:
If you have a call to
log_info!
in the same crate, both rustc0 and rustc1 reject it, because you can't concatenate aty
fragment specifier to something else to create a path in a proc macro; you can only do that with anident
fragment specifier.However, if the call to
log_info!
is in a different crate (in this case because its in a unit test) then rustc0 will accept it. Again, something about being a nested macro that crosses crate boundaries lets it slip through. Once again, there is no good reason for different behaviour across a crate boundary, and rustc1 increases consistency.(If
$level:ty
is changed to$($level:tt)*
, then the concatenation is valid and accepted by both rustc0 and rustc1 in the intra-crate case.)fftconvolve-0.1.1
The minimized version includes this code:
This is similar to the previous case: a nested macro crossing crate boundaries, involving a
path
specifier being concatenated with$crate::
, which shouldn't be allowed. Again, rustc1 increases consistency by treating the intra-crate and inter-crate cases the same.assert-cmp-0.2.1, parallel-disk-usage-0.9.3
A minimization:
and in a unit test:
Once again we have a
path
fragment specifier being concatenated into a longer path. If all the code is in the same crate, both rustc0 and rustc1 reject it. But when it's cross-crate, rustc0 accepts it, for no good reason. Again, rustc1 increases consistency by treating the intra-crate and inter-crate cases the same.for_each-0.9.0, math_adapter-0.3.8, meta_tools_min-0.2.13, non_std-0.1.4, proc_macro_tools-0.1.17, std_tools-0.1.4, std_x-0.1.4, type_constructor-0.3.0
These are all related: they are all by the same author, and they are all failures compiling test code, because they all use similar code in tests.
A minimized version:
rustc0 accepts this, while rustc1 rejects this with "error: attempted to repeat an expression containing no syntax variables matched as repeating at this depth". If you simplify it to this:
then both rustc0 and rustc1 reject it. This is a standard problem with nested macros, where the repetition
$( $arg:tt )*
looks like it belongs to the inner macro but it really belongs to the outer macro.There is no clear reason why rustc0 accepts the more complex code, it's just an accidental byproduct of the imperfect token handling of the most complex declarative macros. Once again, rustc1 increases consistency by treating the two cases the same.