| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Render pattern types nicely in mir dumps
avoid falling through to the fallback rendering that just does a hex dump
r? ``@scottmcm``
best reviewed commit by commit
|
|
Reject unsound toggling of Arm atomics-32 target feature
This target feature has the same semantics as RISC-V `forced-atomics` target feature that already marked as Forbidden (https://github.com/llvm/llvm-project/commit/f5ed0cb217a9988f97b55f2ccb053bca7b41cc0c) and toggling it can cause ABI incompatibility.
https://github.com/rust-lang/rust/blob/2f348cb7ce4063fa4eb40038e6ada3c5214717bd/compiler/rustc_target/src/target_features.rs#L479-L483
[Comment on feature definition in LLVM](https://github.com/llvm/llvm-project/blob/7109f521975e9cc2e8ba4f52ac2a8e1140bd49b5/llvm/lib/Target/ARM/ARMFeatures.td#L572-L574) also says:
> Code built with this feature is not ABI-compatible with code built without this feature, if atomic variables are exposed across the ABI boundary.
r? `@workingjubilee` or `@RalfJung`
`@rustbot` label +O-Arm
|
|
GCI: Don't try to eval / collect mono items inside overly generic free const items
Fixes #136156. Thanks for the pointers, errs!
There's one (preexisting) thing of note (maybe?). There's a difference between `const _: () = panic!();` and `const _<'a>: () = panic!();`: The former is a pre-mono error, the latter is a post-mono error. For comparison, both `fn _f() { const { panic!() } }` and `fn _f<'a: 'a>() { const { panic!() } }` are post-mono errors.
cc `@oli-obk`
r? compiler-errors or reassign
|
|
interpret: is_alloc_live: check global allocs last
See https://github.com/rust-lang/rust/pull/136105#discussion_r1930609553.
(A perf run makes no sense as this is only used by Miri.)
|
|
rustdoc: add nobuild typescript checking to our JS
By nobuild, I mean that the type annotations are all [in comments], not in the "native" typescript syntax. This is a bit uglier, but it lets you rapid-prototype without tsc, works with all the native browser debugging tools, and keeps Node out of Rust's bootstrap chain.
[in comments]: https://news.ycombinator.com/item?id=35892250
This pull request mostly just adds ts-ignore annotations and type declarations. To actually take good advantage of typescript, we'll want to "burn down" this pile of unsafe code until we eventually have a version with almost none of these.
This PR also adds tsc to the mingw-check Dockerfile, so that it can't fall out of date like the Closure annotations did.
https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/typescript
r? `@GuillaumeGomez` `@lolbinarycat`
|
|
Locate asan-odr-win with other sanitizer tests
|
|
Fix SIMD codegen tests on LLVM 20
The splat constants are printed differently on LLVM 20.
|
|
Deduplicate operand creation between scalars, non-scalars and string patterns
just something that felt duplicated and would make pattern type handling a bit more roundabout.
|
|
Revert #135914: Remove usages of `QueryNormalizer` in the compiler
Reverts #135914.
r? jackh726
|
|
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
|
|
|
|
|
