| Age | Commit message (Collapse) | Author | Lines |
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
r=albertlarsan68
optimize and cleanup bootstrap source
I suggest reviewing this commit by commit.
|
|
Overall optimizations for bootstrap on conditions, assertions,
trait implementations, etc.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Based on
https://github.com/rust-lang/rust/pull/115812#issuecomment-1717960119
Having them in separate files used to make more sense, before the
migration to CSS variables made the theme files as small as they are
nowadays. This is already how docs.rs and mdBook do it.
|
|
|
|
We compile each test file to LLVM IR assembly, and then pass that IR to a
dedicated program that can decode LLVM coverage maps and print them in a more
human-readable format. We can then check that output against known-good
snapshots.
This test suite has some advantages over the existing `run-coverage` tests:
- We can test coverage instrumentation without needing to run target binaries.
- We can observe subtle improvements/regressions in the underlying coverage
mappings that don't make a visible difference to coverage reports.
|
|
The dist-src tarball does not include `.github/` at all, so we can't
check whether it needs to be regenerated.
|
|
|
|
Add support for tidy linting via external tools for non-rust files
This change adds the flag `--check-extras` to `tidy`. It accepts a comma separated list of any of the options:
* py (test everything applicable for python files)
* py:lint (lint python files using `ruff`)
* py:fmt (check formatting for python files using `black`)
* shell or shell:lint (lint shell files using `shellcheck`)
Specific files to check can also be specified via positional args. Examples:
* `./x test tidy --check-extras=shell,py`
* `./x test tidy --check-extras=py:fmt -- src/bootstrap/bootstrap.py`
* `./x test tidy --check-extras=shell -- src/ci/*.sh`
* Python formatting can be applied with bless: `./x test tidy --ckeck-extras=py:fmt --bless`
`ruff` and `black` need to be installed via pip; this tool manages these within a virtual environment at `build/venv`. `shellcheck` needs to be installed on the system already.
---
This PR doesn't fix any of the errors that show up (I will likely go through those at some point) and it doesn't enforce anything new in CI. Relevant zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Other.20linters.20in.20CI
|
|
|
|
This change adds the flag `--check-extras` to `tidy`. It accepts a comma
separated list of any of the options:
- py (test everything applicable for python files)
- py:lint (lint python files using `ruff`)
- py:fmt (check formatting for python files using `black`)
- shell or shell:lint (lint shell files using `shellcheck`)
Specific files to check can also be specified via positional args.
Examples:
- `./x test tidy --check-extras=shell,py`
- `./x test tidy --check-extras=py:fmt -- src/bootstrap/bootstrap.py`
- `./x test tidy --check-extras=shell -- src/ci/*.sh`
- Python formatting can be applied with bless:
`./x test tidy --ckeck-extras=py:fmt --bless`
`ruff` and `black` need to be installed via pip; this tool manages these
within a virtual environment at `build/venv`. `shellcheck` needs to be
installed on the system already.
|
|
|
|
Currently, Clippy, Miri, Rustfmt, and rustc all use an environment variable to
indicate that output should be blessed, but they use different variable names.
In order to improve consistency, this patch applies the following changes:
- Emit `RUSTC_BLESS` within `prepare_cargo_test` so it is always
available
- Change usage of `MIRI_BLESS` in the Miri subtree to use `RUSTC_BLESS`
- Change usage of `BLESS` in the Clippy subtree to `RUSTC_BLESS`
- Change usage of `BLESS` in the Rustfmt subtree to `RUSTC_BLESS`
- Adjust the blessable test in `rustc_errors` to use this same
convention
- Update documentation where applicable
Any tools that uses `RUSTC_BLESS` should check that it is set to any value
other than `"0"`.
|
|
built in-tree version
|
|
|
|
bootstrap: Clean up try_run
r? `@ozkanonur` since you reviewed `@GuillaumeGomez's` PR
i recommend reviewing commit-by-commit
|
|
misc bootstrap cleanups
- rename `detail_exit_macro` to `exit`
- remove unnecessary `Builder::new_standalone` function
- support `x suggest` with build-metrics
|
|
It was only used when a `builder` is available, and I want to encourage using the version that supports `--no-fail-fast`.
|
|
|
|
This does three things:
1. Remove `forward!(Build, fn try_run())`. Having `try_run` behave differently as a free function than an associated function is confusing, and `Builder::try_run` is a very desirable name.
2. Move `test::try_run` and `run::try_run` to `Builder::try_run`. These functions are different than `Config::try_run` - they delay the failure and print it out at the end of the build.
3. Mark `Config::try_run` as deprecated to encourage people to use `Builder::try_run` instead.
|
|
- group rustdoc-js-std
- group rust-installer/test.sh
|
|
This caught several places which weren't waiting until the command finished to drop the Group.
I also took the liberty of calling `msg_sysroot_tool` from `run_cargo_test` to reduce code duplication and make errors like this less likely in the future.
|
|
|
|
|
|
This also adds a dynamic check that we don't emit nested groups, since GHA currently doesn't support them.
|
|
|
|
`detail` and `macro` weren't adding any info.
|
|
switch
If someone says `x test rustdoc-js-std` explicitly on the command line, it's because they want to
run the tests. Give an error instead of doing nothing and reporting success.
|
|
Don't fail early if `try_run` returns an error
Fixes https://github.com/rust-lang/rust/issues/113208.
Follow-up of #112962.
r? `@jyn514`
|
|
various download-rustc fixes
separated out from https://github.com/rust-lang/rust/pull/112143 because it keeps getting stuck in limbo.
best reviewed commit-by-commit
|
|
|
|
|
|
This was removed in
https://github.com/rust-lang/rust/pull/113260/commits/de69d556eb5006a21f868b8c12d48f0ef1308a5a#diff-8479eab02701e686aedb15b567dc8fc31220c6e4efb9565ccc9d662b7fee2214
which caused CI to ignore clippy failures. This adds back the exit,
which should cause CI to fail again if a test is broken (like right
now, as clippy tests are broken on master).
|
|
|
|
Add simple markdown formatting to `rustc --explain` output
This is a second attempt at #104540, which is #63128 without dependencies.
This PR adds basic markdown formatting to `rustc --explain` output when available. Currently, the output just displays raw markdown: this works of course, but it really doesn't look very elegant. (output is `rustc --explain E0038`)
<img width="583" alt="image" src="https://github.com/rust-lang/rust/assets/13724985/ea418117-47af-455b-83c0-6fc59276efee">
After this patch, sample output from the same file:
<img width="693" alt="image" src="https://github.com/rust-lang/rust/assets/13724985/12f7bf9b-a3fe-4104-b74b-c3e5227f3de9">
This also obeys the `--color always/auto/never` command option. Behavior:
- If pager is available and supports color, print with formatting to the pager
- If pager is not available or fails print with formatting to stdout - otherwise without formatting
- Follow `--color always/never` if suppied
- If everything fails, just print plain text to stdout
r? `@oli-obk`
cc `@estebank`
(since the two of you were involved in the previous discussion)
|
|
Currently, the output of `rustc --explain foo` displays the raw markdown in a
pager. This is acceptable, but using actual formatting makes it easier to
understand.
This patch consists of three major components:
1. A markdown parser. This is an extremely simple non-backtracking recursive
implementation that requires normalization of the final token stream
2. A utility to write the token stream to an output buffer
3. Configuration within rustc_driver_impl to invoke this combination for
`--explain`. Like the current implementation, it first attempts to print to
a pager with a fallback colorized terminal, and standard print as a last
resort.
If color is disabled, or if the output does not support it, or if printing
with color fails, it will write the raw markdown (which matches current
behavior).
Pagers known to support color are: `less` (with `-r`), `bat` (aka `catbat`),
and `delta`.
The markdown parser does not support the entire markdown specification, but
should support the following with reasonable accuracy:
- Headings, including formatting
- Comments
- Code, inline and fenced block (no indented block)
- Strong, emphasis, and strikethrough formatted text
- Links, anchor, inline, and reference-style
- Horizontal rules
- Unordered and ordered list items, including formatting
This parser and writer should be reusable by other systems if ever needed.
|
|
Update Clippy
r? `@Manishearth`
cc `@oli-obk` (for the ui-test changes in de69d556eb5006a21f868b8c12d48f0ef1308a5a and the valtree fix in 0cbe963e51faa7e3e771c1f9cea9aa443a648455)
Fixes https://github.com/rust-lang/rust/issues/102093
This must've been the most involved Clippy sync ever.
|
|
|
|
Make Rust Analyzer tests faster by compiling less code
This should bring down the test duration of RA significantly.
|
|
Don't pass --test-args to `python -m unitest`
The args for unittest and cargo test are mutually incompatible. Suggest that people use `python -m unittest ...` manually instead.
This also changes `bootstrap_test.py` to be easier to run standalone; see the commit for details.
r? `@clubby789` cc https://github.com/rust-lang/rust/pull/112281#discussion_r1248849172
|
|
|
|
The args for unittest and cargo test are mutually incompatible. Suggest that people use `python -m unittest ...` manually instead.
This also changes `bootstrap_test.py` to be easier to run standalone; see the commit for details.
|
|
Signed-off-by: hi-rustin <rustin.liu@gmail.com>
|
|
|
|
|
|
Switch some more Steps to `builder.msg`
In particular, this hides compiletest suites under a dropdown - some builders are configured with `verbose-tests`, which makes the suites take up many thousands of lines.
before:
```
Documenting stage1 cargo (x86_64-unknown-linux-gnu)
Check compiletest suite=rustdoc-js mode=js-doc-test (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
```
after:
```
::group::Documenting stage1 cargo (x86_64-unknown-linux-gnu)
::group::Testing stage1 compiletest suite=rustdoc-js mode=js-doc-test (x86_64-unknown-linux-gnu)
```
found this from https://github.com/rust-lang-ci/rust/actions/runs/5366993848/jobs/9736792611
r? `@oli-obk`
|
|
- fix tests when `--build` is set
- don't leak `config.example.toml` fd
- don't crash if `config.toml` doesn't exist yet
|
|
In particular, this hides compiletest suites under a dropdown - some builders are configured with `verbose-tests`, which makes the suites take up many thousands of lines.
before:
```
Documenting stage1 cargo (x86_64-unknown-linux-gnu)
Check compiletest suite=rustdoc-js mode=js-doc-test (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
```
after:
```
::group::Documenting stage1 cargo (x86_64-unknown-linux-gnu)
::group::Testing stage1 compiletest suite=rustdoc-js mode=js-doc-test (x86_64-unknown-linux-gnu)
```
|