Detect multiple crate versions on method not found
When a type comes indirectly from one crate version but the imported trait comes from a separate crate version, the called method won't be found. We now show additional context:
```
error[E0599]: no method named `foo` found for struct `dep_2_reexport::Type` in the current scope
--> multiple-dep-versions.rs:8:10
|
8 | Type.foo();
| ^^^ method not found in `Type`
|
note: there are multiple different versions of crate `dependency` in the dependency graph
--> multiple-dep-versions.rs:4:32
|
4 | use dependency::{do_something, Trait};
| ^^^^^ `dependency` imported here doesn't correspond to the right crate version
|
::: ~/rust/build/x86_64-unknown-linux-gnu/test/run-make/crate-loading/rmake_out/multiple-dep-versions-1.rs:4:1
|
4 | pub trait Trait {
| --------------- this is the trait that was imported
|
::: ~/rust/build/x86_64-unknown-linux-gnu/test/run-make/crate-loading/rmake_out/multiple-dep-versions-2.rs:4:1
|
4 | pub trait Trait {
| --------------- this is the trait that is needed
5 | fn foo(&self);
| --- the method is available for `dep_2_reexport::Type` here
```
Fix#128569, fix#110926, fix#109161, fix#81659, fix#51458, fix#32611. Follow up to #124944.
CloneToUninit impls
As per #126799.
Also implements it for `Wtf8` and both versions of `os_str::Slice`.
Maybe it is worth to slap `#[inline]` on some of those impls.
r? `@dtolnay`
float to/from bits and classify: update for float semantics RFC
With https://github.com/rust-lang/rfcs/pull/3514 having been accepted, it is clear that hardware which e.g. flushes subnormal to zero is just non-conformant from a Rust perspective -- this is a hardware bug, or maybe an LLVM backend bug (where LLVM doesn't lower floating-point ops in a way that they have the standardized behavior). So update the comments here to make it clear that we don't have to do any of this, we're just being nice.
Also remove the subnormal/NaN checks from the (unstable) const-version of to/from-bits; they are not needed since we decided with the aforementioned RFC that it is okay to get a different result at const-time and at run-time.
r? `@workingjubilee` since I think you wrote many of the comments I am editing here.
Fix wrong source location for some incorrect macro definitions
Fixes#95463
Currently the code will consume the next token tree after `var` when trying to parse `$var:some_type` even when it's not a `:` (e.g. a `$` when input is `($foo $bar:tt) => {}`). Additionally it will return the wrong span when it's not a `:`.
This PR fixes these problems.
Migrate `validate_json.py` script to rust in `run-make/rustdoc-map-file` test
This PR fixes the FIXME I added for future-me who become present-me. :')
Since there are multiple `run-make` tests using python scripts, I suppose more of them will migrate to Rust, hence why I added the `jzon` public reexport to the `run-make-support` crate.
cc `@jieyouxu`
r? `@Kobzol`
Special-case alias ty during the delayed bug emission in `try_from_lit`
This PR tries to fix#116308.
A delayed bug in `try_from_lit` will not be emitted so that the compiler will not ICE when it sees the pair `(ast::LitKind::Int, ty::TyKind::Alias)` in `lit_to_const` (called from `try_from_lit`).
This PR is related to an unstable feature `adt_const_params` (#95174).
r? ``@BoxyUwU``
detect incompatible CI rustc options more precisely
Previously, the logic here was simply checking whether the option was set in `config.toml`. This approach was not manageable in our CI runners as we set so many options in config.toml. In reality, those values are not incompatible since they are usually the same value used to generate the CI rustc. Now, the new logic compares the configuration values with the values used to generate the CI rustc, so we get more precise results and make the process more manageable.
r? Kobzol
Blocker for https://github.com/rust-lang/rust/pull/122709
Enable debuginfo tests that have been "temporarily disabled" for the past 6 years
The PR history is a bit of a mess because I had to test this a lot with try-jobs, so I'll try to summarize the non-obvious changes here.
A number of tests now have `min-lldb-version: 1800`. Those tests should have gotten an lldb version jump either in https://github.com/rust-lang/rust/pull/124781 or long ago. Note that all such tests with that lldb version requirement do not run in Apple CI.
`tests/debuginfo/drop-locations.rs` is staying disabled for now because gdb doesn't know to stop on the drop calls produced by a `}`: https://github.com/rust-lang/rust/issues/128971
`tests/debuginfo/function-arg-initialization.rs` now has `-Zmir-enable-passes=-SingleUseConsts`; without that we initialize the const before the function prelude: https://github.com/rust-lang/rust/issues/128945
`tests/debuginfo/by-value-non-immediate-argument.rs` fails because we don't generate a function prelude for unused non-immediate arguments, even with all optimizations disabled, and this seems to confuse debuggers on aarch64: https://github.com/rust-lang/rust/issues/128973
`tests/debuginfo/pretty-std.rs` is staying disabled on windows-gnu because our test harness doesn't know how to load our pretty-printers on that target: https://github.com/rust-lang/rust/issues/128981
`tests/debuginfo/method-on-enum.rs` and `tests/debuginfo/option-like-enum.rs` encounter some kind of gdb bug on i686-pc-windows-gnu. I don't know enough about that situation to write a good issue.
I plan on doing more work on this test suite. There's clearly a lot more basic cleanup work to do here.
Rollup of 9 pull requests
Successful merges:
- #128064 (Improve docs for Waker::noop and LocalWaker::noop)
- #128922 (rust-analyzer: use in-tree `pattern_analysis` crate)
- #128965 (Remove `print::Pat` from the printing of `WitnessPat`)
- #129018 (Migrate `rlib-format-packed-bundled-libs` and `native-link-modifier-bundle` `run-make` tests to rmake)
- #129037 (Port `run-make/libtest-json` and `run-make/libtest-junit` to rmake)
- #129078 (`ParamEnvAnd::fully_perform`: we have an `ocx`, use it)
- #129110 (Add a comment explaining the return type of `Ty::kind`.)
- #129111 (Port the `sysroot-crates-are-unstable` Python script to rmake)
- #129135 (crashes: more tests)
r? `@ghost`
`@rustbot` modify labels: rollup
Port the `sysroot-crates-are-unstable` Python script to rmake
New version of #126231, and a follow-up to #129071.
One major difference is that the new version no longer tries to report *all* accidentally-stable crates, because the `run_make_support` helpers tend to halt the test as soon as something goes wrong. That's unfortunate, but I think it won't matter much in practice, and preserving the old behaviour doesn't seem worth the extra effort.
---
Part of #110479 (Python purge), with this being one of the non-trivial Python scripts that actually seems feasible and worthwhile to remove.
This is *not* part of #121876 (Makefile purge), because the underlying test is already using rmake; this PR just modifies the existing rmake recipe to do all the work itself instead of delegating to Python. So there's no particular urgency here.
r? ````@jieyouxu````
try-job: aarch64-gnu
try-job: aarch64-apple
try-job: test-various
try-job: armhf-gnu
try-job: x86_64-msvc
try-job: i686-mingw
Port `run-make/libtest-json` and `run-make/libtest-junit` to rmake
Unlike #126773, this is just a straightforward port to `rmake`, without attempting to switch to compiletest or get rid of the (trivial) Python scripts.
Part of #121876.
r? ````@jieyouxu````
try-job: x86_64-msvc
try-job: i686-mingw
try-job: test-various
try-job: aarch64-gnu
try-job: aarch64-apple
Remove `print::Pat` from the printing of `WitnessPat`
After the preliminary work done in #128536, we can now get rid of `print::Pat` entirely.
- First, we introduce a variant `PatKind::Print(String)`.
- Then we incrementally remove each other variant of `PatKind`, by having the relevant code produce `PatKind::Print` instead.
- Once `PatKind::Print` is the only remaining variant, it becomes easy to remove `print::Pat` and replace it with `String`.
There is more cleanup that I have in mind, but this seemed like a natural stopping point for one PR.
r? ```@Nadrieril```
Improve docs for Waker::noop and LocalWaker::noop
* Add a warning about a likely misuse. (See my commit message for longer rationale.)
* Apply some probably-accidentally-omitted changes to `LocalWaker`'s docs
* Add a comment about the clone-and-hack of the docs
I have used [semantic linefeeds](https://rhodesmill.org/brandon/2012/one-sentence-per-line/) for the docs formatting.
Coalesce `dep-info`, `dep-info-spaces` and `dep-info-doesnt-run-much` `run-make` tests into `dep-info` 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).
This is one of the most ancient tests in the `run-make` directory and its Makefile does some unexpected things, like creating and deleting a `done` directory over and over, sleeping at certain times (this is the [commit](0d9fd8e2a1) that added the `sleep`).
I tried to preserve the intent of the test, which is smoke-testing that `dep-info` works.
try-job: x86_64-msvc
try-job: i686-mingw
try-job: aarch64-gnu
try-job: aarch64-apple
try-job: test-various
try-job: armhf-gnu
try-job: dist-various-1
Rework MIR inlining debuginfo so function parameters show up in debuggers.
Line numbers of multiply-inlined functions were fixed in #114643 by using a single DISubprogram. That, however, triggered assertions because parameters weren't deduplicated. The "solution" to that in #115417 was to insert a DILexicalScope below the DISubprogram and parent all of the parameters to that scope. That fixed the assertion, but debuggers (including gdb and lldb) don't recognize variables that are not parented to the subprogram itself as parameters, even if they are emitted with DW_TAG_formal_parameter.
Consider the program:
```rust
use std::env;
#[inline(always)]
fn square(n: i32) -> i32 {
n * n
}
#[inline(never)]
fn square_no_inline(n: i32) -> i32 {
n * n
}
fn main() {
let x = square(env::vars().count() as i32);
let y = square_no_inline(env::vars().count() as i32);
println!("{x} == {y}");
}
```
When making a release build with debug=2 and rustc 1.82.0-nightly (8b3870784 2024-08-07)
```
(gdb) r
Starting program: /ephemeral/tmp/target/release/tmp [Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, tmp::square () at src/main.rs:5
5 n * n
(gdb) info args
No arguments.
(gdb) info locals
n = 31
(gdb) c
Continuing.
Breakpoint 2, tmp::square_no_inline (n=31) at src/main.rs:10
10 n * n
(gdb) info args
n = 31
(gdb) info locals
No locals.
```
This issue is particularly annoying because it removes arguments from stack traces.
The DWARF for the inlined function looks like this:
```
< 2><0x00002132 GOFF=0x00002132> DW_TAG_subprogram
DW_AT_linkage_name _ZN3tmp6square17hc507052ff3d2a488E
DW_AT_name square
DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs
DW_AT_decl_line 0x00000004
DW_AT_type 0x00001a56<.debug_info+0x00001a56>
DW_AT_inline DW_INL_inlined
< 3><0x00002142 GOFF=0x00002142> DW_TAG_lexical_block
< 4><0x00002143 GOFF=0x00002143> DW_TAG_formal_parameter
DW_AT_name n
DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs
DW_AT_decl_line 0x00000004
DW_AT_type 0x00001a56<.debug_info+0x00001a56>
< 4><0x0000214e GOFF=0x0000214e> DW_TAG_null
< 3><0x0000214f GOFF=0x0000214f> DW_TAG_null
```
That DW_TAG_lexical_block inhibits every debugger I've tested from recognizing 'n' as a parameter.
This patch removes the additional lexical scope. Parameters can be easily deduplicated by a tuple of their scope and the argument index, at the trivial cost of taking a Hash + Eq bound on DIScope.
Use the `enum2$` Natvis visualiser for repr128 C-style enums
Use the preexisting `enum2$` Natvis visualiser to allow PDB debuggers to display fieldless `#[repr(u128)]]`/`#[repr(i128)]]` enums correctly.
Tracking issue: #56071
try-job: x86_64-msvc
Rollup of 6 pull requests
Successful merges:
- #128570 (Stabilize `asm_const`)
- #128828 (`-Znext-solver` caching)
- #128954 (Explicitly specify type parameter on FromResidual for Option and ControlFlow.)
- #129059 (Record the correct target type when coercing fn items/closures to pointers)
- #129071 (Port `run-make/sysroot-crates-are-unstable` to rmake)
- #129088 (Make the rendered html doc for rustc better)
r? `@ghost`
`@rustbot` modify labels: rollup
Shrink `TyKind::FnPtr`.
By splitting the `FnSig` within `TyKind::FnPtr` into `FnSigTys` and `FnHeader`, which can be packed more efficiently. This reduces the size of the hot `TyKind` type from 32 bytes to 24 bytes on 64-bit platforms. This reduces peak memory usage by a few percent on some benchmarks. It also reduces cache misses and page faults similarly, though this doesn't translate to clear cycles or wall-time improvements on CI.
r? `@compiler-errors`
miri: make vtable addresses not globally unique
Miri currently gives vtables a unique global address. That's not actually matching reality though. So this PR enables Miri to generate different addresses for the same type-trait pair.
To avoid generating an unbounded number of `AllocId` (and consuming unbounded amounts of memory), we use the "salt" technique that we also already use for giving constants non-unique addresses: the cache is keyed on a "salt" value n top of the actually relevant key, and Miri picks a random salt (currently in the range `0..16`) each time it needs to choose an `AllocId` for one of these globals -- that means we'll get up to 16 different addresses for each vtable. The salt scheme is integrated into the global allocation deduplication logic in `tcx`, and also used for functions and string literals. (So this also fixes the problem that casting the same function to a fn ptr over and over will consume unbounded memory.)
r? `@saethlin`
Fixes https://github.com/rust-lang/miri/issues/3737
fix: Missing non-exhaustive let diagnostics inside async or unsafe block
The reason that this test doesn't have a pointer deref case is because the following code;
```rust
fn test(ptr: *const Result<i32, !>) {
unsafe {
let Ok(_x) = *ptr;
}
}
```
is getting a block with no stmts but tail one in here(thus, no diagnostic error),
0daeb5c0b0/crates/hir-ty/src/diagnostics/expr.rs (L256-L257)
while the following is getting a block with a single stmt without tail 🤔
```rust
fn test(x: Result<i32, &'static !>) {
let Ok(_y) = x;
}
```
I'll make a more deep inspection and file this as a new issue
_Originally posted by `@ShoyuVanilla` in https://github.com/rust-lang/rust-analyzer/pull/17853#discussion_r1712993585_
