This test's expected stderr now includes a count of the number of types
that implment `Error`. This PR introduces two new types, so increment
the number by two.
Update books
## nomicon
1 commits in 11f1165e8a2f5840467e748c8108dc53c948ee9a..c7d8467ca9158da58ef295ae65dbf00a308752d9
2022-03-19 16:02:00 -0400 to 2022-04-06 14:26:54 +0900
- Change "writers" to "readers" for Deref. (rust-lang/nomicon#346)
## reference
7 commits in c97d14fa6fed0baa9255432b8a93cb70614f80e3..b5f6c2362baf932db9440fbfcb509b309237ee85
2022-03-19 18:18:10 -0700 to 2022-04-10 19:19:51 -0700
- Fix typo: `?` should be inside `<sup>` tags (rust-lang/reference#1190)
- Update aarch64 to use neon as fp (rust-lang/reference#1184)
- Boolean literal expressions (rust-lang/reference#1189)
- Document that unary negation of a signed integer literal cannot cause an overflow error (rust-lang/reference#1188)
- Document compatibility between declarative and procedural macro tokens (rust-lang/reference#1169)
- Document native library modifier syntax and the `whole-archive` modifier specifically (rust-lang/reference#1170)
- Numeric literal expressions and literal suffixes (rust-lang/reference#1177)
## book
8 commits in ea90bbaf53ba64ef4e2da9ac2352b298aec6bec8..765318b844569a642ceef7bf1adab9639cbf6af3
2022-03-28 21:59:34 -0400 to 2022-04-12 21:14:47 -0400
- Propagate nostarch edits to src
- Propagate updated test example code to nostarch snapshot
- Edits to nostarch edits
- edits from nostarch
- Fix error message for the example code
- update ch13-02 to reflect changes in rust-lang/book#2797
- Update to 1.59
- Edits to chapter 2 after tech review
## rust-by-example
4 commits in ec954f35eedf592cd173b21c05a7f80a65b61d8a..c2a98d9fc5d29c481d42052fbeccfde15ed03116
2022-03-22 11:09:06 -0300 to 2022-04-08 06:44:18 -0300
- Code highlight a variable (rust-lang/rust-by-example#1530)
- Add a comment to note that warnings may not be shown in a browser in the Variable Bindings section (rust-lang/rust-by-example#1529)
- Make all new types have UpperCamelCase names in code example in the Aliasing section (rust-lang/rust-by-example#1528)
- Replace `C` with C/C++ (rust-lang/rust-by-example#1527)
## rustc-dev-guide
6 commits in 155126b1d2e2cb01ddb1d7ba9489b90d7cd173ad..eeb5a83c15b6ae60df3e4f19207376b22c6fbc4c
2022-03-22 14:34:21 +0100 to 2022-04-11 23:29:48 +0900
- method-lookup.md improvements (rust-lang/rustc-dev-guide#1296)
- Consolidate crates.io convention section (rust-lang/rustc-dev-guide#1326)
- Update examples with 1.61.0-nightly (latest version) (rust-lang/rustc-dev-guide#1330)
- r-a: Use `python3 x.py` instead of `./x.py` (rust-lang/rustc-dev-guide#1335)
- Update miri.md: correct a minor typo (rust-lang/rustc-dev-guide#1334)
- Add example how lints can be feature gated
Require all paths passed to `ShouldRun::paths` to exist on disk
This has two benefits:
1. There is a clearer mental model of how bootstrap works. Steps correspond to paths on disk unless it's strictly impossible for them to do so (e.g. dist components).
2. Bootstrap has better checks for internal consistency. This caught several issues:
- `src/sanitizers` doesn't exist; I changed it to just be a `sanitizers` alias.
- `src/tools/lld` doesn't exist; I removed it, since `lld` alone already works.
- `src/llvm` doesn't exist; removed it since `llvm` and `src/llvm-project` both work.
- `src/lldb_batchmode.py` doesn't exist, it was moved to `src/etc`.
- `install` was still using `src/librustc` instead of `compiler/rustc`.
- None of the tools in `dist` / `install` allowed using `src/tools/X` to build them. This might be intentional - I can change them to aliases if you like.
Builds on https://github.com/rust-lang/rust/pull/95901 and should not be merged before.
Respect ranlib specified for target during LLVM build
The ranlib specified for the target was never actually transferred
into the builder configuration. In the dist-x86_64-linux build we
ended up using ranlib instead of llvm-ranlib.
Found this investigating a build failure in #94214.
Make `x test --stage 2 compiler/rustc_XXX` faster to run
Previously, bootstrap unconditionally rebuilt the stage 2 compiler,
even if it had previously built stage 1. This changes it to reuse stage 1 if possible.
In particular, it no longer runs the following step:
```
Building stage1 compiler artifacts (x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu) -> x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu))
```
Add codegen tests for additional cases where noop iterators get optimized away
Optimizations have improved over time and now LLVM manages to optimize more in-place-collect noop-iterators to O(1) functions. This updates the codegen test to match.
Many but not all cases reported in #79308 work now.
Report undeclared lifetimes during late resolution.
First step in https://github.com/rust-lang/rust/pull/91557
We reuse the rib design of the current resolution framework. Specific `LifetimeRib` and `LifetimeRibKind` types are introduced. The most important variant is `LifetimeRibKind::Generics`, which happens each time we encounter something which may introduce generic lifetime parameters. It can be an item or a `for<...>` binder. The `LifetimeBinderKind` specifies how this rib behaves with respect to in-band lifetimes.
r? `@petrochenkov`
Refactor HIR item-like traversal (part 1)
Issue #95004
- Create hir_crate_items query which traverses tcx.hir_crate(()).owners to return a hir::ModuleItems
- use tcx.hir_crate_items in tcx.hir().items() to return an iterator of hir::ItemId
- use tcx.hir_crate_items to introduce a tcx.hir().par_items(impl Fn(hir::ItemId)) to traverse all items in parallel;
Signed-off-by: Miguel Guarniz <mi9uel9@gmail.com>
cc `@cjgillot`
Speed up Vec::clear().
Currently it just calls `truncate(0)`. `truncate()` is (a) not marked as
`#[inline]`, and (b) more general than needed for `clear()`.
This commit changes `clear()` to do the work itself. This modest change
was first proposed in rust-lang#74172, where the reviewer rejected it because
there was insufficient evidence that `Vec::clear()`'s performance
mattered enough to justify the change. Recent changes within rustc have
made `Vec::clear()` hot within `macro_parser.rs`, so the change is now
clearly worthwhile.
Although it doesn't show wins on CI perf runs, this seems to be because they
use PGO. But not all platforms currently use PGO. Also, local builds don't use
PGO, and `truncate` sometimes shows up in an over-represented fashion in local
profiles. So local profiling will be made easier by this change.
Note that this will also benefit `String::clear()`, because it just
calls `Vec::clear()`.
Finally, the commit removes the `vec-clear.rs` codegen test. It was
added in #52908. From before then until now, `Vec::clear()` just called
`Vec::truncate()` with a zero length. The body of Vec::truncate() has
changed a lot since then. Now that `Vec::clear()` is doing actual work
itself, and not just calling `Vec::truncate()`, it's not surprising that
its generated code includes a load and an icmp. I think it's reasonable
to remove this test.
r? `@m-ou-se`
Strict provenance lint diagnostics improvements
Use `multipart_suggestion` instead of `span_suggestion` and getting a snippet for the expression. Also don't suggest unnecessary parenthesis in `lossy_provenance_casts`.
cc ``@estebank``
``@rustbot`` label A-diagnostics
Make the debug output for `TargetSelection` less verbose
In particular, this makes the output of `x build -vv` easier to read.
Before:
```
c Sysroot { compiler: Compiler { stage: 0, host: TargetSelection { triple: "x86_64-unknown-linux-gnu", file: None } } }
```
After:
```
c Sysroot { compiler: Compiler { stage: 0, host: x86_64-unknown-linux-gnu } }
```
htmldocck: Compare HTML tree instead of plain text html
This PR improves `htmldocck` by comparing HTML trees instead of plain text html in the case of doing a ```@snapshot``` test.
This fix the [CI issue](https://github.com/rust-lang-ci/rust/runs/5964305020?check_suite_focus=true) encounter in https://github.com/rust-lang/rust/pull/95813 where for some unknown reason one of the attributes is not always at the same place.
The code is largely based on 3a1ba9de2f/formencode/doctest_xml_compare.py (L72-L120) which is behind MIT License. The comparison function is straightforward except for the `text_compare` function which does some weird stuff that we may want to simply reduce to a plain old comparison.
r? ``@GuillaumeGomez``
This has two benefits:
1. There is a clearer mental model of how bootstrap works. Steps correspond to paths on disk unless it's strictly impossible for them to do so (e.g. dist components).
2. Bootstrap has better checks for internal consistency. This caught several issues:
- `src/sanitizers` doesn't exist; I changed it to just be a `sanitizers` alias.
- `src/tools/lld` doesn't exist; I removed it, since `lld` alone already works.
- `src/llvm` doesn't exist; removed it since `llvm` and `src/llvm-project` both work.
- `src/lldb_batchmode.py` doesn't exist, it was moved to `src/etc`.
- `install` was still using `src/librustc` instead of `compiler/rustc`.
- None of the tools in `dist` / `install` allowed using `src/tools/X` to build them. This might be intentional - I can change them to aliases if you like.
rustdoc: Rename `def_id` into `item_id` when the type is `ItemId` for readability
As `@notriddle` mentioned in https://github.com/rust-lang/rust/pull/96091, the field name is inaccurate. This PR fixes it by renaming it accordingly to its real type.
r? `@notriddle`
Parse inner attributes on inline const block
According to https://github.com/rust-lang/rust/pull/84414#issuecomment-826150936, inner attributes are intended to be supported *"in all containers for statements (or some subset of statements)"*.
This PR adds inner attribute parsing and pretty-printing for inline const blocks (https://github.com/rust-lang/rust/issues/76001), which contain statements just like an unsafe block or a loop body.
```rust
let _ = const {
#![allow(...)]
let x = ();
x
};
```
Fix `x test --doc --stage 0 library/std`
I managed to break this in https://github.com/rust-lang/rust/pull/95449.
I am not quite sure why this is the correct fix, but it doesn't break `doc --stage 0`
and is strictly closer to the previous behavior.
Previously, rustdoc would error with strange issues because of the mismatched sysroot:
```
error[E0460]: found possibly newer version of crate `std` which `rustc_span` depends on
--> /home/jnelson/rust-lang/rust/compiler/rustc_lint_defs/src/lib.rs:14:5
|
14 | use rustc_span::{sym, symbol::Ident, Span, Symbol};
| ^^^^^^^^^^
|
= note: perhaps that crate needs to be recompiled?
= note: the following crate versions were found:
crate `std`: /home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-ff9290e971253a38.rlib
crate `std`: /home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-ff9290e971253a38.so
crate `rustc_span`: /home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_span-ed11dce30c1766f9.rlib
```
clarify doc(cfg) wording
The current "This is supported" wording implies that it's possible to
still use the item on other configurations, but in an unsupported way.
Changing this to "Available" removes this ambiguity.
Update GitHub Actions actions/checkout Version v2 -> v3
Update `actions/checkout@v2` to `actions/checkout@v3` because of Node12 will be out of life after Aril 30, 2022 [[Reference](https://nodejs.org/en/about/releases/)].
`actions/xxxx@v3` use Node16 whose support lasts until April 30, 2024.
resolve: Create dummy bindings for all unresolved imports
Apparently such bindings weren't previously created for all unresolved imports, causing issues like https://github.com/rust-lang/rust/issues/95879.
In this PR I'm trying to create such dummy bindings in a more centralized way by calling `import_dummy_binding` once for all imports in `finalize_imports`.
Fixes https://github.com/rust-lang/rust/issues/95879.
Rollup of 9 pull requests
Successful merges:
- #93969 (Only add codegen backend to dep info if -Zbinary-dep-depinfo is used)
- #94605 (Add missing links in platform support docs)
- #95372 (make unaligned_references lint deny-by-default)
- #95859 (Improve diagnostics for unterminated nested block comment)
- #95961 (implement SIMD gather/scatter via vector getelementptr)
- #96004 (Consider lifetimes when comparing types for equality in MIR validator)
- #96050 (Remove some now-dead code that was only relevant before deaggregation.)
- #96070 ([test] Add test cases for untested functions for BTreeMap)
- #96099 (MaybeUninit array cleanup)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Better method call error messages
Rebase/continuation of #71827
~Based on #92360~
~Based on #93118~
There's a decent description in #71827 that I won't copy here (for now at least)
In addition to rebasing, I've tried to restore most of the original suggestions for invalid arguments. Unfortunately, this does make some of the errors a bit verbose. To fix this will require a bit of refactoring to some of the generalized error suggestion functions, and I just don't have the time to go into it right now.
I think this is in a state that the error messages are overall better than before without a reduction in the suggestions given.
~I've tried to split out some of the easier and self-contained changes into separate commits (mostly in #92360, but also one here). There might be more than can be done here, but again just lacking time.~
r? `@estebank` as the original reviewer of #71827
This attempts to bring better error messages to invalid method calls, by applying some heuristics to identify common mistakes.
The algorithm is inspired by Levenshtein distance and longest common sub-sequence. In essence, we treat the types of the function, and the types of the arguments you provided as two "words" and compute the edits to get from one to the other.
We then modify that algorithm to detect 4 cases:
- A function input is missing
- An extra argument was provided
- The type of an argument is straight up invalid
- Two arguments have been swapped
- A subset of the arguments have been shuffled
(We detect the last two as separate cases so that we can detect two swaps, instead of 4 parameters permuted.)
It helps to understand this argument by paying special attention to terminology: "inputs" refers to the inputs being *expected* by the function, and "arguments" refers to what has been provided at the call site.
The basic sketch of the algorithm is as follows:
- Construct a boolean grid, with a row for each argument, and a column for each input. The cell [i, j] is true if the i'th argument could satisfy the j'th input.
- If we find an argument that could satisfy no inputs, provided for an input that can't be satisfied by any other argument, we consider this an "invalid type".
- Extra arguments are those that can't satisfy any input, provided for an input that *could* be satisfied by another argument.
- Missing inputs are inputs that can't be satisfied by any argument, where the provided argument could satisfy another input
- Swapped / Permuted arguments are identified with a cycle detection algorithm.
As each issue is found, we remove the relevant inputs / arguments and check for more issues. If we find no issues, we match up any "valid" arguments, and start again.
Note that there's a lot of extra complexity:
- We try to stay efficient on the happy path, only computing the diagonal until we find a problem, and then filling in the rest of the matrix.
- Closure arguments are wrapped in a tuple and need to be unwrapped
- We need to resolve closure types after the rest, to allow the most specific type constraints
- We need to handle imported C functions that might be variadic in their inputs.
I tried to document a lot of this in comments in the code and keep the naming clear.
