| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
```
error: value assigned to `object` is never read
--> $DIR/mut-arg-of-borrowed-type-meant-to-be-arg-of-mut-borrow.rs:11:5
|
LL | object = &object2;
| ^^^^^^
|
note: the lint level is defined here
--> $DIR/mut-arg-of-borrowed-type-meant-to-be-arg-of-mut-borrow.rs:1:9
|
LL | #![deny(unused_assignments, unused_variables)]
| ^^^^^^^^^^^^^^^^^^
help: you might have meant to mutate the pointed at value being passed in, instead of changing the reference in the local binding
|
LL ~ fn change_object2(object: &mut Object) {
LL | let object2 = Object;
LL ~ *object = object2;
|
```
This might be the first thing someone tries to write to mutate the value *behind* an argument, trying to avoid an E0308.
|
|
```
error[E0308]: mismatched types
--> $DIR/mut-arg-of-borrowed-type-meant-to-be-arg-of-mut-borrow.rs:6:14
|
LL | fn change_object(mut object: &Object) {
| ------- expected due to this parameter type
LL | let object2 = Object;
LL | object = object2;
| ^^^^^^^ expected `&Object`, found `Object`
|
help: you might have meant to mutate the pointed at value being passed in, instead of changing the reference in the local binding
|
LL ~ fn change_object(object: &mut Object) {
LL | let object2 = Object;
LL ~ *object = object2;
|
```
This might be the first thing someone tries to write to mutate the value *behind* an argument. We avoid suggesting `object = &object2;`, as that is less likely to be what was intended.
|
|
This is a mistake I've seen newcomers make where they want to express an "out" argument.
|
|
alloc: remove unsound `IsZero` for raw pointers
Fixes #135338
|
|
mir_transform: implement `#[rustc_force_inline]`
Adds `#[rustc_force_inline]` which is similar to always inlining but reports an error if the inlining was not possible.
- `#[rustc_force_inline]` can only be applied to free functions to guarantee that the MIR inliner will be able to resolve calls.
- `rustc_mir_transform::inline::Inline` is refactored into two passes (`Inline` and `ForceInline`), sharing the vast majority of the implementation.
- `rustc_mir_transform::inline::ForceInline` can't be disabled so annotated items are always inlined.
- `rustc_mir_transform::inline::ForceInline` runs regardless of optimisation level.
- `#[rustc_force_inline]` won't inline unless target features match, as with normal inlining.
- MIR validation will ICE if a `#[rustc_force_inline]` isn't inlined, to guarantee that it will never be codegened independently. As a further guarantee, monomorphisation collection will always decide that `#[rustc_force_inline]` functions cannot be codegened locally.
- Like other intrinsics, `#[rustc_force_inline]` annotated functions cannot be cast to function pointers.
- As with other rustc attrs, this cannot be used by users, just within the compiler and standard library.
- This is only implemented within rustc, so should avoid any limitations of LLVM's inlining.
It is intended that this attribute be used with intrinsics that must be inlined for security reasons. For example, pointer authentication intrinsics would allow Rust users to make use of pointer authentication instructions, but if these intrinsic functions were in the binary then they could be used as gadgets with ROP attacks, defeating the point of introducing them. We don't have any intrinsics like this today, but I expect to upstream some once a force inlining mechanism such as this is available.
cc rust-lang/rust#131687 rust-lang/rfcs#3711 - this approach should resolve the concerns from these previous attempts
r? `@saethlin`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Adds `#[rustc_force_inline]` which is similar to always inlining but
reports an error if the inlining was not possible, and which always
attempts to inline annotated items, regardless of optimisation levels.
It can only be applied to free functions to guarantee that the MIR
inliner will be able to resolve calls.
|
|
Fixes #135338
|
|
Subtree sync for rustc_codegen_cranelift
This has a couple of changes that will conflict with https://github.com/rust-lang/rust/pull/134338.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
|
|
Rollup of 7 pull requests
Successful merges:
- #132607 (Used pthread name functions returning result for FreeBSD and DragonFly)
- #134693 (proc_macro: Use `ToTokens` trait in `quote` macro)
- #134732 (Unify conditional-const error reporting with non-const error reporting)
- #135083 (Do not ICE when encountering predicates from other items in method error reporting)
- #135251 (Only treat plain literal patterns as short)
- #135320 (Fix typo in `#[coroutine]` gating error)
- #135321 (remove more redundant into() conversions)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
sync_cg_clif-2025-01-10
|
|
|
|
remove more redundant into() conversions
|
|
Fix typo in `#[coroutine]` gating error
|
|
Only treat plain literal patterns as short
See https://github.com/rust-lang/rust/pull/134228#discussion_r1905848384 and https://github.com/rust-lang/rust/pull/134228#discussion_r1905916702 for context. We never wanted to treat const blocks and paths as short, only plain literals.
I don't know how to write a test for this, it.s not clear to me how the short pattern check actually affects the formatting
|
|
Do not ICE when encountering predicates from other items in method error reporting
See the comments I left in the code and the test file.
Fixes https://github.com/rust-lang/rust/issues/124350
|
|
compiler-errors:unify-conditional-const-error-reporting, r=RalfJung
Unify conditional-const error reporting with non-const error reporting
This PR unifies the error reporting between `ConditionallyConstCall` and `FnCallNonConst` so that the former will refer to syntactical sugar like operators by their sugared name, rather than calling all operators "methods". We achieve this by making the "non-const" part of the error message generic over the "non" part so we can plug in "conditionally" instead.
This should ensure that as we constify traits in the standard library, we don't regress error messages for things like `==`.
r? fmease or reassign
|
|
r=tgross35
proc_macro: Use `ToTokens` trait in `quote` macro
Tracking issues: #130977, #54722
This PR changed `proc_macro::quote!` to use `ToTokens` trait instead of `TokenStream::from`, and migrated test cases from `quote` crate.
r? `@dtolnay`
CC `@tgross35`
|
|
Used pthread name functions returning result for FreeBSD and DragonFly
`pthread_getname_np` and `pthread_setname_np` received a wider adoption in past years and was added to:
* FreeBSD by June 11 2020 via [`2ef84b7da9a6c3e23b4a135e6e863581f16d46e1`](https://github.com/freebsd/freebsd-src/commit/2ef84b7da9a6c3e23b4a135e6e863581f16d46e1),
* DargonFly by March 8 2021 via [`ab5dc9aceb34419d1c4b6006739e61acee8ee999`](https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/ab5dc9aceb34419d1c4b6006739e61acee8ee999).
There's not so much advantage except that the result can be checked in debug builds. Ideally it should be unified with Linux' implementation, but it trims the input.
|
|
Remove special-casing for argument patterns in MIR typeck (attempt to fix perf regression of #133858)
See [my comment](https://github.com/rust-lang/rust/pull/133858#issuecomment-2579029618) on #133858 for more information. This is just a guess as to what went wrong, and I haven't been able to get the profiler running locally, so I'll need a perf run to make sure this actually helps.
There's one test's stderr that suffers a bit, but this was just papering over the issue anyway. Making region errors point to the correct constraints in the presence of invariance/contravariance is a broader problem; the current way it's handled is mostly based on guesswork, luck, and hoping it works out. Properly handling that (somehow) would improve the test's stderr without the hack that this PR reverts.
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #133088 (`-Zrandomize-layout` harder. `Foo<T> != Foo<U>`)
- #134619 (Improve prose around `as_slice` example of IterMut)
- #134855 (Add `default_field_values` entry to unstable book)
- #134908 (Fix `ptr::from_ref` documentation example comment)
- #135275 (Add Pin::as_deref_mut to 1.84 relnotes)
- #135294 (Make `bare-fn-no-impl-fn-ptr-99875` test less dependent on path width)
- #135304 (Add tests cases from review of #132289)
- #135308 (Make sure to walk into nested const blocks in `RegionResolutionVisitor`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Make sure to walk into nested const blocks in `RegionResolutionVisitor`
Fixes https://github.com/rust-lang/rust/issues/135306
I tried auditing the rest of the visitors that called `.visit_body`, and it seems like this is the only one that was missing it. I wonder if we should modify intravisit (specifcially, that `NestedBodyFilter` stuff) to make this less likely to happen, tho...
r? oli-obk
|
|
Add tests cases from review of #132289
Adding my comments as test-cases as suggested by ``@jackh726`` in https://github.com/rust-lang/rust/pull/132289#issuecomment-2564602267
|
|
Make `bare-fn-no-impl-fn-ptr-99875` test less dependent on path width
This sets diagnostic-width to some arbitrary number. Seems to work on my machine.
|
|
Add Pin::as_deref_mut to 1.84 relnotes
Resolves #131243 - I think this got missed in the relnotes sweep or something.
``@rustbot`` label relnotes
|
|
Fix `ptr::from_ref` documentation example comment
The comment says that the expression involves no function call, but that was only true for the example above, the example here _does_ contain a function call.
``@rustbot`` label A-docs
|
|
r=jieyouxu
Add `default_field_values` entry to unstable book
Tracking issue: https://github.com/rust-lang/rust/issues/132162
RFC: https://github.com/rust-lang/rfcs/blob/master/text/3681-default-field-values.md
|
|
Improve prose around `as_slice` example of IterMut
I've removed the cryptic message about not being able to call `&mut self` methods while retaining a shared borrow of the iterator, such as `as_slice` produces. This is just normal borrowing rules and does not seem especially relevant here. I can whip up a replacement if someone thinks it has value.
|
|
`-Zrandomize-layout` harder. `Foo<T> != Foo<U>`
Tracking issue: #106764
Previously randomize-layout only used a deterministic shuffle based on the seed stored in an Adt's ReprOptions, meaning that `Foo<T>` and `Foo<U>` were shuffled by the same seed. This change adds a similar seed to each calculated LayoutData so that a struct can be randomized both based on the layout of its fields and its per-type seed.
Primitives start with simple seed derived from some of their properties. Though some types can no longer be distinguished at that point, e.g. usize and u64 will still be treated the same.
|
|
Clippy subtree update
r? `@Manishearth`
|
|
|
|
|
|
|
|
|
|
previously field ordering was using the same seed for all instances of Foo,
now we pass seed values through the layout tree so that not only
the struct itself affects layout but also its fields
|
|
CI: fix name of jobs
There is a difference between the `image` (the Dockerfile), the `name` of the job (which determines also its properties) and the `full_name`, which includes the `auto/try/pr` prefix.
Missed this in https://github.com/rust-lang/rust/pull/134898.
|
|
|
|
|
