interpret: on a signed deref check, mention the right pointer in the error
When a negative offset (like `ptr.offset(-10)`) goes out-of-bounds, we currently show an error saying that we expect the *resulting* pointer to be inbounds for 10 bytes. That's confusing, so this PR makes it so that instead we say that we expect the *original* pointer `ptr` to have 10 bytes *to the left*.
I also realized I can simplify the pointer arithmetic logic and handling of "staying inbounds of a target `usize`" quite a bit; the second commit does that.
More unsafe attr verification
This code denies unsafe on attributes such as `#[test]` and `#[ignore]`, while also changing the `MetaItem` parsing so `unsafe` in args like `#[allow(unsafe(dead_code))]` is not accidentally allowed.
Tracking:
- https://github.com/rust-lang/rust/issues/123757
Finish blessing `coverage/mcdc` tests after LLVM 19 upgrade
Context: https://github.com/rust-lang/rust/pull/127513#issuecomment-2260887708
These changes aren't needed for Rust CI, because after the LLVM 19 upgrade we have no jobs that run these tests in `coverage-run` mode against LLVM 18. But they might help external builds.
The longer-term plan is to completely drop (unstable) MC/DC support on LLVM 18, as part of getting it working on LLVM 19 in #126733.
cc `@cuviper`
Emit an error if `#[optimize]` is applied to an incompatible item
#54882
The RFC specifies that this should emit a lint. I used the same allow logic as the `coverage` attribute (also allowing modules and impl blocks) - this should possibly be changed depending on if it's decided to allow 'propogation' of the attribute.
Migrate `symbol-visibility` `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).
Pretty scary!
- The expected number of symbols on each check has been changed slightly to reflect the differences between `llvm_readobj` and `nm`, as I think the former will print hidden symbols once and visible symbols twice, while the latter will only print visible symbols.
- The original test ran the same exact checks on `cdylib` twice, for seemingly no reason. I have removed it.
- This may be possible to optimize some more? `llvm_readobj` could get called only once for each library type, and the regex could avoid being created repeatedly. I am not sure if these kinds of considerations are important for a `run-make` test.
Demands a Windows try-job.
try-job: x86_64-mingw
Rollup of 7 pull requests
Successful merges:
- #123813 (Add `REDUNDANT_IMPORTS` lint for new redundant import detection)
- #126697 ([RFC] mbe: consider the `_` in 2024 an expression)
- #127159 (match lowering: Hide `Candidate` from outside the lowering algorithm)
- #128244 (Peel off explicit (or implicit) deref before suggesting clone on move error in borrowck, remove some hacks)
- #128431 (Add myself as VxWorks target maintainer for reference)
- #128438 (Add special-case for [T, 0] in dropck_outlives)
- #128457 (Fix docs for OnceLock::get_mut_or_init)
r? `@ghost`
`@rustbot` modify labels: rollup
derive(SmartPointer): require pointee to be maybe sized
cc ``@Darksonn``
So `#[pointee]` has to be `?Sized` in order for deriving `SmartPointer` to be meaningful.
cc ``@compiler-errors`` for suggestions in #127681
Properly mark loop as diverging if it has no breaks
Due to specifics about the desugaring of the `.await` operator, HIR typeck doesn't recognize that `.await`ing an `impl Future<Output = !>` will diverge in the same way as calling a `fn() -> !`.
This is because the await operator desugars to approximately:
```rust
loop {
match future.poll(...) {
Poll::Ready(x) => break x,
Poll::Pending => {}
}
}
```
We know that the value of `x` is `!`, however since `break` is a coercion site, we coerce `!` to some `?0` (the type of the loop expression). Then since the type of the `loop {...}` expression is `?0`, we will not detect the loop as diverging like we do with other expressions that evaluate to `!`:
0b5eb7ba7b/compiler/rustc_hir_typeck/src/expr.rs (L240-L243)
We can technically fix this in two ways:
1. Make coercion of loop exprs more eagerly result in a type of `!` when the only break expressions have type `!`.
2. Make loops understand that all of that if they have only diverging break values, then the loop diverges as well.
(1.) likely has negative effects on inference, and seems like a weird special case to drill into coercion. However, it turns out that (2.) is very easy to implement, we already record whether a loop has any break expressions, and when we do so, we actually skip over any break expressions with diverging values!:
0b5eb7ba7b/compiler/rustc_hir_typeck/src/expr.rs (L713-L716)
Thus, we can consider the loop as diverging if we see that it has no breaks, which is the change implemented in this PR.
This is not usually a problem in regular code for two reasons:
1. In regular code, we already mark `break diverging()` as unreachable if `diverging()` is unreachable. We don't do this for `.await`, since we suppress unreachable errors within `.await` (#64930). Un-suppressing this code will result in spurious unreachable expression errors pointing to internal await machinery.
3. In loops that truly have no breaks (e.g. `loop {}`), we already evaluate the type of the loop to `!`, so this special case is kinda moot. This only affects loops that have `break`s with values of type `!`.
Thus, this seems like a change that may affect more code than just `.await`, but it likely does not in meaningful ways; if it does, it's certainly correct to apply.
Fixes#128434
Peel off explicit (or implicit) deref before suggesting clone on move error in borrowck, remove some hacks
Also remove a heck of a lot of weird hacks in `suggest_cloning` that I don't think we should have around.
I know this regresses tests, but I don't believe most of these suggestions were accurate, b/c:
1. They either produced type errors (e.g. turning `&x` into `x.clone()`)
2. They don't fix the issue
3. They fix the issue ostensibly, but introduce logic errors (e.g. cloning a `&mut Option<T>` to then `Option::take` out...)
Most of the suggestions are still wrong, but they're not particularly *less* wrong IMO.
Stacked on top of #128241, which is an "obviously worth landing" subset of this PR.
r? estebank
match lowering: Hide `Candidate` from outside the lowering algorithm
The internals of `Candidate` are tricky and a source of confusion. This PR makes it so we don't expose `Candidate`s outside the lowering algorithm. Now:
- false edges are handled in `lower_match_tree`;
- `lower_match_tree` takes a list of patterns as input;
- `lower_match_tree` returns a flat datastructure that contains only the necessary information.
r? ```@matthewjasper```
Add `REDUNDANT_IMPORTS` lint for new redundant import detection
Defaults to Allow for now. Stacked on #123744 to avoid merge conflict, but much easier to review all as one.
r? petrochenkov
Accelerate GVN a little
This PR addresses a few inefficiencies I've seen in callgrind profiles.
Commits are independent.
Only the first commit introduces a change in behaviour: we stop substituting some constant pointers. But we keep propagating their contents that have no provenance, so we don't lose much.
r? `@saethlin`
Rollup of 9 pull requests
Successful merges:
- #126454 (bump-stage0: use IndexMap for determinism)
- #127681 (derive(SmartPointer): rewrite bounds in where and generic bounds)
- #127830 (When an archive fails to build, print the path)
- #128151 (Structured suggestion for `extern crate foo` when `foo` isn't resolved in import)
- #128387 (More detailed note to deprecate ONCE_INIT)
- #128388 (Match LLVM ABI in `extern "C"` functions for `f128` on Windows)
- #128402 (Attribute checking simplifications)
- #128412 (Remove `crate_level_only` from `ELIDED_LIFETIMES_IN_PATHS`)
- #128430 (Use a separate pattern type for `rustc_pattern_analysis` diagnostics )
r? `@ghost`
`@rustbot` modify labels: rollup
Remove `crate_level_only` from `ELIDED_LIFETIMES_IN_PATHS`
As far as I can tell, we provide the right node id to the `ELIDED_LIFETIMES_IN_PATHS` lint:
f8060d282d/compiler/rustc_resolve/src/late.rs (L2015-L2027)
So I've gone ahead and removed the restriction from this lint.
Match LLVM ABI in `extern "C"` functions for `f128` on Windows
As MSVC doesn't support `_Float128`, x86-64 Windows doesn't have a defined ABI for `f128`. Currently, Rust will pass and return `f128` indirectly for `extern "C"` functions. This is inconsistent with LLVM, which passes and returns `f128` in XMM registers, meaning that e.g. the ABI of `extern "C"` compiler builtins won't match. This PR fixes this discrepancy by making the x86-64 Windows `extern "C"` ABI pass `f128` directly through to LLVM, so that Rust will follow whatever LLVM does. This still leaves the difference between LLVM and GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054) but this PR is still an improvement as at least Rust is now consistent with it's primary codegen backend and compiler builtins from `compiler-builtins` will now work.
I've also fixed the x86-64 Windows `has_reliable_f16` match arm in `std` `build.rs` to refer to the correct target, and added an equivalent match arm to `has_reliable_f128` as the LLVM-GCC ABI difference affects both `f16` and `f128`.
Tracking issue: #116909
try-job: x86_64-msvc
try-job: x86_64-mingw
Structured suggestion for `extern crate foo` when `foo` isn't resolved in import
When encountering a name in an import that could have come from a crate that wasn't imported, use a structured suggestion to suggest `extern crate foo;` pointing at the right place in the crate.
When encountering `_` in an import, do not suggest `extern crate _;`.
```
error[E0432]: unresolved import `spam`
--> $DIR/import-from-missing-star-3.rs:2:9
|
LL | use spam::*;
| ^^^^ maybe a missing crate `spam`?
|
help: consider importing the `spam` crate
|
LL + extern crate spam;
|
```
derive(SmartPointer): rewrite bounds in where and generic bounds
Fix#127647
Due to the `Unsize` bounds, we need to commute the bounds on the pointee type to the new self type.
cc ```@Darksonn```
Update to LLVM 19
The LLVM 19.1.0 final release is planned for Sep 3rd. The rustc 1.82 stable release will be on Oct 17th.
The unstable MC/DC coverage support is temporarily broken by this update. It will be restored by https://github.com/rust-lang/rust/pull/126733. The implementation changed substantially in LLVM 19, and there are no plans to support both the LLVM 18 and LLVM 19 implementation at the same time.
Compatibility note for wasm:
> WebAssembly target support for the `multivalue` target feature has changed when upgrading to LLVM 19. Support for generating functions with multiple returns no longer works and `-Ctarget-feature=+multivalue` has a different meaning than it did in LLVM 18 and prior. The WebAssembly target features `multivalue` and `reference-types` are now both enabled by default, but generated code is not affected by default. These features being enabled are encoded in the `target_features` custom section and may affect downstream tooling such as `wasm-opt` consuming the module, but the actual generated WebAssembly will continue to not use either `multivalue` or `reference-types` by default. There is no longer any supported means to generate a module that has a function with multiple returns.
Related changes:
* https://github.com/rust-lang/rust/pull/127605
* https://github.com/rust-lang/rust/pull/127613
* https://github.com/rust-lang/rust/pull/127654
* https://github.com/rust-lang/rust/pull/128141
* https://github.com/llvm/llvm-project/pull/98933
Fixes https://github.com/rust-lang/rust/issues/121444.
Fixes https://github.com/rust-lang/rust/issues/128212.
Migrate `rlib-format-packed-bundled-libs-2`, `native-link-modifier-whole-archive` and `no-builtins-attribute` `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: x86_64-msvc
try-job: test-various
try-job: armhf-gnu
try-job: aarch64-apple
try-job: x86_64-gnu-llvm-18
This makes it possible for the `unsafe(...)` syntax to only be
valid at the top level, and the `NestedMetaItem`s will automatically
reject `unsafe(...)`.
Mark `Parser::eat`/`check` methods as `#[must_use]`
These methods return a `bool`, but we probably should either use these values or explicitly throw them away (e.g. when we just want to unconditionally eat a token if it exists).
I changed a few places from `eat` to `expect`, but otherwise I tried to leave a comment explaining why the `eat` was okay.
This also adds a test for the `pattern_type!` macro, which used to silently accept a missing `is` token.
Detect non-lifetime binder params shadowing item params
We should check that `for<T>` shadows `T` from an item in the same way that `for<'a>` shadows `'a` from an item.
r? ``@petrochenkov`` since you're familiar w the nuances of rib kinds
