mirror
/
rustc-dev-guide
mirror of https://github.com/rust-lang/rustc-dev-guide.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

make date-check more lightweight (#1394) 

* make date-check lightweight

This avoids having to write the date twice when updating date-check.

Before "As of <-- 2022-07 --> July 2022"
After "As of July 2022"

* please clippy

* update date-check docs

* accept review suggestion

Co-authored-by: Noah Lev <camelidcamel@gmail.com>

* address review comment

https://github.com/rust-lang/rustc-dev-guide/pull/1394#pullrequestreview-1042163557

* accept review suggestion

Co-authored-by: Noah Lev <camelidcamel@gmail.com>

* address review comment

https://github.com/rust-lang/rustc-dev-guide/pull/1394#pullrequestreview-1042167261

* address review comment

https://github.com/rust-lang/rustc-dev-guide/pull/1394#issuecomment-1189105017

* this breaks markdown

* address review comment

https://github.com/rust-lang/rustc-dev-guide/pull/1394#discussion_r934018268

This led to a more robust regex, though making the tool more picky.
It also found a wrong date format that was missed.

* address review comment

https://github.com/rust-lang/rustc-dev-guide/pull/1394#discussion_r934018419

* address review comment

https://github.com/rust-lang/rustc-dev-guide/pull/1394#discussion_r934018816

* accept review suggestion

This was reverted by mistake

Co-authored-by: Noah Lev <camelidcamel@gmail.com>

* address review comment

https://github.com/rust-lang/rustc-dev-guide/pull/1394#discussion_r934019395

* use a more simple fn

* address review comment

https://github.com/rust-lang/rustc-dev-guide/pull/1394#discussion_r934018981

Much more clean

* nit

* accept review suggestion

Co-authored-by: Noah Lev <camelidcamel@gmail.com>

* avoid a failed regex

Also, test new shape

* adjust to new regex (which uses named groups)

New regex was introduced by 456008cc35

Co-authored-by: Noah Lev <camelidcamel@gmail.com>
This commit is contained in:
Tshepang Mbambo 2022-08-02 22:50:32 +02:00 committed by GitHub
parent 04f3cf0bb2
commit 2557089a44
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
29 changed files with 201 additions and 77 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

166
ci/date-check/src/main.rs
View File

@ -3,9 +3,10 @@ use std::{
convert::TryInto as _,
env, fmt, fs,
path::{Path, PathBuf},
str::FromStr,
};
use chrono::{Datelike as _, TimeZone as _, Utc};
use chrono::{Datelike as _, Month, TimeZone as _, Utc};
use glob::glob;
use regex::Regex;
@ -38,12 +39,18 @@ impl fmt::Display for Date {
fn make_date_regex() -> Regex {
Regex::new(
r"(?x) # insignificant whitespace mode
<!--\s*
[dD]ate:\s*
(?P<y>\d{4}) # year
-
(?P<m>\d{2}) # month
\s*-->",
(<!--\s*
date-check:\s*
(?P<m1>\D+)\s+
(?P<y1>\d{4})\s*-->
)
|
(<!--\s*
date-check\s*-->\s+
(?P<m2>\D+)\s+
(?P<y2>\d{4})\b
)
",
)
.unwrap()
}
@ -52,15 +59,22 @@ fn collect_dates_from_file(date_regex: &Regex, text: &str) -> Vec<(usize, Date)>
let mut line = 1;
let mut end_of_last_cap = 0;
date_regex
.captures_iter(&text)
.map(|cap| {
(
cap.get(0).unwrap().range(),
Date {
year: cap["y"].parse().unwrap(),
month: cap["m"].parse().unwrap(),
},
)
.captures_iter(text)
.filter_map(|cap| {
if let (Some(month), Some(year), None, None) | (None, None, Some(month), Some(year)) = (
cap.name("m1"),
cap.name("y1"),
cap.name("m2"),
cap.name("y2"),
) {
let year = year.as_str().parse().expect("year");
let month = Month::from_str(month.as_str())
.expect("month")
.number_from_month();
Some((cap.get(0).expect("all").range(), Date { year, month }))
} else {
None
}
})
.map(|(byte_range, date)| {
line += text[end_of_last_cap..byte_range.end]
@ -182,61 +196,153 @@ mod tests {
#[test]
fn test_date_regex() {
let regex = make_date_regex();
assert!(regex.is_match("foo <!-- date: 2021-01 --> bar"));
let regex = &make_date_regex();
assert!(regex.is_match("<!-- date-check: jan 2021 -->"));
assert!(regex.is_match("<!-- date-check: january 2021 -->"));
assert!(regex.is_match("<!-- date-check: Jan 2021 -->"));
assert!(regex.is_match("<!-- date-check: January 2021 -->"));
assert!(regex.is_match("<!-- date-check --> jan 2021"));
assert!(regex.is_match("<!-- date-check --> january 2021"));
assert!(regex.is_match("<!-- date-check --> Jan 2021"));
assert!(regex.is_match("<!-- date-check --> January 2021"));
assert!(regex.is_match("<!-- date-check --> jan 2021 "));
assert!(regex.is_match("<!-- date-check --> jan 2021."));
}
#[test]
fn test_date_regex_capitalized() {
let regex = make_date_regex();
assert!(regex.is_match("foo <!-- Date: 2021-08 --> bar"));
fn test_date_regex_fail() {
let regexes = &make_date_regex();
assert!(!regexes.is_match("<!-- date-check: jan 221 -->"));
assert!(!regexes.is_match("<!-- date-check: jan 20221 -->"));
assert!(!regexes.is_match("<!-- date-check: 01 2021 -->"));
assert!(!regexes.is_match("<!-- date-check --> jan 221"));
assert!(!regexes.is_match("<!-- date-check --> jan 20222"));
assert!(!regexes.is_match("<!-- date-check --> 01 2021"));
}
#[test]
fn test_collect_dates_from_file() {
let text = "Test1\n<!-- date: 2021-01 -->\nTest2\nFoo<!-- date: 2021-02 \
-->\nTest3\nTest4\nFoo<!-- date: 2021-03 -->Bar\n<!-- date: 2021-04 \
-->\nTest5\nTest6\nTest7\n<!-- date: \n\n2021-05 -->\nTest8
let text = r"
Test1
<!-- date-check: jan 2021 -->
Test2
Foo<!-- date-check: february 2021
-->
Test3
Test4
Foo<!-- date-check: Mar 2021 -->Bar
<!-- date-check:April 2021
-->
Test5
Test6
Test7
<!-- date-check:
may 2021 -->
Test8
Test1
<!-- date-check --> jan 2021
Test2
Foo<!-- date-check
--> february 2021
Test3
Test4
Foo<!-- date-check --> mar 2021 Bar
<!-- date-check
--> apr 2021
Test5
Test6
Test7
<!-- date-check
--> may 2021
Test8
<!--
date-check
--> june 2021.
";
assert_eq!(
collect_dates_from_file(&make_date_regex(), text),
vec![
(
2,
3,
Date {
year: 2021,
month: 1,
}
),
(
4,
6,
Date {
year: 2021,
month: 2,
}
),
(
7,
9,
Date {
year: 2021,
month: 3,
}
),
(
8,
11,
Date {
year: 2021,
month: 4,
}
),
(
14,
17,
Date {
year: 2021,
month: 5,
}
),
]
(
20,
Date {
year: 2021,
month: 1,
}
),
(
23,
Date {
year: 2021,
month: 2,
}
),
(
26,
Date {
year: 2021,
month: 3,
}
),
(
28,
Date {
year: 2021,
month: 4,
}
),
(
34,
Date {
year: 2021,
month: 5,
}
),
(
38,
Date {
year: 2021,
month: 6,
}
),
],
);
}
}

2
src/backend/backend-agnostic.md
View File

@ -2,7 +2,7 @@
<!-- toc -->
As of <!-- date: 2021-10 --> October 2021, `rustc_codegen_ssa` provides an
As of <!-- date-check --> October 2021, `rustc_codegen_ssa` provides an
abstract interface for all backends to implement, to allow other codegen
backends (e.g. [Cranelift]).

4
src/backend/updating-llvm.md
View File

@ -66,8 +66,8 @@ Example PRs look like:
## Feature updates
> Note that this information is as of the time of this writing <!-- date:
2021-10 --> (October 2021). The process for updating LLVM changes with
> Note that this information is as of the time of this writing, <!--
date-check --> October 2021. The process for updating LLVM changes with
practically all LLVM updates, so this may be out of date!
Unlike bugfixes, updating to pick up a new feature of LLVM typically requires a

2
src/borrow_check/region_inference/member_constraints.md
View File

@ -94,7 +94,7 @@ member constraints come in.
## Choices are always lifetime parameters
At present, the "choice" regions from a member constraint are always lifetime
parameters from the current function. As of <!-- date: 2021-10 --> October 2021,
parameters from the current function. As of <!-- date-check --> October 2021,
this falls out from the placement of impl Trait, though in the future it may not
be the case. We take some advantage of this fact, as it simplifies the current
code. In particular, we don't have to consider a case like `'0 member of ['1,

2
src/building/suggested.md
View File

@ -22,7 +22,7 @@ You can also install the hook as a step of running `./x.py setup`!
a file. By default, `rust-analyzer` runs the `cargo check` and `rustfmt`
commands, but you can override these commands to use more adapted versions
of these tools when hacking on `rustc`. For example, for Visual Studio Code,
you can write: <!-- date: 2022-04 --><!-- the date comment is for the edition below -->
you can write: <!-- date-check: apr 2022 --><!-- the date comment is for the edition below -->
```JSON
{

37
src/contributing.md
View File

@ -437,17 +437,35 @@ Just a few things to keep in mind:
the project.
- The date the comment was added, e.g. instead of writing _"Currently, ..."_
or _"As of now, ..."_, consider writing
_"As of January 2021, ..."_.
Try to format the date as `<MONTH> <YEAR>` to ease search.
or _"As of now, ..."_,
consider adding the date, in one of the following formats:
- Jan 2021
- January 2021
- jan 2021
- january 2021
- Additionally, include a machine-readable comment of the form `<!-- date:
2022-04 -->` (if the current month is April 2022). We have an automated
tool that uses these (in `ci/date-check`).
There is a CI action (in `~/.github/workflows/date-check.yml`)
that generates a monthly issue with any of these that are over 6 months old.
So, for the month of April 2022, the comment would look like: `As of <!--
date: 2022-04 --> April 2022`. Make sure to put the comment *between* `as of`
and `April 2022`; see [PR #1066][rdg#1066] for the rationale.
For the action to pick the date,
add a special annotation before specifying the date:
```md
<!-- date-check --> Jul 2022
```
Example:
```md
As of <!-- date-check --> Jul 2022, the foo did the bar.
```
For cases where the date should not be part of the visible rendered output,
use the following instead:
```md
<!-- date-check: Jul 2022 -->
```
- A link to a relevant WG, tracking issue, `rustc` rustdoc page, or similar, that may provide
further explanation for the change process or a way to verify that the information is not
@ -459,7 +477,6 @@ Just a few things to keep in mind:
[rdg]: https://rustc-dev-guide.rust-lang.org/
[rdgrepo]: https://github.com/rust-lang/rustc-dev-guide
[rdg#1066]: https://github.com/rust-lang/rustc-dev-guide/pull/1066
## Issue Triage

4
src/conventions.md
View File

@ -14,14 +14,14 @@ special config, so this may result in different style from normal [`rustfmt`].
Therefore, formatting this repository using `cargo fmt` is not recommended.
Instead, formatting should be done using `./x.py fmt`. It's a good habit to run
`./x.py fmt` before every commit, as this reduces conflicts later.
`./x.py fmt` before every commit, as this reduces conflicts later.
Formatting is checked by the `tidy` script. It runs automatically when you do
`./x.py test` and can be run in isolation with `./x.py fmt --check`.
If you want to use format-on-save in your editor, the pinned version of
`rustfmt` is built under `build/<target>/stage0/bin/rustfmt`. You'll have to
pass the <!-- date: 2022-04 --> `--edition=2021` argument yourself when calling
pass the <!-- date-check: April 2022 --> `--edition=2021` argument yourself when calling
`rustfmt` directly.
[fmt]: https://github.com/rust-dev-tools/fmt-rfcs

2
src/crates-io.md
View File

@ -12,7 +12,7 @@ reasons:
- The dependency may have transitive dependencies that have one of the above
problems.
As of <!-- date: 2022-02 --> February 2022, there is no official policy for vetting
As of <!-- date-check --> February 2022, there is no official policy for vetting
new dependencies to the compiler. Generally, new dependencies are not added
to the compiler unless there is a good reason to do so.

2
src/diagnostics/diagnostic-items.md
View File

@ -43,7 +43,7 @@ A new diagnostic item can be added with these two steps:
For the naming conventions of diagnostic items, please refer to
[*Naming Conventions*](#naming-conventions).
2. As of <!-- date: 2022-02 --> February 2022, diagnostic items in code are
2. As of <!-- date-check --> February 2022, diagnostic items in code are
accessed via symbols in [`rustc_span::symbol::sym`]. To add your newly
created diagnostic item simply open the module file and add the name (In
this case `Cat`) at the correct point in the list.

2
src/diagnostics/lintstore.md
View File

@ -17,7 +17,7 @@ default lint level and other metadata come from. These are normally defined by
way of the [`declare_lint!`] macro, which boils down to a static with type
`&rustc_session::lint::Lint`.
As of <!-- date: 2022-02 --> February 2022, we lint against direct declarations
As of <!-- date-check --> February 2022, we lint against direct declarations
without the use of the macro today (although this may change in the future, as
the macro is somewhat unwieldy to add new fields to, like all macros).

2
src/diagnostics/translation.md
View File

@ -217,7 +217,7 @@ returned by `Emitter::fluent_bundle`. This bundle is used preferentially when
translating messages, the fallback bundle is only used if the primary bundle is
missing a message or not provided.
As of <!-- date: 2022-06 --> June 2022, there are no locale bundles
As of <!-- date-check --> June 2022, there are no locale bundles
distributed with the compiler, but mechanisms are implemented for loading
bundles.

2
src/git.md
View File

@ -157,7 +157,7 @@ no changes added to commit (use "git add" and/or "git commit -a")
These changes are not changes to files: they are changes to submodules (more on
this [later](#git-submodules)). To get rid of those, run `git submodule update`
(or run any `x.py` command, which will automatically update the submodules).
Note that there is (as of <!-- date: 2022-02 --> February 2022) a [bug][#77620] if you use
Note that there is (as of <!-- date-check --> February 2022) a [bug][#77620] if you use
worktrees, submodules, and `x.py` in a commit hook. If you run into an error
like:

7
src/llvm-coverage-instrumentation.md
View File

@ -222,9 +222,10 @@ properly-configured variables in LLVM IR, according to very specific
details of the [_LLVM Coverage Mapping Format_][coverage-mapping-format]
(Version 6).[^llvm-and-covmap-versions]
[^llvm-and-covmap-versions]: The Rust compiler (as of <!-- date: 2021-12 -->
December 2021) supports _LLVM Coverage Mapping Format_ Version 5 or 6. Version 5
was introduced in _LLVM 12_, which is (as of this writing) the minimum LLVM
[^llvm-and-covmap-versions]: The Rust compiler (as of <!-- date-check --> December 2021)
supports _LLVM Coverage Mapping Format_ Version 5 or 6. Version 5
was introduced in _LLVM 12_,
which is (as of <!-- date-check: December 2021--> this writing) the minimum LLVM
version supported by the current version of Rust. Version 6 was introduced in
_LLVM 13_, which is currently the default LLVM version for Rust. The Rust
compiler will automatically use the most up-to-date coverage mapping format

6
src/opaque-types-type-alias-impl-trait.md
View File

@ -14,9 +14,9 @@ This declares an opaque type named `Foo`, of which the only information is that
it implements `Bar`. Therefore, any of `Bar`'s interface can be used on a `Foo`,
but nothing else (regardless of whether it implements any other traits).
Since there needs to be a concrete background type, you can (as of <!-- date:
2021-01 --> January 2021) express that type by using the opaque type in a
"defining use site".
Since there needs to be a concrete background type,
you can (as of <!-- date-check --> January 2021) express that type
by using the opaque type in a "defining use site".
```rust,ignore
struct Struct;

2
src/overview.md
View File

@ -292,7 +292,7 @@ Moreover, the compiler wasn't originally built to use a query system; the query
system has been retrofitted into the compiler, so parts of it are not query-fied
yet. Also, LLVM isn't our code, so that isn't querified either. The plan is to
eventually query-fy all of the steps listed in the previous section,
but as of <!-- date: 2021-11 --> November 2021, only the steps between HIR and
but as of <!-- date-check --> November 2021, only the steps between HIR and
LLVM IR are query-fied. That is, lexing, parsing, name resolution, and macro
expansion are done all at once for the whole program.

8
src/parallel-rustc.md
View File

@ -1,6 +1,6 @@
# Parallel Compilation
As of <!-- date: 2022-05 --> May 2022, The only stage of the compiler
As of <!-- date-check --> May 2022, The only stage of the compiler
that is already parallel is codegen. The nightly compiler implements query evaluation,
but there is still a lot of work to be done. The lack of parallelism at other stages
also represents an opportunity for improving compiler performance. One can try out the current
@ -54,13 +54,13 @@ When a query `foo` is evaluated, the cache table for `foo` is locked.
## Rustdoc
As of <!-- date: 2022-05--> May 2022, there are still a number of steps
As of <!-- date-check--> May 2022, there are still a number of steps
to complete before rustdoc rendering can be made parallel. More details on
this issue can be found [here][parallel-rustdoc].
## Current Status
As of <!-- date: 2022-05 --> May 2022, work on explicitly parallelizing the
As of <!-- date-check --> May 2022, work on explicitly parallelizing the
compiler has stalled. There is a lot of design and correctness work that needs
to be done.
@ -76,7 +76,7 @@ These are the basic ideas in the effort to make `rustc` parallel:
[`rayon`]: https://crates.io/crates/rayon
As of <!-- date: 2022-05 --> May 2022, much of this effort is on hold due
As of <!-- date-check --> May 2022, much of this effort is on hold due
to lack of manpower. We have a working prototype with promising performance
gains in many cases. However, there are two blockers:

2
src/profiling.md
View File

@ -108,6 +108,6 @@ The llvm-lines output is affected by several options.
MIR optimizations have little impact. Compared to the default `RUSTFLAGS="-Z
mir-opt-level=1"`, level 0 adds 0.3GB and level 2 removes 0.2GB.
As of <!-- date: 2022-07 --> July 2022,
As of <!-- date-check --> July 2022,
inlining happens in LLVM and GCC codegen backends,
missing only in the Cranelift one.

2
src/queries/query-evaluation-model-in-detail.md
View File

@ -76,7 +76,7 @@ executed, no results are cached. But the context already provides access to
"input" data, i.e. pieces of immutable data that were computed before the
context was created and that queries can access to do their computations.
As of <!-- date: 2021-01 --> January 2021, this input data consists mainly of
As of <!-- date-check --> January 2021, this input data consists mainly of
the HIR map, upstream crate metadata, and the command-line options the compiler
was invoked with; but in the future inputs will just consist of command-line
options and a list of source files -- the HIR map will itself be provided by a

2
src/query.md
View File

@ -3,7 +3,7 @@
<!-- toc -->
As described in [the high-level overview of the compiler][hl], the Rust compiler
is still (as of <!-- date: 2021-07 --> July 2021) transitioning from a
is still (as of <!-- date-check --> July 2021) transitioning from a
traditional "pass-based" setup to a "demand-driven" system. The compiler query
system is the key to rustc's demand-driven organization.
The idea is pretty simple. Instead of entirely independent passes

2
src/rustc-driver-getting-diagnostics.md
View File

@ -7,7 +7,7 @@
To get diagnostics from the compiler,
configure `rustc_interface::Config` to output diagnostic to a buffer,
and run `TyCtxt.analysis`. The following was tested
with <!-- date: 2022-06 --> `nightly-2022-06-05` (See [here][example]
with <!-- date-check: June 2022 --> `nightly-2022-06-05` (See [here][example]
for the complete example):
[example]: https://github.com/rust-lang/rustc-dev-guide/blob/master/examples/rustc-driver-getting-diagnostics.rs

2
src/rustc-driver-interacting-with-the-ast.md
View File

@ -5,7 +5,7 @@
## Getting the type of an expression
To get the type of an expression, use the `global_ctxt` to get a `TyCtxt`.
The following was tested with <!-- date: 2022-06 --> `nightly-2022-06-05`
The following was tested with <!-- date-check: June 2022 --> `nightly-2022-06-05`
(see [here][example] for the complete example):
[example]: https://github.com/rust-lang/rustc-dev-guide/blob/master/examples/rustc-driver-interacting-with-the-ast.rs

2
src/rustdoc-internals.md
View File

@ -66,7 +66,7 @@ these passes, please let us know!)
[44136]: https://github.com/rust-lang/rust/issues/44136
Here is the list of passes as of <!-- date: 2022-05 --> May 2022:
Here is the list of passes as of <!-- date-check --> May 2022:
- `calculate-doc-coverage` calculates information used for the `--show-coverage`
flag.

2
src/salsa.md
View File

@ -9,7 +9,7 @@ want to watch [Salsa In More
Depth](https://www.youtube.com/watch?v=i_IhACacPRY), also by Niko
Matsakis.
> As of <!-- date: 2022-04 --> April 2022, although Salsa is inspired by
> As of <!-- date-check --> April 2022, although Salsa is inspired by
> (among other things) rustc's query system, it is not used directly in rustc.
> It _is_ used in chalk and extensively in `rust-analyzer`, but there are no
> medium or long-term concrete plans to integrate it into the compiler.

2
src/tests/compiletest.md
View File

@ -452,7 +452,7 @@ fn main() {
## Revisions
Certain classes of tests support "revisions" (as of <!-- date: 2022-07 --> July 2022,
Certain classes of tests support "revisions" (as of <!-- date-check --> July 2022,
this includes UI, assembly, codegen, debuginfo, incremental, and rustdoc UI tests,
though incremental tests are somewhat different).
Revisions allow a single test file to be used for multiple tests.

2
src/the-parser.md
View File

@ -1,6 +1,6 @@
# Lexing and Parsing
As of <!-- date: 2021-01 --> January 2021, the lexer and parser are undergoing
As of <!-- date-check --> January 2021, the lexer and parser are undergoing
refactoring to allow extracting them into libraries.
The very first thing the compiler does is take the program (in Unicode

2
src/thir.md
View File

@ -4,7 +4,7 @@
The THIR ("Typed High-Level Intermediate Representation"), previously called HAIR for
"High-Level Abstract IR", is another IR used by rustc that is generated after
[type checking]. It is (as of <!-- date: 2022-04 --> April 2022) only used for
[type checking]. It is (as of <!-- date-check --> April 2022) only used for
[MIR construction] and [exhaustiveness checking]. There is also
[an experimental unsafety checker][thir-unsafeck] that operates on the THIR as a replacement for
the current MIR unsafety checker, and can be used instead of the MIR unsafety checker by passing

4
src/traits/chalk.md
View File

@ -1,7 +1,7 @@
# Chalk-based trait solving
[Chalk][chalk] is an experimental trait solver for Rust that is (as of <!--
date: 2022-05 --> May 2022) under development by the [Types team].
[Chalk][chalk] is an experimental trait solver for Rust that is
(as of <!-- date-check --> May 2022) under development by the [Types team].
Its goal is to enable a lot of trait system features and bug fixes
that are hard to implement (e.g. GATs or specialization). If you would like to
help in hacking on the new solver, drop by on the rust-lang Zulip in the [`#t-types`]

2
src/traits/resolution.md
View File

@ -120,7 +120,7 @@ the obligation contains unbound inference variables.
The subroutines that decide whether a particular impl/where-clause/etc applies
to a particular obligation are collectively referred to as the process of
_matching_. As of <!-- date: 2022-05 --> May 2022, this amounts to unifying
_matching_. As of <!-- date-check --> May 2022, this amounts to unifying
the `Self` types, but in the future we may also recursively consider some of the
nested obligations, in the case of an impl.

2
src/type-inference.md
View File

@ -72,7 +72,7 @@ inference works, or perhaps this blog post on
[Unification in the Chalk project]: http://smallcultfollowing.com/babysteps/blog/2017/03/25/unification-in-chalk-part-1/
All told, the inference context stores five kinds of inference variables
(as of <!-- date: 2021-06 --> June 2021):
(as of <!-- date-check --> June 2021):
- Type variables, which come in three varieties:
- General type variables (the most common). These can be unified with any