The name of NativeLib will be presented
Fixes#109144
I was working on a quick fix, but found change the name from `Option<Symbol>` to `Symbol` make life a little bit easier.
fix: don't suggest similar method when unstable
Fixes#109177
Don't display typo suggestions for unstable things, unless the feature flag is enabled.
AFAIK, there are two places this occurs:
- `rustc_resolve`: before type checking, effectively just `FnCtxt::Free`.
- `rustc_hir_typck`: during type checking, for `FnCtxt::Assoc(..)`s.
The linked issue is about the latter, obviously the issue is applicable to both.
r? `@estebank`
Add `useless_anonymous_reexport` lint
This is a follow-up of https://github.com/rust-lang/rust/pull/108936. We once again show all anonymous re-exports in rustdoc, however we also wanted to add a lint to let users know that it very likely doesn't have the effect they think it has.
Add note for mismatched types because of circular dependencies
If you have crate A with a dependency on crate B, and crate B with a dev-dependency on A, then you might see "mismatched types" errors on types that seem to be equal. This PR adds a note that explains that the types are different, because crate B is compiled twice, one time with `cfg(test)` and one time without.
I haven't found a good way to create circular dependencies in UI tests, so I abused the incremental tests instead. As a bonus, incremental tests support "cpass" now.
related to https://github.com/rust-lang/rust/issues/22750
Use `size_of_val` instead of manual calculation
Very minor thing that I happened to notice in passing, but it's both shorter and [means it gets `mul nsw`](https://rust.godbolt.org/z/Y9KxYETv5), so why not.
Fix generics mismatch errors for RPITITs on -Zlower-impl-trait-in-trait-to-assoc-ty
This PR stops reporting errors due to different count of generics on the new synthesized associated types for RPITITs. Those were already reported when we compare the function on the triat with the function on the impl.
r? ``@compiler-errors``
Tweak implementation of overflow checking assertions
Extract and reuse logic controlling behaviour of overflow checking assertions instead of duplicating it three times.
r? `@cjgillot`
resolve: Improve debug impls for `NameBinding`
Print at least the Some/None/Ok/Err status of the nested bindings if not the bindings themselves.
Noticed while reviewing https://github.com/rust-lang/rust/pull/108729.
Pass the right HIR back from `get_fn_decl`
Fixes#109232
Makes sure that the `fn_id: HirId` that we pass to `suggest_missing_return_type` matches up with the `fn_decl: hir::FnDecl` that we pass to it, so the late-bound vars that we fetch from the former match up with the types in the latter...
This HIR suggestion code really needs a big refactor. I've tried to do it in the past (a couple of attempts), but it's a super tangled mess. It really shouldn't be passing around things like `hir::Node` and just deal with `LocalDefId`s everywhere... Anyways, I'd rather fix this ICE, now.
Do not ICE for unexpected lifetime with ConstGeneric rib
Fixes#109143
r? ````@petrochenkov````
Combining this test with the previous test will affect the previous diagnostics, so I added a separate test case.
- only borrow the refcell once per loop
- avoid complex matches to reduce branch paths in the hot loop
- use a by-ref fast path that avoids mutations at the expense of having false negatives
Use index based drop loop for slices and arrays
Instead of building two kinds of drop pair loops, of which only one will be eventually used at runtime in a given monomorphization, always use index based loop.
Install projection from RPITIT to default trait method opaque correctly
1. For new lowering strategy `-Zlower-impl-trait-in-trait-to-assoc-ty`, install the correct default trait method projection predicates (RPITIT -> opaque). This makes default trait body tests pass!
2. Fix two WF-checking bugs -- first, we want to make sure that we're always looking for an opaque type in `check_return_position_impl_trait_in_trait_bounds`. That's because the RPITIT projections are normalized to opaques during wfcheck. Second, fix RPITIT's param-envs by not adding the projection predicates that we install on trait methods to make default RPITITs work -- I left a comment why.
3. Also, just a small drive-by for `rustc_on_unimplemented`. Not sure if it affects any tests, but can't hurt.
r? ````@spastorino,```` based off of #109140
Fix riscv64 fuchsia LLVM target name
Currently, riscv64gc-unknown-fuchsia (added in #108722) sets riscv64*gc*-unknown-fuchsia as the LLVM target.
1716932743/compiler/rustc_target/src/spec/riscv64gc_unknown_fuchsia.rs (L5)
However, riscv64*gc*-\* is not a valid LLVM target and causes the following error.
```console
$ rustc --print cfg --target riscv64gc-unknown-fuchsia
error: could not create LLVM TargetMachine for triple: riscv64gc-unknown-fuchsia: No available targets are compatible with triple "riscv64gc-unknown-fuchsia"
```
As with other RISC-V targets, the LLVM target should use riscv64-\*, not riscv64*gc*-\*.
1716932743/compiler/rustc_target/src/spec/riscv64gc_unknown_freebsd.rs (L5)1716932743/compiler/rustc_target/src/spec/riscv64gc_unknown_linux_gnu.rs (L5)
I confirmed that riscv64-unknown-fuchsia is recognized as a valid LLVM target by using custom targets.
```console
# create a custom target with `"llvm-target": "riscv64-unknown-fuchsia" from no-std riscv64gc target.
$ rustc --print target-spec-json -Z unstable-options --target riscv64gc-unknown-none-elf | grep -v is-builtin | sed 's/"llvm-target".*/"llvm-target": "riscv64-unknown-fuchsia",/' > riscv64gc-unknown-fuchsia.json
$ rustc --print cfg --target riscv64gc-unknown-fuchsia.json
debug_assertions
panic="abort"
target_abi=""
target_arch="riscv64"
target_endian="little"
target_env=""
target_feature="a"
target_feature="c"
target_feature="d"
target_feature="f"
target_feature="m"
...
$ cat riscv64gc-unknown-fuchsia.json
{
"arch": "riscv64",
"code-model": "medium",
"cpu": "generic-rv64",
"data-layout": "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128",
"eh-frame-header": false,
"emit-debug-gdb-scripts": false,
"features": "+m,+a,+f,+d,+c",
"linker": "rust-lld",
"linker-flavor": "ld.lld",
"llvm-abiname": "lp64d",
"llvm-target": "riscv64-unknown-fuchsia",
"max-atomic-width": 64,
"panic-strategy": "abort",
"relocation-model": "static",
"supported-sanitizers": [
"kernel-address"
],
"target-pointer-width": "64"
}
# Check the current master's LLVM target name causes an error
$ sed -i 's/riscv64-unknown-fuchsia/riscv64gc-unknown-fuchsia/' riscv64gc-unknown-fuchsia.json
$ rustc --print cfg --target riscv64gc-unknown-fuchsia.json
error: could not create LLVM TargetMachine for triple: riscv64gc-unknown-fuchsia: No available targets are compatible with triple "riscv64gc-unknown-fuchsia"
```
r? ````@tmandry````
Remove box expressions from HIR
After #108516, `#[rustc_box]` is used at HIR->THIR lowering and this is no longer emitted, so it can be removed.
This is based on top of #108471 to help with conflicts, so 43490488ccacd1a822e9c621f5ed6fca99959a0b is the only relevant commit (sorry for all the duplicated pings!)
````@rustbot```` label +S-blocked
Wrap the whole LocalInfo in ClearCrossCrate.
MIR contains a lot of information about locals. The primary purpose of this information is the quality of borrowck diagnostics.
This PR aims to drop this information after MIR analyses are finished, ie. starting from post-cleanup runtime MIR.
Flatten/inline format_args!() and (string and int) literal arguments into format_args!()
Implements https://github.com/rust-lang/rust/issues/78356
Gated behind `-Zflatten-format-args=yes`.
Part of #99012
This change inlines string literals, integer literals and nested format_args!() into format_args!() during ast lowering, making all of the following pairs result in equivalent hir:
```rust
println!("Hello, {}!", "World");
println!("Hello, World!");
```
```rust
println!("[info] {}", format_args!("error"));
println!("[info] error");
```
```rust
println!("[{}] {}", status, format_args!("error: {}", msg));
println!("[{}] error: {}", status, msg);
```
```rust
println!("{} + {} = {}", 1, 2, 1 + 2);
println!("1 + 2 = {}", 1 + 2);
```
And so on.
This is useful for macros. E.g. a `log::info!()` macro could just pass the tokens from the user directly into a `format_args!()` that gets efficiently flattened/inlined into a `format_args!("info: {}")`.
It also means that `dbg!(x)` will have its file, line, and expression name inlined:
```rust
eprintln!("[{}:{}] {} = {:#?}", file!(), line!(), stringify!(x), x); // before
eprintln!("[example.rs:1] x = {:#?}", x); // after
```
Which can be nice in some cases, but also means a lot more unique static strings than before if dbg!() is used a lot.
