| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
parentheses, but they are after a newline
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
|
|
style: Never break within a nullary function call `func()` or a unit literal `()`
Implements https://github.com/rust-lang/style-team/issues/210
|
|
rustdoc-json: Remove newlines from attributes
Fixes #140689
Not sure if this needs to bump `FORMAT_VERSION` or not.
r? ``@GuillaumeGomez``
cc ``@obi1kenobi``
|
|
Only prefer param-env candidates if they remain non-global after norm
Introduce `CandidateSource::GlobalParamEnv`, and dynamically compute the `CandidateSource` based on whether the predicate contains params *post-normalization*.
This code needs some cleanup and documentation. I'm just putting this up for review.
cc https://github.com/rust-lang/trait-system-refactor-initiative/issues/179
r? lcnr
|
|
allow deref patterns to participate in exhaustiveness analysis
Per [this proposal](https://hackmd.io/4qDDMcvyQ-GDB089IPcHGg#Exhaustiveness), this PR allows deref patterns to participate in exhaustiveness analysis. Currently all deref patterns enforce `DerefPure` bounds on their scrutinees, so this assumes all patterns it's analyzing are well-behaved. This also doesn't support [mixed exhaustiveness](https://hackmd.io/4qDDMcvyQ-GDB089IPcHGg#Mixed-exhaustiveness), and instead emits an error if deref patterns are used together with normal constructors. I think mixed exhaustiveness would be nice to have (especially if we eventually want to support arbitrary `Deref` impls[^1]), but it'd require more work to get reasonable diagnostics[^2].
Tracking issue for deref patterns: #87121
r? `@Nadrieril`
[^1]: Regardless of whether we support limited exhaustiveness checking for untrusted `Deref` or always require other arms to be exhaustive, I think it'd be useful to allow mixed matching for user-defined smart pointers. And it'd be strange if it worked there but not for `Cow`.
[^2]: I think listing out witnesses of non-exhaustiveness can be confusing when they're not necessarily disjoint, and when you only need to cover some of them, so we'd probably want special formatting and/or explanatory subdiagnostics. And if it's implemented similarly to unions, we'd probably also want some way of merging witnesses; the way witnesses for unions can appear duplicated is pretty unfortunate. I'm not sure yet how the diagnostics should look, especially for deeply nested patterns.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
`()`
|
|
|
|
|
|
|
|
r=jieyouxu
run-make-support: set rustc dylib path for cargo wrapper
Some run-make tests invoke Cargo via run_make_support::cargo(), but fail to execute correctly when rustc is built without rpath. In these setups, runtime loading of rustc’s shared libraries fails unless the appropriate dynamic library path is set manually.
This commit updates the cargo() wrapper to call set_host_compiler_dylib_path(), aligning its behavior with the existing rustc() wrapper: https://github.com/rust-lang/rust/blob/f76c7367c6363d33ddb5a93b5de0d158b2d827f6/src/tools/run-make-support/src/external_deps/rustc.rs#L39-L43
This ensures that Cargo invocations during tests inherit the necessary dylib paths, avoiding errors related to missing shared libraries in rpath-less builds.
Fixes part of #140738
|
|
r=jieyouxu
add armv5te-unknown-linux-gnueabi target maintainer
My employer is interested in having this target maintained and we already have some tests in our CI running for it.
armv5te-unknown-linux-gnueabi can be ticket off in #113739.
|
|
r=notriddle
[rustdoc] Ensure that temporary doctest folder is correctly removed even if doctests failed
Fixes #139899.
The bug was due to the fact that if any doctest fails for any reason, we call `exit` (or it's called inside `libtest` if not edition 2024), meaning that `TempDir`'s destructor isn't called, and therefore the temporary folder isn't cleaned up.
Took me a while to figure out how to reproduce but finally I was able to reproduce the bug with:
`````rust
#![doc(test(attr(deny(warnings))))]
//! ```
//! let a = 12;
//! ```
`````
And then I ensured that panicking doctests were cleaned up as well:
`````rust
//! ```
//! panic!();
//! ```
`````
And finally I checked if it was fixed for merged doctests too (`--edition 2024`).
To make this work, I needed to add a new public function in `libtest` too which would call a function once all tests have been run.
So only issue is: I have absolutely no idea how we can add a regression test for this fix. If anyone has an idea...
r? `@notriddle`
|
|
Separate dataflow analysis and results
`Analysis` gets put into `Results` with `EntryStates`, by `iterate_to_fixpoint`. This has two problems:
- `Results` is passed various places where only `Analysis` is needed.
- `EntryStates` is passed around mutably everywhere even though it is immutable.
This commit mostly separates `Analysis` from `Results` and fixes these two problems.
r? `@davidtwco`
|
|
|
|
Some run-make tests invoke Cargo via run_make_support::cargo(), but fail to
execute correctly when rustc is built without rpath. In these setups, runtime
loading of rustc’s shared libraries fails unless the appropriate dynamic library
path is set manually.
This commit updates the cargo() wrapper to call set_host_compiler_dylib_path(),
aligning its behavior with the existing rustc() wrapper:
https://github.com/rust-lang/rust/blob/f76c7367c6363d33ddb5a93b5de0d158b2d827f6/src/tools/run-make-support/src/external_deps/rustc.rs#L39
This ensures that Cargo invocations during tests inherit the necessary dylib
paths, avoiding errors related to missing shared libraries in rpath-less builds.
Fixes part of #140738
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #139518 (Stabilize precise capture syntax in style guide)
- #140398 (Fix backtrace for cygwin)
- #140719 (fix typo in autorefs lint doc example)
- #140724 (Update `compiler-builtins` to 0.1.158)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Stabilize precise capture syntax in style guide
Closes #138527
r? `@jieyouxu`
|
|
|
|
Remove duplicate impl of string unescape from parse_format
r? `@nnethercote`
|
|
rust-analyzer doesn't construct `DerefPattern(_)` constructors, so these
shouldn't crash. It looks like this is how slice patterns are
implemented too.
|
|
This does not yet handle the case of mixed deref patterns with normal
constructors; it'll ICE in `Constructor::is_covered_by`. That'll be
fixed in a later commit.
|
|
rustdoc: remove unportable markdown lint and old parser
Follow up https://github.com/rust-lang/rust/pull/127127
|
|
de-stabilize bench attribute
This has been soft-unstable since forever (https://github.com/rust-lang/rust/pull/64066), and shown in future-compat reports since Rust 1.77 (https://github.com/rust-lang/rust/pull/116274).
The feature covering `bench` itself is tracked in https://github.com/rust-lang/rust/issues/50297, which has been closed despite still having active feature gates referencing it.
Cc `@rust-lang/libs-api`
|
|
Signed-off-by: Hayashi Mikihiro <34ttrweoewiwe28@gmail.com>
|
|
Follow up https://github.com/rust-lang/rust/pull/127127
|
|
failed
|
|
Signed-off-by: Hayashi Mikihiro <34ttrweoewiwe28@gmail.com>
|
|
Signed-off-by: Hayashi Mikihiro <34ttrweoewiwe28@gmail.com>
|
|
Signed-off-by: Hayashi Mikihiro <34ttrweoewiwe28@gmail.com>
|
|
|
|
The 2 commands do the same thing.
Also, follow style used elsewhere in the guide.
|
|
`deref_patterns`: let string and byte string literal patterns peel references and smart pointers before matching
This follows up on #140028. Together, they allow using string and byte string literal patterns to match on smart pointers when `deref_patterns` is enabled. In particular, string literals can now match on `String`, subsuming the functionality of the `string_deref_patterns` feature.
More generally, this works by letting literals peel references (and smart pointers) before matching, similar to most other patterns, providing an answer to #44849. Though it's only partially implemented at this point: this doesn't yet let named const patterns peel before matching. The peeling logic is general enough to support named consts, but the typing rules for named const patterns would need adjustments to feel consistent (e.g. arrays would need rules to be usable as slices, and `const STR: &'static str` wouldn't be able to match on a `String` unless a rule was added to let it be used where a `str` is expected, similar to what #140028 did for literals).
This also allows string and byte string patterns to match on mutable references, following up on https://github.com/rust-lang/rust/pull/140028#discussion_r2053927512. Rather than forward the mutability of the scrutinee to literal patterns, I've opted to peel `&mut`s from the scrutinee. From a design point of view, this makes the behavior consistent with what would be expected from deref coercions using the methodology in the next paragraph. From a diagnostics point of view, this avoids labeling string and byte string patterns as "mutable references", which I think could be confusing. See [`byte-string-type-errors.rs`](https://github.com/rust-lang/rust/compare/master...dianne:rust:lit-deref-pats-p2?expand=1#diff-4a0dd9b164b67c706751f3c0b5762ddab08bcef05a91972beb0190c6c1cd3706) for how the diagnostics look.
At a high level, the peeling logic implemented here tries to mimic how deref coercions work for expressions: we peel references (and smart pointers) from the scrutinee until the pattern can match against it, and no more. This is primarily tested by [`const-pats-do-not-mislead-inference.rs`](https://github.com/rust-lang/rust/compare/master...dianne:rust:lit-deref-pats-p2?expand=1#diff-19afc05b8aae9a30fe4a3a8c0bc2ab2c56b58755a45cdf5c12be0d5e83c4739d). To illustrate the connection, I wasn't sure if this made sense to include in the test file, but I've translated those tests to make sure they give the same inference results as deref coercions: [(playground)](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=1869744cb9cdfed71a686990aadf9fe1). In each case, a reference to the scrutinee is coerced to have the type of the pattern (under a reference).
Tracking issue for deref patterns: #87121
r? `@oli-obk`
cc `@Nadrieril`
|
|
Unify sidebar buttons to use the same image
Part of https://github.com/rust-lang/rust/issues/139832.
The source sidebar looks like this with the new image:
You can test it [here](https://rustdoc.crud.net/imperio/sidebar-images/src/foo/foo.rs.html).
r? `@notriddle`
|
|
|
|
fix: Don't panic on some weird code
|
|
Signed-off-by: Hayashi Mikihiro <34ttrweoewiwe28@gmail.com>
|
|
Signed-off-by: Hayashi Mikihiro <34ttrweoewiwe28@gmail.com>
|
|
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
|
|
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
|
|
cfg_attr bit to doc_place bit
Signed-off-by: Hayashi Mikihiro <34ttrweoewiwe28@gmail.com>
|
|
|
|
Better handle parallelism in cache priming
|
|
It could be confusing if they see "Indexing n/n" but cache priming does not finish.
|
