| Age | Commit message (Collapse) | Author | Lines |
|---|
|
it now checks zlib and zstd, via rustc and rust-lld
|
|
|
|
also make it fail if there's a compression issue
|
|
Rollup of 9 pull requests
Successful merges:
- #128596 (stabilize const_fn_floating_point_arithmetic)
- #129199 (make writes_through_immutable_pointer a hard error)
- #129246 (Retroactively feature gate `ConstArgKind::Path`)
- #129290 (Pin `cc` to 1.0.105)
- #129323 (Implement `ptr::fn_addr_eq`)
- #129500 (remove invalid `TyCompat` relation for effects)
- #129501 (panicking: improve hint for Miri's RUST_BACKTRACE behavior)
- #129505 (interpret: ImmTy: tighten sanity checks in offset logic)
- #129510 (Fix `elided_named_lifetimes` in code)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rustdoc: show exact case-sensitive matches first
fixes #119480
|
|
Print the generic parameter along with the variance in dumps.
This allows to make sure we are testing what we think we are testing.
While the tests are correct, I discovered that opaque duplicated args are in the reverse declaration order.
|
|
Add a special case for `CStr`/`CString` in the `improper_ctypes` lint
Revives #120176. Just needed to bless a test and fix an argument, but seemed reasonable to me otherwise.
Instead of saying to "consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct", we now tell users to "Use `*const ffi::c_char` instead, and pass the value from `CStr::as_ptr()`" when the type involved is a `CStr` or a `CString`.
The suggestion is not made for `&mut CString` or `*mut CString`.
r? ``````@cjgillot`````` (since you were the reviewer of the original PR #120176, but feel free to reroll)
|
|
chenyukang:yukang-fix-127930-invalid-outer-style-sugg, r=cjgillot
Don't suggest turning crate-level attributes into outer style
Fixes #127930
|
|
Detect `*` operator on `!Sized` expression
The suggestion is new:
```
error[E0277]: the size for values of type `str` cannot be known at compilation time
--> $DIR/unsized-str-in-return-expr-arg-and-local.rs:15:9
|
LL | let x = *"";
| ^ doesn't have a size known at compile-time
|
= help: the trait `Sized` is not implemented for `str`
= note: all local variables must have a statically known size
= help: unsized locals are gated as an unstable feature
help: references to `!Sized` types like `&str` are `Sized`; consider not dereferencing the expression
|
LL - let x = *"";
LL + let x = "";
|
```
Fix #128199.
|
|
remove invalid `TyCompat` relation for effects
if the current impl uses `Maybe` (`impl const`), the parent impl must use `Maybe` (`impl const`) as well.
I'd like to rename `TyCompat` to `Sub` which is probably clearer. But it would conflict with my other PR.
r? ``@rust-lang/project-const-traits``
|
|
Retroactively feature gate `ConstArgKind::Path`
This puts the lowering introduced by #125915 under a feature gate until we fix the regressions introduced by it. Alternative to whole sale reverting the PR since it didn't seem like a very clean revert and I think this is generally a step in the right direction and don't want to get stuck landing and reverting the PR over and over :)
cc #129137 ``@camelid,`` tests taken from there. beta is branching soon so I think it makes sense to not try and rush that fix through since it wont have much time to bake and if it has issues we can't simply revert it on beta.
Fixes #128016
|
|
r=compiler-errors
make writes_through_immutable_pointer a hard error
This turns the lint added in https://github.com/rust-lang/rust/pull/118324 into a hard error. This has been reported in cargo's future-compat reports since Rust 1.76 (released in February). Given that const_mut_refs is still unstable, it should be impossible to even hit this error on stable: we did accidentally stabilize some functions that can cause this error, but that got reverted in https://github.com/rust-lang/rust/pull/117905. Still, let's do a crater run just to be sure.
Given that this should only affect unstable code, I don't think it needs an FCP, but let's Cc ``@rust-lang/lang`` anyway -- any objection to making this unambiguous UB into a hard error during const-eval? This can be viewed as part of https://github.com/rust-lang/rust/pull/129195 which is already nominated for discussion.
|
|
r=nnethercote
stabilize const_fn_floating_point_arithmetic
Part of https://github.com/rust-lang/rust/issues/128288
Fixes https://github.com/rust-lang/rust/issues/57241
The existing test `tests/ui/consts/const_let_eq_float.rs` ([link](https://github.com/RalfJung/rust/blob/const_fn_floating_point_arithmetic/tests/ui/consts/const_let_eq_float.rs)) covers the basics, and also Miri has extensive tests covering the interpreter's float machinery. Also, that machinery can already be used on stable inside `const`/`static` initializers, just not inside `const fn`.
This was explicitly called out in https://github.com/rust-lang/rfcs/pull/3514 so in a sense t-lang just recently already FCP'd this, but let's hear from them whether they want another FCP for the stabilization here or whether that was covered by the FCP for the RFC.
Cc ``@rust-lang/lang``
### Open items
- [x] Update the Reference: https://github.com/rust-lang/reference/pull/1566
|
|
|
|
|
|
Migrate `libtest-thread-limit` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Please try, but **only if normal CI is green**:
// try-job: armhf-gnu // <- failed on this
try-job: aarch64-gnu
|
|
fixes #119480
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #128511 (Document WebAssembly target feature expectations)
- #129243 (do not build `cargo-miri` by default on stable channel)
- #129263 (Add a missing compatibility note in the 1.80.0 release notes)
- #129276 (Stabilize feature `char_indices_offset`)
- #129350 (adapt integer comparison tests for LLVM 20 IR changes)
- #129408 (Fix handling of macro arguments within the `dropping_copy_types` lint)
- #129426 (rustdoc-search: use tighter json for names and parents)
- #129437 (Fix typo in a help diagnostic)
- #129457 (kobzol vacation)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix typo in a help diagnostic
Replaced "**the your** dependency graph" with "**in the** dependency graph".
|
|
Fix handling of macro arguments within the `dropping_copy_types` lint
This PR fixes the handling of spans with different context (aka macro arguments) than the primary expression within the different `{drop,forget}ing_copy_types` and `{drop,forget}ing_references` lints.
<details>
<summary>Before</summary>
```
warning: calls to `std::mem::drop` with a value that implements `Copy` does nothing
--> drop_writeln.rs:5:5
|
5 | drop(writeln!(&mut msg, "test"));
| ^^^^^--------------------------^
| |
| argument has type `Result<(), std::fmt::Error>`
|
= note: `#[warn(dropping_copy_types)]` on by default
help: use `let _ = ...` to ignore the expression or result
--> /home/[..]/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/macros/mod.rs:688:9
|
68| let _ =
| ~~~~~~~
```
</details>
<details>
<summary>With this PR</summary>
```
warning: calls to `std::mem::drop` with a value that implements `Copy` does nothing
--> drop_writeln.rs:5:5
|
5 | drop(writeln!(&mut msg, "test"));
| ^^^^^--------------------------^
| |
| argument has type `Result<(), std::fmt::Error>`
|
= note: `#[warn(dropping_copy_types)]` on by default
help: use `let _ = ...` to ignore the expression or result
|
5 - drop(writeln!(&mut msg, "test"));
5 + let _ = writeln!(&mut msg, "test");
|
```
</details>
``````@rustbot`````` label +L-dropping_copy_types
|
|
adapt integer comparison tests for LLVM 20 IR changes
The LLVM commit https://github.com/llvm/llvm-project/commit/abf69a167bbc99054871e3f9cc8810bbebcb6747 changed the IR in a few comparison tests:
https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/30500#01917017-26fe-4a4d-956b-725a2903e5a8
Adapted accordingly.
````@rustbot```` label: +llvm-main
r? ````@nikic````
|
|
Don't trigger refinement lint if predicates reference errors
Fixes #129404
|
|
Fix extern crates not being hidden with `doc(hidden)`
Fixes #126796.
Only the current crate should never be stripped, any other crate should be strippable.
r? ``@notriddle``
|
|
Migrate `x86_64-fortanix-unknown-sgx-lvi` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
The final Makefile! Every Makefile test is now claimed.
This is difficult to test due to the uncommon architecture it is specific to. I don't think it is in the CI (I didn't find it in `jobs.yml`, but if there is a way to test it, please do.
Locally, on Linux, it compiles and panics at the `llvm_filecheck` part (if I replace the `x86_64-fortanix-unknown-sgx` with `x86_64-unknown-linux-gnu`, of course), which is expected.
For this reason, the Makefile and associated script have been kept, but with a leading underscore.
|
|
fix: fs::remove_dir_all: treat internal ENOENT as success
fixes #127576
try-job: test-various
|
|
|
|
|
|
fixes #127576
windows implementation still needs some work
|
|
|
|
Allow rust staticlib to work with MSVC's /WHOLEARCHIVE
This fixes #129020 by renaming the `__NULL_IMPORT_DESCRIPTOR` to prevent conflicts.
try-job: dist-i686-msvc
|
|
|
|
The LLVM commit https://github.com/llvm/llvm-project/commit/abf69a167bbc99054871e3f9cc8810bbebcb6747
changed the IR in a few comparison tests:
https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/30500#01917017-26fe-4a4d-956b-725a2903e5a8
Adapted accordingly.
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #128432 (WASI: forbid `unsafe_op_in_unsafe_fn` for `std::{os, sys}`)
- #129373 (Add missing module flags for CFI and KCFI sanitizers)
- #129374 (Use `assert_unsafe_precondition!` in `AsciiChar::digit_unchecked`)
- #129376 (Change `assert_unsafe_precondition` docs to refer to `check_language_ub`)
- #129382 (Add `const_cell_into_inner` to `OnceCell`)
- #129387 (Advise against removing the remaining Python scripts from `tests/run-make`)
- #129388 (Do not rely on names to find lifetimes.)
- #129395 (Pretty-print own args of existential projections (dyn-Trait w/ GAT constraints))
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Pretty-print own args of existential projections (dyn-Trait w/ GAT constraints)
Previously we would just drop them. This bug isn't that significant as it can only be triggered by user code that constrains GATs inside trait object types which is currently gated under the interim feature `generic_associated_types_extended` (whose future is questionable) or on stable if the GATs are 'disabled' in dyn-Trait via `where Self: Sized` (in which case the assoc type bindings get ignored anyway (and trigger the warn-by-default lint `unused_associated_type_bounds`)), so yeah.
Affects diagnostic output and output of `std::any::type_name{_of_val}`.
|
|
Do not rely on names to find lifetimes.
For some reason, we were trying to find the lifetime parameter from its name, instead of using the def_id we have.
This PR uses it instead. This changes some ui tests, I think to be more sensible.
|
|
Advise against removing the remaining Python scripts from `tests/run-make`
After some recent PRs (e.g. #129185), there are only two Python scripts left in `tests/run-make`.
Having come so far, it's tempting to try to get rid of the remaining ones. But after trying that myself, I've come to the conclusion that it's not worth the extra hassle, especially if it means pulling in an XML-parsing crate just for one test.
This PR therefore leaves behind a few signpost comments to explain why getting rid of these particular scripts has low value.
|
|
Add missing module flags for CFI and KCFI sanitizers
Set the cfi-normalize-integers and kcfi-offset module flags when Control-Flow Integrity sanitizers are used, so functions generated by the LLVM backend use the same CFI/KCFI options as rustc.
cfi-normalize-integers tells LLVM to also use integer normalization for generated functions when -Zsanitizer-cfi-normalize-integers is used.
kcfi-offset specifies the number of prefix nops between the KCFI type hash and the function entry when -Z patchable-function-entry is used. Note that LLVM assumes all indirectly callable functions use the same number of prefix NOPs with -Zsanitizer=kcfi.
|
|
Rollup of 9 pull requests
Successful merges:
- #127279 (use old ctx if has same expand environment during decode span)
- #127945 (Implement `debug_more_non_exhaustive`)
- #128941 ( Improve diagnostic-related lints: `untranslatable_diagnostic` & `diagnostic_outside_of_impl`)
- #129070 (Point at explicit `'static` obligations on a trait)
- #129187 (bootstrap: fix clean's remove_dir_all implementation)
- #129231 (improve submodule updates)
- #129264 (Update `library/Cargo.toml` in weekly job)
- #129284 (rustdoc: animate the `:target` highlight)
- #129302 (compiletest: use `std::fs::remove_dir_all` now that it is available)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Trying to get rid of this Python script looks tempting, because it's currently
the only Python script in the whole `run-make` suite that we actually run.
But getting rid of it would require pulling in a Rust crate to parse XML
instead, and that's probably not worth the extra hassle for a relatively-minor
test.
|
|
This makes it easier for maintainers to see what the Python script is for.
|
|
|
|
Set the cfi-normalize-integers and kcfi-offset module flags when
Control-Flow Integrity sanitizers are used, so functions generated by
the LLVM backend use the same CFI/KCFI options as rustc.
cfi-normalize-integers tells LLVM to also use integer normalization
for generated functions when -Zsanitizer-cfi-normalize-integers is
used.
kcfi-offset specifies the number of prefix nops between the KCFI
type hash and the function entry when -Z patchable-function-entry is
used. Note that LLVM assumes all indirectly callable functions use the
same number of prefix NOPs with -Zsanitizer=kcfi.
|
|
safe transmute: gracefully bubble-up layout errors
Changes `.unwrap()`s to `?` to avoid ICEs. Adds ui tests.
Fixes #129327
Tracking Issue: https://github.com/rust-lang/rust/issues/99571
r? `@compiler-errors`
|
|
bump conflicting_repr_hints lint to be shown in dependencies
This has been a future compatibility lint for years, let's bump it up to be shown in dependencies (so that hopefully we can then make it a hard error fairly soon).
Cc https://github.com/rust-lang/rust/issues/68585
|
|
Changes `.unwrap()`s to `?` to avoid ICEs. Adds ui tests.
Fixes #129327
|
