| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fix associated item removal suggestion
We were previously telling people to write what was already there, instead of removal (treating it as a `help`). We now properly suggest to remove the code that needs to be removed.
```
error[E0229]: associated item constraints are not allowed here
--> $DIR/E0229.rs:13:25
|
LL | fn baz<I>(x: &<I as Foo<A = Bar>>::A) {}
| ^^^^^^^ associated item constraint not allowed here
|
help: consider removing this associated item binding
|
LL - fn baz<I>(x: &<I as Foo<A = Bar>>::A) {}
LL + fn baz<I>(x: &<I as Foo>::A) {}
|
```
|
|
Migrate `atomic-lock-free` to `rmake`
Also adds `llvm_components_contain` to `run-make-support`.
Part of #121876.
r? ``@jieyouxu``
try-job: dist-x86_64-linux
|
|
Put the dots back in RTN pretty printing
Also don't render RTN-like bounds for methods with ty/const params.
|
|
compiler-errors:precise-capturing-better-sugg-apit, r=oli-obk
Fix precise capturing suggestion for hidden regions when we have APITs
Suggests to turn APITs into type parameters so they can be named in precise capturing syntax for hidden type lifetime errors. We also note that it may change the API.
This is currently done via a note *and* a suggestion, which feels a bit redundant, but I wasn't totally sure of a better alternative for the presentation.
Code is kind of a mess but there's a lot of cases to consider. Happy to iterate on this if you think the approach is too messy.
Based on #127619, only the last commit is relevant.
r? oli-obk
Tracking:
- https://github.com/rust-lang/rust/issues/123432
|
|
[`macro_metavar_expr_concat`] Add support for literals
Adds support for literals in macro parameters.
```rust
macro_rules! with_literal {
($literal:literal) => {
const ${concat(FOO, $literal)}: i32 = 1;
}
}
fn main() {
with_literal!("_BAR");
assert_eq!(FOO_BAR, 1);
}
```
cc #124225
r? ``@petrochenkov``
|
|
Rollup of 8 pull requests
Successful merges:
- #125042 (Use ordinal number in argument error)
- #127229 (rustdoc: click target for sidebar items flush left)
- #127337 (Move a few intrinsics to Rust abi)
- #127472 (MIR building: Stop using `unpack!` for `BlockAnd<()>`)
- #127579 (Solve a error `.clone()` suggestion when moving a mutable reference)
- #127769 (Don't use implicit features in `Cargo.toml` in `compiler/`)
- #127844 (Remove invalid further restricting suggestion for type bound)
- #127855 (Add myself to review rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
We were previously telling people to write what was already there, instead of removal.
```
error[E0229]: associated item constraints are not allowed here
--> $DIR/E0229.rs:13:25
|
LL | fn baz<I>(x: &<I as Foo<A = Bar>>::A) {}
| ^^^^^^^ associated item constraint not allowed here
|
help: consider removing this associated item binding
|
LL - fn baz<I>(x: &<I as Foo<A = Bar>>::A) {}
LL + fn baz<I>(x: &<I as Foo>::A) {}
|
```
|
|
|
|
|
|
|
|
|
|
Remove invalid further restricting suggestion for type bound
This PR partially addresses #127555, it will remove the obvious error suggestion:
```console
| ^^^^ required by this bound in `<Baz as Foo>::bar`
help: consider further restricting this bound
|
12 | F: FnMut() + Send + std::marker::Send,
| +++++++++++++++++++
```
I may create another PR to get a better diagnostic for `impl has stricter requirements than trait` scenario.
|
|
Solve a error `.clone()` suggestion when moving a mutable reference
If the moved value is a mut reference, it is used in a generic function and it's type is a generic param, suggest it can be reborrowed to avoid moving.
for example:
```rust
struct Y(u32);
// x's type is '& mut Y' and it is used in `fn generic<T>(x: T) {}`.
fn generic<T>(x: T) {}
```
fixes #127285
|
|
Move a few intrinsics to Rust abi
Move a few more intrinsic functions to the convention added in #121192. In the second commit, I added documentation about their safety requirements. Let me know if you would like me to move the second commit to a different PR.
Note: I kept the same signature of `pref_align_of`, but I was wondering why this function is considered unsafe?
|
|
rustdoc: click target for sidebar items flush left
This change adjusts the clickable area of sidebar links to touch the leftmost edge of the canvas, making them [much easier](https://www.nngroup.com/articles/fitts-law/) to click (when the browser window is maximized or tiled left, but those cases are common enough to matter).
[Screencast from 2024-07-15 15-31-07.webm](https://github.com/user-attachments/assets/1e952d3a-e9e7-476b-b211-44a17c190b38)
<details><summary>old screencast</summary>
[Screencast from 2024-07-01 17-23-34.webm](https://github.com/rust-lang/rust/assets/1593513/dc6f9c2e-5904-403d-b353-d233e6e1afbc)
</details>
|
|
Use ordinal number in argument error
Add an ordinal number to two argument errors ("unexpected" and "missing") for ease of understanding error.
```
error[E0061]: this function takes 3 arguments but 2 arguments were supplied
--> test.rs:11:5
|
11 | f(42, 'a');
| ^ --- 2nd argument of type `f32` is missing
|
(snip)
error[E0061]: this function takes 3 arguments but 4 arguments were supplied
--> test.rs:12:5
|
12 | f(42, 42, 1.0, 'a');
| ^ ----
| | |
| | unexpected 2nd argument of type `{integer}`
| help: remove the extra argument
```
To get an ordinal number, I copied `ordinalize` from other crate `rustc_resolve` because I think it is too much to link `rustc_resolve` for this small function. Please let me know if there is a better way.
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #125206 (Simplify environment variable examples)
- #126271 (Skip fast path for dec2flt when optimize_for_size)
- #126776 (Clean up more comments near use declarations)
- #127444 (`impl Send + Sync` and override `count` for the `CStr::bytes` iterator)
- #127512 (Terminate `--print link-args` output with newline)
- #127792 (std: Use `read_unaligned` for reads from DWARF)
- #127807 (Use futex.rs for Windows thread parking)
- #127833 (zkvm: add `#[forbid(unsafe_op_in_unsafe_fn)]` in `stdlib`)
- #127836 (std: Forbid unwrapped unsafe ops in xous and uefi modules)
Failed merges:
- #127813 (Prevent double reference in generic futex)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
it's type is a generic param, it can be reborrowed to avoid moving.
for example:
```rust
struct Y(u32);
// x's type is '& mut Y' and it is used in `fn generic<T>(x: T) {}`.
fn generic<T>(x: T) {}
```
fixes #127285
|
|
r=compiler-errors
Terminate `--print link-args` output with newline
Fixes #127507
|
|
Migrate `compiler-lookup-paths`, `dump-mono-stats` and `prune-link-args` `run-make` tests to `rmake` or `ui` format
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
try-job: x86_64-msvc
try-job: aarch64-apple
try-job: dist-x86_64-linux
try-job: armhf-gnu
|
|
Rollup of 7 pull requests
Successful merges:
- #124033 (Sync ar_archive_writer to LLVM 18.1.3)
- #126699 (Delegation: support coercion for target expression)
- #126762 (Deny keyword lifetimes pre-expansion)
- #126967 (Promote the `wasm32-wasip2` target to Tier 2)
- #127390 (Migrate `raw-dylib-inline-cross-dylib` and `raw-dylib-custom-dlltool` `run-make` tests to rmake)
- #127501 (Invert infer `error_reporting` mod struture)
- #127816 (Update method name to reflect changes to its internals)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=lcnr
Invert infer `error_reporting` mod struture
Parallel change to #127493, which moves `rustc_infer::infer::error_reporting` to `rustc_infer::error_reporting::infer`. After this, we should just be able to merge this into `rustc_trait_selection::error_reporting::infer`, and pull down `TypeErrCtxt` into that crate. 👍
r? lcnr
|
|
Migrate `raw-dylib-inline-cross-dylib` and `raw-dylib-custom-dlltool` `run-make` tests 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:
try-job: i686-mingw
|
|
Deny keyword lifetimes pre-expansion
https://github.com/rust-lang/rust/pull/126452#issuecomment-2179464266
> Secondly, we confirmed that we're OK with moving the validation of keywords in lifetimes to pre-expansion from post-expansion. We similarly consider this a bug fix. While the breakage of the convenience feature of the with_locals crate that relies on this is unfortunate, and we wish we had not overlooked this earlier for that reason, we're fortunate that the breakage is contained to only one crate, and we're going to accept this breakage as the extra complexity we'd need to carry in the compiler to work around this isn't deemed worth it.
T-lang considers it to be a bugfix to deny `'keyword` lifetimes in the parser, rather than during AST validation that only happens post-expansion. This has one breakage: https://github.com/rust-lang/rust/pull/126452#issuecomment-2171654756
This probably should get lang FCP'd just for consistency.
|
|
Delegation: support coercion for target expression
(solves https://github.com/rust-lang/rust/issues/118212#issuecomment-2160723092)
The implementation consist of 2 parts. Firstly, method call is generated instead of fully qualified call in AST->HIR lowering if there were no generic arguments or `Qpath` were provided. These restrictions are imposed due to the loss of information after desugaring. For example in
```rust
trait Trait {
fn foo(&self) {}
}
reuse <u8 as Trait>::foo;
```
We would like to generate such a code:
```rust
fn foo<u8: Trait>(x: &u8) {
x.foo(x)
}
```
however, the signature is inherited during HIR analysis where `u8` was discarded.
Then, we probe the single pre-resolved method.
P.S In the future, we would like to avoid restrictions on the callee path by `Self` autoref/autoderef in fully qualified calls, but at the moment it didn't work out.
r? `@petrochenkov`
|
|
|
|
|
|
|
|
|
|
|
|
Migrate `std-core-cycle`, `obey-crate-type-flag`, `mixing-libs` and `issue-18943` `run-make` tests to `rmake.rs`
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
try-job: x86_64-apple-1
try-job: x86_64-msvc
try-job: aarch64-gnu
|
|
|
|
|
|
|
|
|
|
Make sure trait def ids match before zipping args in `note_function_argument_obligation`
Fixes #126416
Fixes #127745
Didn't add both tests b/c I felt like it was unnecessary.
|
|
Suggest a borrow when using dbg
Fixes #120327
r? ````@estebank````
|
|
|
|
|
|
Suggest using `map_or` when `Option<&T>::unwrap_or where T: Deref` fails
Fix #127545
Split from https://github.com/rust-lang/rust/pull/127596#pullrequestreview-2171898588
|
|
note_function_argument_obligation
|
|
consolidate miri-unleashed tests for mutable refs into one file
r? ```@oli-obk```
|
|
Make parse error suggestions verbose and fix spans
Go over all structured parser suggestions and make them verbose style.
When suggesting to add or remove delimiters, turn them into multiple suggestion parts.
|
|
offset_from: always allow pointers to point to the same address
This PR implements the last remaining part of the t-opsem consensus in https://github.com/rust-lang/unsafe-code-guidelines/issues/472: always permits offset_from when both pointers have the same address, no matter how they are computed. This is required to achieve *provenance monotonicity*.
Tracking issue: https://github.com/rust-lang/rust/issues/117945
### What is provenance monotonicity and why does it matter?
Provenance monotonicity is the property that adding arbitrary provenance to any no-provenance pointer must never make the program UB. More specifically, in the program state, data in memory is stored as a sequence of [abstract bytes](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#abstract-byte), where each byte can optionally carry provenance. When a pointer is stored in memory, all of the bytes it is stored in carry that provenance. Provenance monotonicity means: if we take some byte that does not have provenance, and give it some arbitrary provenance, then that cannot change program behavior or introduce UB into a UB-free program.
We care about provenance monotonicity because we want to allow the optimizer to remove provenance-stripping operations. Removing a provenance-stripping operation effectively means the program after the optimization has provenance where the program before the optimization did not -- since the provenance removal does not happen in the optimized program. IOW, the compiler transformation added provenance to previously provenance-free bytes. This is exactly what provenance monotonicity lets us do.
We care about removing provenance-stripping operations because `*ptr = *ptr` is, in general, (likely) a provenance-stripping operation. Specifically, consider `ptr: *mut usize` (or any integer type), and imagine the data at `*ptr` is actually a pointer (i.e., we are type-punning between pointers and integers). Then `*ptr` on the right-hand side evaluates to the data in memory *without* any provenance (because [integers do not have provenance](https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html#integers-do-not-have-provenance)). Storing that back to `*ptr` means that the abstract bytes `ptr` points to are the same as before, except their provenance is now gone. This makes `*ptr = *ptr` a provenance-stripping operation (Here we assume `*ptr` is fully initialized. If it is not initialized, evaluating `*ptr` to a value is UB, so removing `*ptr = *ptr` is trivially correct.)
### What does `offset_from` have to do with provenance monotonicity?
With `ptr = without_provenance(N)`, `ptr.offset_from(ptr)` is always well-defined and returns 0. By provenance monotonicity, I can now add provenance to the two arguments of `offset_from` and it must still be well-defined. Crucially, I can add *different* provenance to the two arguments, and it must still be well-defined. In other words, this must always be allowed: `ptr1.with_addr(N).offset_from(ptr2.with_addr(N))` (and it returns 0). But the current spec for `offset_from` says that the two pointers must either both be derived from an integer or both be derived from the same allocation, which is not in general true for arbitrary `ptr1`, `ptr2`.
To obtain provenance monotonicity, this PR hence changes the spec for offset_from to say that if both pointers have the same address, the function is always well-defined.
### What further consequences does this have?
It means the compiler can no longer transform `end2 = begin.offset(end.offset_from(begin))` into `end2 = end`. However, it can still be transformed into `end2 = begin.with_addr(end.addr())`, which later parts of the backend (when provenance has been erased) can trivially turn into `end2 = end`.
The only alternative I am aware of is a fundamentally different handling of zero-sized accesses, where a "no provenance" pointer is not allowed to do zero-sized accesses and instead we have a special provenance that indicates "may be used for zero-sized accesses (and nothing else)". `offset` and `offset_from` would then always be UB on a "no provenance" pointer, and permit zero-sized offsets on a "zero-sized provenance" pointer. This achieves provenance monotonicity. That is, however, a breaking change as it contradicts what we landed in https://github.com/rust-lang/rust/pull/117329. It's also a whole bunch of extra UB, which doesn't seem worth it just to achieve that transformation.
### What about the backend?
LLVM currently doesn't have an intrinsic for pointer difference, so we anyway cast to integer and subtract there. That's never UB so it is compatible with any relaxation we may want to apply.
If LLVM gets a `ptrsub` in the future, then plausibly it will be consistent with `ptradd` and [consider two equal pointers to be inbounds](https://github.com/rust-lang/rust/pull/124921#issuecomment-2205795829).
|
|
|
