| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Add mermaid graphs of NLL regions and SCCs to polonius MIR dump
This PR expands the polonius MIR dump again with a couple of mermaid charts ported from the graphviz version:
- the NLL region graph
- and the NLL SCCs
I still have done zero visual design on this until now, but [here's](https://gistpreview.github.io/?fbbf900fed2ad21108c7ca0353456398) how it looks (i.e. still bad) just to give an idea of the result.
r? `````@matthewjasper````` (feel free to reassign) or anyone
|
|
Rename `Piece::String` to `Piece::Lit`
This renames Piece::String to Piece::Lit to avoid shadowing std::string::String and removes "pub use Piece::*;".
|
|
r=lcnr
Do not consider child bound assumptions for rigid alias
r? lcnr
See first commit for the important details. For second commit, I also stacked a somewhat opinionated name change, though I can separate that if needed.
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/149
|
|
[cfg_match] Document the use of expressions.
cc #115585
Adds documentation to this new feature introduced in #133720.
|
|
Clippy subtree update
r? `@Manishearth`
Quite a bit late, as I was on vacation and then we had an issue in MacOS CI after the sync.
|
|
Rollup of 9 pull requests
Successful merges:
- #135869 (Make docs for AtomicUsize::from_mut platform-independent)
- #135892 (-Znext-solver: "normalize" signature before checking it mentions self in `deduce_closure_signature`)
- #136055 (Implement MIR const trait stability checks)
- #136066 (Pass spans to `perform_locally_in_new_solver`)
- #136071 ([Clippy] Add vec_reserve & vecdeque_reserve diagnostic items)
- #136124 (Arbitrary self types v2: explain test.)
- #136149 (Flip the `rustc-rayon`/`indexmap` dependency order)
- #136173 (Update comments and sort target_arch in c_char_definition)
- #136178 (Update username in build helper example)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
clippy-subtree-update
|
|
|
|
r? @ghost
changelog: none
|
|
|
|
|
|
Apply LTO config to rustdoc
Before, the LTO configuration from `config.toml` was not applied to `rustdoc`. This provides a small perf. and binary size [win](https://github.com/rust-lang/rust/pull/112049#issuecomment-2605131041) for doc builds.
Since this is configured with Cargo profiles and not rustflags, it should not break tool build cache (https://github.com/rust-lang/rust/pull/131155). I tried to run `x test miri`, `x test rustdoc` and `x test miri` and nothing was rebuilt.
r? `@onur-ozkan`
|
|
Update username in build helper example
no typos have been made in the process of creating this pull request
r? pietroalbini
|
|
Update comments and sort target_arch in c_char_definition
Follow-up to https://github.com/rust-lang/rust/pull/132975.
- Clang's wrong default on MSP430 has been fixed in https://github.com/llvm/llvm-project/pull/115964, and will be included in LLVM 20, which will be used soon.
- Add a reference on Xtensa's default (from https://github.com/rust-lang/rust/pull/132975#issuecomment-2484645240).
- Fix link for Windows's default.
- Add a link to the discussion on L4Re (https://github.com/rust-lang/rust/pull/132975#issuecomment-2484645240)
- Sort `target_arch`. (now match with `target_arch`s in comments)
r? `@tgross35`
|
|
Flip the `rustc-rayon`/`indexmap` dependency order
[`rustc-rayon v0.5.1`](https://github.com/rust-lang/rustc-rayon/pull/14) added `indexmap` implementations that will allow `indexmap` to drop its own "internal-only" implementations.
(This is separate from `indexmap`'s implementation for normal `rayon`.)
|
|
Arbitrary self types v2: explain test.
The purpose of this test wasn't obvious, as ```@traviscross``` noted. Add a comment.
Confession: although this test was added to demonstrate this particular corner-case, I can no longer reproduce the original problem, even if I adjust `rustc` to do the "wrong" thing. I have spent several hours trying to adjust the case to trigger the "faulty" behavior with no success. This test may therefore not be as useful as it originally was. But it still seems worthwhile retaining as a regression test that we don't break things in these quirky circumstances. Ideally we'd find a new test which tests this behavior but I've failed to come up with one.
r? ```@traviscross```
|
|
[Clippy] Add vec_reserve & vecdeque_reserve diagnostic items
I’m currently working on reviving this lint (https://github.com/rust-lang/rust-clippy/pull/10157), and there was [a comment](https://github.com/rust-lang/rust-clippy/pull/10157#discussion_r1091591057) from ``@flip1995`` regarding the necessity of adding new diagnostic items.
|
|
Pass spans to `perform_locally_in_new_solver`
Nothing changes yet, but we may be able to use these spans in the future once we start dealing w the response region constraints better.
r? lcnr
|
|
Implement MIR const trait stability checks
Addresses https://github.com/rust-lang/project-const-traits/issues/16
cc ``@rust-lang/project-const-traits``
r? ``@RalfJung``
|
|
-Znext-solver: "normalize" signature before checking it mentions self in `deduce_closure_signature`
Fixes rust-lang/trait-system-refactor-initiative#138
r? ``@lcnr``
Tbh I wrote so much comments I don't feel like writing it all again but as a description.
|
|
Make docs for AtomicUsize::from_mut platform-independent
fixes #133342
|
|
Rollup of 8 pull requests
Successful merges:
- #133151 (Trim extra whitespace in fn ptr suggestion span)
- #133829 (Implement `AtomicT::update` & `AtomicT::try_update`)
- #135367 (Enable `unreachable_pub` lint in `alloc`)
- #135748 (Lower index bounds checking to `PtrMetadata`, this time with the right fake borrow semantics 😸)
- #135805 (Add missing allocator safety in alloc crate)
- #135886 (Document purpose of closure in from_fn.rs more clearly)
- #135961 (Fix 2/4 tests skipped by opt-dist)
- #136012 (Document powf and powi values that are always 1.0)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Document powf and powi values that are always 1.0
fixes bug #90429
|
|
Fix 2/4 tests skipped by opt-dist
The linker errors were because this one test, strangely, wants itself compiled with `-Ctarget-features=+crt-static`, and yet it looks like the runner image is simply missing static libraries for libc and libm.
Eyeballing the output of
```
rustc +nightly --target=x86_64-pc-windows-msvc -O tests/codegen/vec-shrink-panik.rs --emit=llvm-ir
```
suggests that vec-shrink-panik should pass on Windows. And it's quite disturbing that such a test would have failed only on Windows to start with. Exactly why that was would require some advanced digging, but it looks clean now.
|
|
Document purpose of closure in from_fn.rs more clearly
partial fix for #135087 together with https://github.com/rust-lang/rust/pull/135895
|
|
Add missing allocator safety in alloc crate
### PR Description
In the previous PR [#135009](https://github.com/rust-lang/rust/pull/135009), PR [#134496](https://github.com/rust-lang/rust/pull/134496), some incomplete API documentation issues have been fixed.
Based on these changes, other inconsistencies related to the allocator have also been identified, including:
- `Box::from_non_null`
- `Box::from_non_null_in`
- `Weak::from_raw`
|
|
Lower index bounds checking to `PtrMetadata`, this time with the right fake borrow semantics 😸
Change `Rvalue::RawRef` to take a `RawRefKind` instead of just a `Mutability`. Then introduce `RawRefKind::FakeForPtrMetadata` and use that for lowering index bounds checking to a `PtrMetadata`. This new `RawRefKind::FakeForPtrMetadata` acts like a shallow fake borrow in borrowck, which mimics the semantics of the old `Rvalue::Len` operation we're replacing.
We can then use this `RawRefKind` instead of using a span desugaring hack in CTFE.
cc ``@scottmcm`` ``@RalfJung``
|
|
Enable `unreachable_pub` lint in `alloc`
This PR enables the [`unreachable_pub`](https://doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#unreachable-pub) lint as warn in the `alloc` crate.
Most of changes are in the btree implementation and in tests.
*The diff was mostly generated with `./x.py fix --stage 1 library/alloc/ -- --broken-code`, as well as manual edits for code in macros and in tests.*
Continuation of #134286 and #135366
r? libs
|
|
Implement `AtomicT::update` & `AtomicT::try_update`
ACP accepted in https://github.com/rust-lang/libs-team/issues/490
``@rustbot`` label +T-libs-api
|
|
Trim extra whitespace in fn ptr suggestion span
Trim extra whitespace when suggesting removal of invalid qualifiers when parsing function pointer type.
Fixes: #133083
---
I made a comment about the format of the diagnostic error message in https://github.com/rust-lang/rust/issues/133083#issuecomment-2480047875. I think the `.label` may be a little redundant if the diagnostic only highlights the bad qualifier instead of the entire `TyKind::BareFn` span. If it makes sense, I can include it in this PR.
|
|
platform-independent
|
|
Currently, the CI pipeline triggers `Lintcheck` for all PRs. However,
this check takes significant amount of time and seems unnecessary for
some certain directories that are frequently updated.
r? flip1995
changelog: none
|
|
|
|
|
|
Remove -Zinline-in-all-cgus and clean up tests/codegen-units/
Implementation of https://github.com/rust-lang/compiler-team/issues/814
I've taken some liberties with cleaning up the CGU partitioning tests, because that's the only place this flag was used and also mattered. I've often fought a lot with the contents of `tests/codegen-units` and it has never been clear to me when a test failure indicates a problem with my changes as opposed to a test just needing to be manually blessed. Hopefully the combination of the new README, new comments, and using `-Zprint-mono-items=lazy` in the partitioning tests improves that.
I've also deleted some of the `tests/run-make/sepcomp` tests. I think all the "sepcomp" tests have been obviated for years by better-designed (less flaky, clearer failures) test suites, but here I'm just deleting the ones I'm confident in.
|
|
Add a new lint `doc_overindented_list_items` to detect and fix list
items
in docs that are overindented.
For example,
```rs
/// - first line
/// second line
fn foo() {}
```
this would be fixed to:
```rs
/// - first line
/// second line
fn foo() {}
```
This lint improves readabiliy and consistency in doc.
---
- \[x] Followed [lint naming conventions][lint_naming]
- \[x] Added passing UI tests (including committed `.stderr` file)
- \[x] `cargo test` passes locally
- \[x] Executed `cargo dev update_lints`
- \[x] Added lint documentation
- \[x] Run `cargo dev fmt`
[lint_naming]:
https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints
changelog: [`doc_overindented_list_items`]: Added a new lint that
detects overindented list items in docs
fixes: #13601
|
|
|
|
Add a new lint `doc_overindented_list_items` to detect and fix list items
in docs that are overindented.
For example,
```rs
/// - first line
/// second line
fn foo() {}
```
this would be fixed to:
```rs
/// - first line
/// second line
fn foo() {}
```
This lint improves readabiliy and consistency in doc.
|
|
fix #14034
The currect implementation of `obfuscated_if_else` sometimes makes
incorrect suggestions when the original code have side effects (see the
example in the above issue). I think this can be fixed by changing the
applicability depending on whether it can have side effects or not.
changelog: [`obfuscated_if_else`]: change applicability when the
original code can have side effects
|
|
Windows x86: Change i128 to return via the vector ABI
Clang and GCC both return `i128` in xmm0 on windows-msvc and windows-gnu. Currently, Rust returns the type on the stack. Add a calling convention adjustment so we also return scalar `i128`s using the vector ABI, which makes our `i128` compatible with C.
In the future, Clang may change to return `i128` on the stack for its `-msvc` targets (more at [1]). If this happens, the change here will need to be adjusted to only affect MinGW.
Link: https://github.com/rust-lang/rust/issues/134288 (does not fix) [1]
try-job: x86_64-msvc
try-job: x86_64-msvc-ext1
try-job: x86_64-mingw-1
try-job: x86_64-mingw-2
|
|
|
|
|
|
|
|
|
|
|
|
r=davidtwco,RalfJung"
This reverts commit 122a55bb442bd1995df9cf9b36e6f65ed3ef4a1d.
|
|
|
