| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Add intra-doc links to size_of_* functions
Also some smaller doc improvements.
|
|
r=Mark-Simulacrum
Allow everyone to set the beta-nominated label
It is allowed both in cargo and clippy's triagebot.toml, and nomination does not automatically mean that the PR will be backported.
|
|
fix: skip implied bounds if unconstrained lifetime exists
Fixes #110161
r? ````@aliemjay````
|
|
Add 1.69.0 release notes
cc ````@rust-lang/release````
r? ````@Mark-Simulacrum````
|
|
Temporarily disable the jobserver-error test
This test is failing randomly on CI. We don't have a handle on what might be causing it, so disable it for now to reduce disruption.
cc https://github.com/rust-lang/rust/issues/110321
|
|
bootstrap: drop some windows features
They became unused after https://github.com/rust-lang/rust/pull/109960
|
|
|
|
|
|
Bump to Rust 1.71.0
|
|
|
|
|
|
explicit `adt_dtorck_constraint` for `ManuallyDrop`
the only reason we didn't add outlives requirements when dropping `ManuallyDrop` was a fast-path in `trivial_dropck_outlives`. Explicitly acknowledge that fast-path in `adt_dtorck_constraint`
|
|
Only enable ConstProp at mir-opt-level >= 2.
That pass is not responsible for lints any more, so we can restrict it to optimized builds.
This reduces the amount of duplicated const-eval messages.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix rust-gdb on FreeBSD
"\w" is a GNU-specific extension to sed. Avoid it.
Fixes #110334
Signed-off-by: Alan Somers <asomers@gmail.com>
|
|
r=GuillaumeGomez
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>>`.
|
|
Co-authored-by: SNCPlay42 <SNCPlay42@gmail.com>
|
|
Reduce core counts for a number of builders
Best reviewed by-commit; first commit renames all builder names to include core counts.
Applied changes for these builders (only on the auto branch, haven't touched PR CI):
- arm-android -> 8 core (currently at 39 minutes; 25.58% CPU)
- armhf-gnu -> 8 core (currently at 31 minutes; 30.97% CPU)
- dist-aarch64-linux -> 8 core (currently at 35 minutes; 55.38% CPU)
- dist-android -> 8 core (currently at 18 minutes; 43.03% CPU)
- dist-armhf-linux -> 8 core (currently at 27 minutes; 54.71% CPU)
- dist-armv7-linux -> 8 core (currently at 29 minutes; 50.33% CPU)
- dist-i586-gnu-i586-i686-musl -> 8 core (currently at 27 minutes; 48.31% CPU)
- dist-i686-linux -> 8 core (currently at 32 minutes; 52.39% CPU)
- dist-mips-linux -> 8 core (currently at 25 minutes; 55.09% CPU)
- dist-mips64-linux -> 8 core (currently at 25 minutes; 55.33% CPU)
- dist-mips64el-linux -> 8 core (currently at 26 minutes; 54.93% CPU)
- dist-mipsel-linux -> 8 core (currently at 25 minutes; 55.38% CPU)
- dist-powerpc-linux -> 8 core (currently at 26 minutes; 55.77% CPU)
- dist-powerpc64-linux -> 8 core (currently at 27 minutes; 55.03% CPU)
- dist-powerpc64le-linux -> 8 core (currently at 27 minutes; 54.95% CPU)
- dist-riscv64-linux -> 8 core (currently at 26 minutes; 54.43% CPU)
- dist-s390x-linux -> 8 core (currently at 30 minutes; 55.97% CPU)
- dist-various-1 -> 8 core (currently at 36 minutes; 29.16% CPU)
- dist-various-2 -> 8 core (currently at 27 minutes; 32.69% CPU)
- dist-x86_64-freebsd -> 8 core (currently at 27 minutes; 51.69% CPU)
- dist-x86_64-illumos -> 8 core (currently at 30 minutes; 54.88% CPU)
- dist-x86_64-musl -> 8 core (currently at 39 minutes; 57.56% CPU)
- dist-x86_64-netbsd -> 8 core (currently at 26 minutes; 55.82% CPU)
- mingw-check -> 8 core (currently at 17 minutes; 35.00% CPU)
- test-various -> 8 core (currently at 22 minutes; 44.84% CPU)
- wasm32 -> 8 core (currently at 19 minutes; 62.94% CPU)
- x86_64-gnu -> 8 core (currently at 32 minutes; 50.31% CPU)
- x86_64-gnu-stable -> 8 core (currently at 32 minutes; 51.23% CPU)
- x86_64-gnu-aux -> 8 core (currently at 22 minutes; 46.39% CPU)
- x86_64-gnu-debug -> 8 core (currently at 21 minutes; 53.93% CPU)
- x86_64-gnu-distcheck -> 8 core (currently at 38 minutes; 55.93% CPU)
- x86_64-gnu-llvm-15 -> 8 core (currently at 34 minutes; 52.99% CPU)
- x86_64-gnu-llvm-14 -> 8 core (currently at 34 minutes; 52.09% CPU)
- x86_64-gnu-llvm-14-stage1 -> 8 core (currently at 33 minutes; 51.13% CPU)
- x86_64-gnu-nopt -> 8 core (currently at 29 minutes; 53.36% CPU)
- x86_64-gnu-tools -> 8 core (currently at 22 minutes; 40.56% CPU)
We may also want to look at merging some of these builders in the future (to deduplicate stage0 builds and such) but that can happen separately - and is more work than just adjusting core counts.
r? `@pietroalbini`
|
|
"\w" is a GNU-specific extension to sed. Avoid it.
Fixes #110334
Signed-off-by: Alan Somers <asomers@gmail.com>
|
|
|
|
|
|
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 :sweat_smile:)
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
|
|
r=notriddle
[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`
|
|
Remove some unneeded imports / qualified paths
Continuation of #105537.
|
|
Fix typos in library
I ran [`typos -w library`](https://github.com/crate-ci/typos) to fix typos in the `library` directory.
Refs #110150
|
|
Use `Display` in top-level example for `PanicInfo`
Addresses https://github.com/rust-lang/rust/issues/110098.
This confused me as well, when I was writing a `no_std` panic handler for the first time, so here's a better top-level example.
`Display` is stable, prints the `.message()` if available, and falls back to `.payload().downcast_ref<&str>()` if the message is not available. So this example should provide strictly more information and also work for formatted panics.
The old example still exists on the `payload` method.
|
|
Add links from `core::cmp` derives to their traits
Fixes #109946
Adds intra-doc links from the `core::cmp` derives to their respective traits, and a link to their derive behaviour
`@rustbot` label +A-docs
|
|
r=Amanieu
Add Command environment variable inheritance docs
The interaction between the environment variable methods can be confusing. Specifically `env_clear` and `remove_env` have a side effects not mentioned: they disable inheriting environment variables from the parent process. I wanted to fully document this behavior as well as explain relevant edge cases in each of the `Command` env methods.
This is further confused by the return of `get_envs` which will return key/None if `remove_env` has been used, but an empty iterator if `env_clear` has been called. Or a non-empty iterator if `env_clear` was called and later explicit mappings are added. Currently there is no way (that I'm able to find) of observing whether or not the internal `env_clear=true` been toggled on the `Command` struct via its public API.
Ultimately environment variable mappings can be in one of several states:
- Explicitly set value (via `envs` / `env`) will take precedence over parent mapping
- Not explicitly set, will inherit mapping from parent
- Explicitly removed via `remove_env`, this single mapping will not inherit from parent
- Implicitly removed via `env_clear`, no mappings will inherit from parent
I tried to represent this in the relevant sections of the docs.
This is my second-ever doc PR (whoop!). I'm happy to take specific or general doc feedback. Also happy to explain the logic behind any changes or additions I made.
|
|
compiler-errors:reformulate-point_at_expr_source_of_inferred_type, r=oli-obk
Reformulate `point_at_expr_source_of_inferred_type` to be more accurate
Be more accurate when deducing where along the several usages of a binding it is constrained to be some type that is incompatible with an expectation.
This also renames the method to `note_source_of_type_mismatch_constraint` because I prefer that name, though I guess I can revert that. (Also drive-by rename `note_result_coercion` -> `suggest_coercing_result_via_try_operator`, because it's suggesting, not noting!)
This PR is (probably?) best reviewed per commit, but it does regress a bit only to fix it later on, so it could also be reviewed as a whole if that makes the final results more clear.
r? `@estebank`
|
|
to a proc-macro and a trait at the same time
|
|
Add `libLLVM.so` to the target libdir when download-rustc is enabled
Previously, we would only add it to the host libdir, which meant it couldn't be loaded by `ui-fulldeps` tests that used rustc_private.
Fixes https://github.com/rust-lang/rust/issues/110225, fixes https://github.com/rust-lang/rust/issues/110226.
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
Add a stable MIR way to get the main function
This is useful for analysis tools that only analyze the code paths that a specific program actually goes through. Or for code generators built on top of stable MIR.
|
|
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
|
|
Add `tidy-alphabetical` to features in `alloc` & `std`
So that people have to keep them sorted in future, rather than just sticking them on the end where they conflict more often.
Follow-up to #110269
cc `@jyn514`
|
|
Add `tidy-alphabetical` to features in `core`
So that people have to keep them sorted in future, rather than just sticking them on the end where they conflict more often.
|
|
Add link to `collections` docs to `extend` trait
I believe it would be useful here.
|
|
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```
|
|
Stabilize rustdoc `--test-run-directory`
This should resolve https://github.com/rust-lang/rust/issues/84674
|
