We remove `src/tools/cargo` from rust-lang/rust root workspace, but
some underlying mechanism still needs it to be a member. for example,
`./x.py doc`. This little hack make cargo's metadata available by
invoking an extra `cargo metadata` for cargo the package itself.
Co-authored-by: Scott Schafer <schaferjscott@gmail.com>
Co-authored-by: Eric Huss <eric@huss.org>
This also
* bumps cargo to the latest in rust-lang/cargo.
* adds 0BSD to allowed list of licenses
Co-authored-by: Scott Schafer <schaferjscott@gmail.com>
Co-authored-by: Eric Huss <eric@huss.org>
Remove `TypeSuper{Foldable,Visitable}` impls for `Region`.
These traits exist so that folders/visitors can recurse into types of interest: binders, types, regions, predicates, and consts. But `Region` is non-recursive and cannot contain other types of interest, so its methods in these traits are trivial.
This commit inlines and removes those trivial methods.
r? `@compiler-errors`
Rollup of 8 pull requests
Successful merges:
- #110033 (Add 1.69.0 release notes)
- #110272 (fix: skip implied bounds if unconstrained lifetime exists)
- #110307 (Allow everyone to set the beta-nominated label)
- #110347 (Add intra-doc links to size_of_* functions)
- #110350 (Add a UI test for #79605)
- #110356 (Fix `x test rust-installer` when `cargo` is set to a relative path)
- #110364 (remove redundant clones)
- #110366 (fix some clippy::complexity)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
These traits exist so that folders/visitors can recurse into types of
interest: binders, types, regions, predicates, and consts. But `Region`
is non-recursive and cannot contain other types of interest, so its
methods in these traits are trivial.
This commit inlines and removes those trivial methods.
Fix `x test rust-installer` when `cargo` is set to a relative path
Previously, this would give an error because the shell script had a different working directory:
```
test: basic_install
$ sh /home/jyn/src/rust/src/tools/rust-installer/gen-installer.sh --image-dir=/home/jyn/src/rust/src/tools/rust-installer/test/image1 --work-dir=/home/jyn/src/rust/build/x86_64-unknown-linux-gnu/test/rust-installer/workdir --output-dir=/home/jyn/src/rust/build/x86_64-unknown-linux-gnu/test/rust-installer/outdir
/home/jyn/src/rust/src/tools/rust-installer/gen-installer.sh: 15: ../rust3/build/host/stage2-tools-bin/cargo: not found
TEST FAILED!
```
[compiletest] Add more test ignore reasons, `needs-` validation, and improved error messages
This PR makes more improvements to the way compiletest ignoring headers are handled, following up on #108905:
* Human-readable ignore reasons have been added for the remaining ignore causes (`needs-*` directives, `*llvm*` directives, and debugger version directives). All ignored tests should now have a human-readable reason.
* The code handling `needs-*` directives has been refactored, and now invalid `needs-*` directive emit errors like `ignore-*` and `only-*`.
* All errors are now displayed at startup (with line numbers) rather than just the first error of the first file.
This PR is best reviewed commit-by-commit.
r? `@ehuss`
Previously, this would give an error because the shell script had a
different working directory:
```
test: basic_install
$ sh /home/jyn/src/rust/src/tools/rust-installer/gen-installer.sh --image-dir=/home/jyn/src/rust/src/tools/rust-installer/test/image1 --work-dir=/home/jyn/src/rust/build/x86_64-unknown-linux-gnu/test/rust-installer/workdir --output-dir=/home/jyn/src/rust/build/x86_64-unknown-linux-gnu/test/rust-installer/outdir
/home/jyn/src/rust/src/tools/rust-installer/gen-installer.sh: 15: ../rust3/build/host/stage2-tools-bin/cargo: not found
TEST FAILED!
```
rustdoc-search: add support for nested generics
This change allows `search.js` to parse nested generics (which look `Like<This<Example>>`) and match them. It maintains the existing "bag semantics", so that the order of type parameters is ignored but the number is required to be greater than or equal to what's in the query.
For example, a function with the signature `fn read_all(&mut self: impl Read) -> Result<Vec<u8>, Error>` will match these queries:
* `Read -> Result<Vec<u8>, Error>`
* `Read -> Result<Error, Vec>`
* `Read -> Result<Vec<u8>>`
But it *does not* match `Result<Vec, u8>` or `Result<u8<Vec>>`.
Do not attempt to commute comparison and cast to codegen discriminants
The general algorithm to compute a discriminant is:
```
relative_tag = tag - niche_start
is_niche = relative_tag <= (ule) relative_max
discr = if is_niche {
cast(relative_tag) + niche_variants.start()
} else {
untagged_variant
}
```
We have an optimization branch which attempts to merge the addition and the subtraction by commuting them with the cast. We currently get this optimization wrong.
This PR takes the easiest and safest way: remove the optimization, and let LLVM handle it. (Perf may not agree with that course of action 😅)
There may be a less invasive solution, but I don't have the necessary knowledge of LLVM semantics to find it. Cranelift has the same optimization, which should be handled similarly.
cc `@nikic` and `@bjorn3` if you have a better solution.
Fixes https://github.com/rust-lang/rust/issues/110128
Rollup of 7 pull requests
Successful merges:
- #108687 (Reformulate `point_at_expr_source_of_inferred_type` to be more accurate)
- #109272 (Add Command environment variable inheritance docs)
- #109947 (Add links from `core::cmp` derives to their traits)
- #110110 (Use `Display` in top-level example for `PanicInfo`)
- #110154 (Fix typos in library)
- #110244 (Remove some unneeded imports / qualified paths)
- #110328 ([rustdoc] Add explanations for auto-disambiguation when an intra doc link is resolved to a proc-macro and a trait at the same time)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
[rustdoc] Add explanations for auto-disambiguation when an intra doc link is resolved to a proc-macro and a trait at the same time
Part of https://github.com/rust-lang/rust/issues/110111.
r? `@notriddle`
Rollup of 7 pull requests
Successful merges:
- #103682 (Stabilize rustdoc `--test-run-directory`)
- #106249 (Create "suggested tests" tool in `rustbuild`)
- #110047 (Add link to `collections` docs to `extend` trait)
- #110269 (Add `tidy-alphabetical` to features in `core`)
- #110292 (Add `tidy-alphabetical` to features in `alloc` & `std`)
- #110305 (rustdoc-search: use ES6 `Map` and `Set` where they make sense)
- #110315 (Add a stable MIR way to get the main function)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc-search: use ES6 `Map` and `Set` where they make sense
Since all supported browsers now support these classes, and rustdoc has started using them in some places, it might as well use them everywhere it makes sense (because, as [MDN's Map page] says, it "performs better in scenarios involving frequent additions and removals of key-value pairs.").
[MDN's Map page]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map
Create "suggested tests" tool in `rustbuild`
Not the claimed person in #97339 but:
I've done a very rough implementation of this feature in-tree. I'm very new to `rustc` development (outside of docs) so some help would be greatly appreciated. The UI of this new subcommand obviously will change and I need some mentoring with the `--run` flag.
r? ```@jyn514```
fix running Miri tests
This partially reverts https://github.com/rust-lang/rust/pull/108659 to fix https://github.com/rust-lang/rust/issues/110102: the Miri test runner does not support any flags, they are interpreted as filters instead which leads to no tests being run.
I have not checked any of the other test runners for whether they are having any trouble with these flags.
Cc `@pietroalbini` `@Mark-Simulacrum` `@jyn514`
rustdoc: Correctly handle built-in compiler proc-macros as proc-macro and not macro
Part of https://github.com/rust-lang/rust/issues/110111.
There were actually one issue split in two parts:
* Compiler built-in proc-macro were incorrectly considered as macros and not proc-macros.
* Re-exports of compiler built-in proc-macros were considering them as macros.
Both issues can be fixed by looking at the `MacroKind` variant instead of just relying on information extracted later on.
r? ``@fmease``
resolve: Pre-compute non-reexport module children
Instead of repeating the same logic by walking HIR during metadata encoding.
The only difference is that we are no longer encoding `macro_rules` items, but we never currently need them as a part of this list. They can be encoded separately if this need ever arises.
`module_reexports` is also un-querified, because I don't see any reasons to make it a query, only overhead.
