From ff2b6fd0cb43c123e43f68673d2a82bbe6671595 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Ber=C3=A1nek?= Date: Thu, 8 May 2025 16:00:48 +0200 Subject: [PATCH 1/4] Mention fast try builds in the rustc-dev-guide --- src/tests/ci.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/src/tests/ci.md b/src/tests/ci.md index c04f296b..825be11c 100644 --- a/src/tests/ci.md +++ b/src/tests/ci.md @@ -135,12 +135,16 @@ There are several use-cases for try builds: - Run a specific CI job (e.g. Windows tests) on a PR, to quickly test if it passes the test suite executed by that job. -You can select which CI jobs will -be executed in the try build by adding lines containing `try-job: -` to the PR description. All such specified jobs will be executed -in the try build once the `@bors try` command is used on the PR. If no try -jobs are specified in this way, the jobs defined in the `try` section of -[`jobs.yml`] will be executed by default. +By default, if you send a comment with `@bors try`, the jobs defined in the `try` section of +[`jobs.yml`] will be executed. We call this mode a "fast try build". Such a try build +will not execute any tests, and it will allow compilation warnings. It is useful when you want to +get an optimized toolchain as fast as possible, for a crater run or performance benchmarks, +even if it might not be working fully correctly. + +If you want to run a custom CI job in a try build and make sure that it passes all tests and does +not produce any compilation warnings, you can select CI jobs to be executed by adding lines +containing `try-job: ` to the PR description. All such specified jobs will be executed +in the try build once the `@bors try` command is used on the PR. Each pattern can either be an exact name of a job or a glob pattern that matches multiple jobs, for example `*msvc*` or `*-alt`. You can start at most 20 jobs in a single try build. When using From b82a852640e3514b3e64a141d56198b4fc92e62b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tomasz=20Mi=C4=85sko?= Date: Fri, 9 May 2025 10:36:07 +0200 Subject: [PATCH 2/4] Remove mono item collection strategy override from -Zprint-mono-items Previously `-Zprint-mono-items` would override the mono item collection strategy. When debugging one doesn't want to change the behaviour, so this was counter productive. Additionally, the produced behaviour was artificial and might never arise without using the option in the first place (`-Zprint-mono-items=eager` without `-Clink-dead-code`). Finally, the option was incorrectly marked as `UNTRACKED`. Resolve those issues, by turning `-Zprint-mono-items` into a boolean flag that prints results of mono item collection without changing the behaviour of mono item collection. For codegen-units test incorporate `-Zprint-mono-items` flag directly into compiletest tool. Test changes are mechanical. `-Zprint-mono-items=lazy` was removed without additional changes, and `-Zprint-mono-items=eager` was turned into `-Clink-dead-code`. Linking dead code disables internalization, so tests have been updated accordingly. --- src/tests/compiletest.md | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/src/tests/compiletest.md b/src/tests/compiletest.md index 2c35381e..0ba078f0 100644 --- a/src/tests/compiletest.md +++ b/src/tests/compiletest.md @@ -325,12 +325,8 @@ The tests in [`tests/codegen-units`] test the [monomorphization](../backend/monomorph.md) collector and CGU partitioning. These tests work by running `rustc` with a flag to print the result of the -monomorphization collection pass, and then special annotations in the file are -used to compare against that. - -Each test should be annotated with the `//@ -compile-flags:-Zprint-mono-items=VAL` directive with the appropriate `VAL` to -instruct `rustc` to print the monomorphization information. +monomorphization collection pass, i.e., `-Zprint-mono-items`, and then special +annotations in the file are used to compare against that. Then, the test should be annotated with comments of the form `//~ MONO_ITEM name` where `name` is the monomorphized string printed by rustc like `fn Date: Mon, 12 May 2025 11:15:46 +0200 Subject: [PATCH 3/4] Fix typos --- src/autodiff/installation.md | 2 +- src/rustdoc-internals/rustdoc-test-suite.md | 8 ++++---- src/type-checking.md | 2 +- src/type-inference.md | 2 +- src/typing_parameter_envs.md | 8 ++++---- 5 files changed, 11 insertions(+), 11 deletions(-) diff --git a/src/autodiff/installation.md b/src/autodiff/installation.md index f3c11395..c9b28dc4 100644 --- a/src/autodiff/installation.md +++ b/src/autodiff/installation.md @@ -1,6 +1,6 @@ # Installation -In the near future, `std::autodiff` should become available in nightly builds for users. As a contribute however, you will still need to build rustc from source. Please be aware that the msvc target is not supported at the moment, all other tier 1 targets should work. Please open an issue if you encounter any problems on a supported tier 1 target, or if you succesfully build this project on a tier2/tier3 target. +In the near future, `std::autodiff` should become available in nightly builds for users. As a contributor however, you will still need to build rustc from source. Please be aware that the msvc target is not supported at the moment, all other tier 1 targets should work. Please open an issue if you encounter any problems on a supported tier 1 target, or if you successfully build this project on a tier2/tier3 target. ## Build instructions diff --git a/src/rustdoc-internals/rustdoc-test-suite.md b/src/rustdoc-internals/rustdoc-test-suite.md index 169b95a7..bad7ac19 100644 --- a/src/rustdoc-internals/rustdoc-test-suite.md +++ b/src/rustdoc-internals/rustdoc-test-suite.md @@ -16,10 +16,10 @@ In addition to the directives listed here, `rustdoc` tests also support most [compiletest directives](../tests/directives.html). -All `PATH`s in directives are relative to the the rustdoc output directory (`build/TARGET/test/rustdoc/TESTNAME`), +All `PATH`s in directives are relative to the rustdoc output directory (`build/TARGET/test/rustdoc/TESTNAME`), so it is conventional to use a `#![crate_name = "foo"]` attribute to avoid having to write a long crate name multiple times. -To avoid repetion, `-` can be used in any `PATH` argument to re-use the previous `PATH` argument. +To avoid repetition, `-` can be used in any `PATH` argument to re-use the previous `PATH` argument. All arguments take the form of quoted strings (both single and double quotes are supported), @@ -87,7 +87,7 @@ compiletest's `--bless` flag is forwarded to htmldocck. Usage: `//@ has-dir PATH` -Checks for the existance of directory `PATH`. +Checks for the existence of directory `PATH`. ### `files` @@ -106,7 +106,7 @@ Example: `//@ files "foo/bar" '["index.html", "sidebar-items.js"]'` ## Limitations `htmldocck.py` uses the xpath implementation from the standard library. This leads to several limitations: -* All `XPATH` arguments must start with `//` due to a flaw in the implemention. +* All `XPATH` arguments must start with `//` due to a flaw in the implementation. * Many XPath features (functions, axies, etc.) are not supported. * Only well-formed HTML can be parsed (hopefully rustdoc doesn't output mismatched tags). diff --git a/src/type-checking.md b/src/type-checking.md index b6069420..4e8b30b1 100644 --- a/src/type-checking.md +++ b/src/type-checking.md @@ -17,7 +17,7 @@ Type "collection" is the process of converting the types found in the HIR **internal representation** used by the compiler (`Ty<'tcx>`) – we also do similar conversions for where-clauses and other bits of the function signature. -To try and get a sense for the difference, consider this function: +To try and get a sense of the difference, consider this function: ```rust,ignore struct Foo { } diff --git a/src/type-inference.md b/src/type-inference.md index c03fa36d..888eb243 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -19,7 +19,7 @@ Here, the type of `things` is *inferred* to be `Vec<&str>` because of the value we push into `things`. The type inference is based on the standard Hindley-Milner (HM) type inference -algorithm, but extended in various way to accommodate subtyping, region +algorithm, but extended in various ways to accommodate subtyping, region inference, and higher-ranked types. ## A note on terminology diff --git a/src/typing_parameter_envs.md b/src/typing_parameter_envs.md index 757296d1..67eaf51b 100644 --- a/src/typing_parameter_envs.md +++ b/src/typing_parameter_envs.md @@ -4,7 +4,7 @@ ## Typing Environments -When interacting with the type system there are a few variables to consider that can affect the results of trait solving. The the set of in-scope where clauses, and what phase of the compiler type system operations are being performed in (the [`ParamEnv`][penv] and [`TypingMode`][tmode] structs respectively). +When interacting with the type system there are a few variables to consider that can affect the results of trait solving. The set of in-scope where clauses, and what phase of the compiler type system operations are being performed in (the [`ParamEnv`][penv] and [`TypingMode`][tmode] structs respectively). When an environment to perform type system operations in has not yet been created, the [`TypingEnv`][tenv] can be used to bundle all of the external context required into a single type. @@ -13,11 +13,11 @@ Once a context to perform type system operations in has been created (e.g. an [` [ocx]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/traits/struct.ObligationCtxt.html [fnctxt]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_typeck/fn_ctxt/struct.FnCtxt.html -## Parameter Environemnts +## Parameter Environments ### What is a `ParamEnv` -The [`ParamEnv`][penv] is a list of in-scope where-clauses, it typically corresponds to a specific item's where clauses. Some clauses are not explicitly written but are instead are implicitly added in the [`predicates_of`][predicates_of] query, such as `ConstArgHasType` or (some) implied bounds. +The [`ParamEnv`][penv] is a list of in-scope where-clauses, it typically corresponds to a specific item's where clauses. Some clauses are not explicitly written but are instead implicitly added in the [`predicates_of`][predicates_of] query, such as `ConstArgHasType` or (some) implied bounds. In most cases `ParamEnv`s are initially created via the [`param_env` query][query] which returns a `ParamEnv` derived from the provided item's where clauses. A `ParamEnv` can also be created with arbitrary sets of clauses that are not derived from a specific item, such as in [`compare_method_predicate_entailment`][method_pred_entailment] where we create a hybrid `ParamEnv` consisting of the impl's where clauses and the trait definition's function's where clauses. @@ -73,7 +73,7 @@ fn foo2(a: T) { ### Acquiring a `ParamEnv` -Using the wrong [`ParamEnv`][penv] when interacting with the type system can lead to ICEs, illformed programs compiling, or erroing when we shouldn't. See [#82159](https://github.com/rust-lang/rust/pull/82159) and [#82067](https://github.com/rust-lang/rust/pull/82067) as examples of PRs that modified the compiler to use the correct param env and in the process fixed ICEs. +Using the wrong [`ParamEnv`][penv] when interacting with the type system can lead to ICEs, illformed programs compiling, or erroring when we shouldn't. See [#82159](https://github.com/rust-lang/rust/pull/82159) and [#82067](https://github.com/rust-lang/rust/pull/82067) as examples of PRs that modified the compiler to use the correct param env and in the process fixed ICEs. In the large majority of cases, when a `ParamEnv` is required it either already exists somewhere in scope, or above in the call stack and should be passed down. A non exhaustive list of places where you might find an existing `ParamEnv`: - During typeck `FnCtxt` has a [`param_env` field][fnctxt_param_env] From 5012fc30165d4c28ec6ade4c342d1f54aa2700af Mon Sep 17 00:00:00 2001 From: The rustc-dev-guide Cronjob Bot Date: Thu, 15 May 2025 09:46:15 +0000 Subject: [PATCH 4/4] Preparing for merge from rustc --- rust-version | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rust-version b/rust-version index ec160228..5e4266f6 100644 --- a/rust-version +++ b/rust-version @@ -1 +1 @@ -7e552b46af72df390ed233b58a7f51650515b2a8 +414482f6a0d4e7290f614300581a0b55442552a3