Emit `check-cfg` lints during attribute parsing rather than evaluation
The goal of this PR is to make the `eval_config_entry` not have any side effects, by moving the check-cfg lints to the attribute parsing. This also helps ensure we do emit the lint in situations where the attribute happens to be parsed, but never evaluated.
cc ``@jdonszelmann`` ``@Urgau`` for a vibe check if you feel like it
Move the libgccjit.so file in a target directory
Since GCC is not multi-target, we need multiple libgccjit.so. Our solution to have a directory per target so that we can have multiple libgccjit.so.
r? `@Kobzol`
contracts: clean up feature flag warning duplicated across tests
There is no need for every contracts test to assert the same warning for using the `contracts` feature flag, as such use `#![expect(incomplete_features)]` in the tests, and add one test to specifically check for the warning.
Making this change has been discussed in the comments of rust-lang/rust#149722.
Contracts tracking issue: https://github.com/rust-lang/rust/issues/128044
r? Kivooeo
contracts: fix lowering final declaration without trailing semicolon
Lowering for contract delcarations introduced in rust-lang/rust#144444 incorrectly handled the final declaration statement when it didn't end in a semicolon. This change fixes the issue.
See the included regression test for the minimal reproducible example.
Contracts tracking issue: https://github.com/rust-lang/rust/issues/128044
Tidying up tests/ui/issues tests [3/N]
> [!NOTE]
> Intermediate commits are intended to help review, but will be squashed add comment commit prior to merge.
part of rust-lang/rust#133895
r? Kivooeo
Add `ilog10` result range hints
This PR adds hints that the return value of `T::ilog10` will never exceed `T::MAX.ilog10()`.
This works because `ilog10` is a monotonically nondecreasing function, the maximum return value is reached at the max input value.
Merged tests/ui/typeck/non-function-call-error-2 with
tests/ui/typeck/non-function-call-error
Add comment to
tests/ui/traits/normalize-associated-type-in-where-clause.rs
Merged tests/ui/privacy/private-item-simple-2.rs with
tests/ui/privacy/private-item-simple.rs
Merged tests/ui/str/str-add-operator-2.rs with
tests/ui/str/str-add-operator.rs
Add comment to tests/ui/imports/duplicate-empty-imports.rs
Add comment to tests/ui/for-loop-while/nested-loop-break-unit.rs
Add comment to tests/ui/match/match-ref-option-pattern.rs
Add comment to tests/ui/closures/simple-capture-and-call.rs
Add comment to tests/ui/type/never-type-inference-fail.rs
Add comment to tests/ui/match/match-stack-overflow-72933.rs
There is no need for every contracts test to assert the same warning
for using the `contracts` feature flag, as such use
`#![expect(incomplete_features)]` in the tests, and add one test
to specifically check for the warning.
Tidying up `tests/ui/issues` tests [1/N]
> [!NOTE]
> Intermediate commits are intended to help review, but will be squashed add comment commit prior to merge.
part of rust-lang/rust#133895
Add warn-by-default lint for visibility on `const _` declarations
Add a warn-by-default `unused_visibilities` lint for visibility qualifiers on `const _` declarations—e.g. `pub const _: () = ();`. Such qualifiers have no effect.
A [Sourcegraph search](https://sourcegraph.com/search?q=context:global+lang:Rust+pub%5Cs*%28%5C%28.*%5C%29%29%3F%5Cs*const%5Cs%2B_%5Cs*:&patternType=regexp&case=yes&sm=0) suggests that this pattern is relatively rare, and mostly found in tests (with only 3 exceptions). So perhaps this could become an FCW/hard error in the future.
`@rustbot` label T-lang A-lints A-visibility -T-clippy
merged tests/ui/issues/issue-2951.rs with
tests/ui/type/type-parameter-names.rs
Merged
tests/ui/for-loop-while/break-continue-in-loop-while-contiditoin-1.rs
with
tests/ui/for-loop-while/break-continue-in-loop-while-contiditoin-2.rs
Removed tests/ui/issues/issue-2383.rs
duplicated of library\alloc\src\collections\vec_deque\tests.rs
Removed tests/ui/issues/issue-20714.rs
duplicated of tests/ui/empty/empty-struct-unit-expr.rs
Added comment to tests/ui/match/match-option-result-mismatch.rs, tests/ui/numeric/ref-int.rs,
tests/ui/box/self-assignment.rs
Add a warn-by-default `unused_visibility` lint for visibility qualifiers
on `const _` declarations - e.g. `pub const _: () = ();`.
These have no effect.
rustdoc: fix bugs with search aliases and merging
These bugs cause a crash and a perf problem with aliases, caused by loading the search index when it's not expected.
cc `@weihanglo`
r? `@GuillaumeGomez`
Assume the returned value in `.filter(…).count()`
Similar to how this helps in `slice::Iter::position`, LLVM sometimes loses track of how high this can get, so for `TrustedLen` iterators tell it what the upper bound is.
Fix `name()` functions for local defs in rustc_public
This change fixes the behavior of the `name()` function for `CrateDef` and `Instance` which should return absolute path of items. For local items, the crate name was missing.
This resolves: https://github.com/rust-lang/project-stable-mir/issues/109
`c_variadic`: make `VaList` abi-compatible with C
tracking issue: https://github.com/rust-lang/rust/issues/44930
related PR: rust-lang/rust#144529
On some platforms, the C `va_list` type is actually a single-element array of a struct (on other platforms it is just a pointer). In C, arrays passed as function arguments expirience array-to-pointer decay, which means that C will pass a pointer to the array in the caller instead of the array itself, and modifications to the array in the callee will be visible to the caller (this does not match Rust by-value semantics). However, for `va_list`, the C standard explicitly states that it is undefined behaviour to use a `va_list` after it has been passed by value to a function (in Rust parlance, the `va_list` is moved, not copied). This matches Rust's pass-by-value semantics, meaning that when the C `va_list` type is a single-element array of a struct, the ABI will match C as long as the Rust type is always be passed indirectly.
In the old implementation, this ABI was achieved by having two separate types: `VaList` was the type that needed to be used when passing a `VaList` as a function parameter, whereas `VaListImpl` was the actual `va_list` type that was correct everywhere else. This however is quite confusing, as there are lots of footguns: it is easy to cause bugs by mixing them up (e.g. the C function `void foo(va_list va)` was equivalent to the Rust `fn foo(va: VaList)` whereas the C function `void bar(va_list* va)` was equivalent to the Rust `fn foo(va: *mut VaListImpl)`, not `fn foo(va: *mut VaList)` as might be expected); also converting from `VaListImpl` to `VaList` with `as_va_list()` had platform specific behaviour: on single-element array of a struct platforms it would return a `VaList` referencing the original `VaListImpl`, whereas on other platforms it would return a cioy,
In this PR, there is now just a single `VaList` type (renamed from `VaListImpl`) which represents the C `va_list` type and will just work in all positions. Instead of having a separate type just to make the ABI work, rust-lang/rust#144529 adds a `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute, which when applied to a struct will force the struct to be passed indirectly by non-Rustic calling conventions. This PR then implements the `VaList` rework, making use of the new attribute on all platforms where the C `va_list` type is a single-element array of a struct.
Cleanup of the `VaList` API and implementation is also included in this PR: since it was decided it was OK to experiment with Rust requiring that not calling `va_end` is not undefined behaviour (https://github.com/rust-lang/rust/issues/141524#issuecomment-3028383594), I've removed the `with_copy` method as it was redundant to the `Clone` impl (the `Drop` impl of `VaList` is a no-op as `va_end` is a no-op on all known platforms).
Previous discussion: rust-lang/rust#141524 and [t-compiler > c_variadic API and ABI](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/c_variadic.20API.20and.20ABI)
Tracking issue: https://github.com/rust-lang/rust/issues/44930
r? `@joshtriplett`
Add perma-unstable `--print=backend-has-zstd` for use by compiletest
Tests for `-Zdebuginfo-compression=zstd` need to be skipped if LLVM was built without support for zstd compression.
Currently, compiletest relies on messy and fragile heuristics to detect whether the compiler's LLVM was built with zstd support. But the compiler itself already knows whether LLVM has zstd or not, so it's easier for compiletest to just ask the compiler.
---
Originally I was intending for this to be a `--print=debuginfo-compression` flag that would print out a list of values supported by `-Zdebuginfo-compression=`. I got that working locally, but it was more complex than I was happy with (in both rustc and compiletest), so I decided to cut scope and instead add a very narrow perma-unstable print request instead.
There is always a circularity hazard whenever we ask the compiler-under-test for information about how to test it. But in this case, the underlying compiler code is fairly simple, whereas the previous heuristics were inherently messy and unreliable anyway.
Add regression test for 141845
close: rust-lang/rust#141845
I saw the `tests/ui/associated-inherent-types` directory, but I felt the current location was a better fit.
Check identifiers defined in macros when suggesting identifiers hidden by hygiene
Fixrust-lang/rust#149604
r? `@JonathanBrouwer` (Since you reviewed the other one related to this)
Generate delegation error body when delegation is not resolved
This PR relates to the delegation feature rust-lang/rust#118212, it fixesrust-lang/rust#144594 ICE.
r? `@petrochenkov`
library: Rename `IterRange*` to `Range*Iter`
There is a weak convention in the ecosystem that `IterFoos` is an iterator yielding items of type `Foo` (e.g. `bitflags` `IterNames`, `hashbrown` `IterBuckets`), while `FooIter` is an iterator over `Foo` from an `.iter()` or `.into_iter()` method (e.g. `memchr` `OneIter`, `regex` `SetMatchesIter`). Rename `IterRange`, `IterRangeInclusive`, and `IterRangeFrom` to `RangeIter`, `RangeInclusiveIter`, and `RangeInclusiveIter` to match this.
Tracking issue: https://github.com/rust-lang/rust/issues/125687 (`new_range_api`)
misc coercion cleanups and handle safety correctly
r? lcnr
### "remove normalize call"
Fixesrust-lang/rust#132765
If the normalization fails we would sometimes get a `TypeError` containing inference variables created inside of the probe used by coercion. These would then get leaked out causing ICEs in diagnostics logic
### "leak check and lub for closure<->closure coerce-lubs of same defids"
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/233
```rust
fn peculiar() -> impl Fn(u8) -> u8 {
return |x| x + 1
}
```
the `|x| x + 1` expr has a type of `Closure(?31t)` which we wind up inferring the RPIT to. The `CoerceMany` `ret_coercion` for the whole `peculiar` typeck has an expected type of `RPIT` (unnormalized). When we type check the `return |x| x + 1` expr we go from the never type to `Closure(?31t)` which then participates in the `ret_coercion` giving us a `coerce-lub(RPIT, Closure(?31t))`.
Normalizing `RPIT` gives us some `Closure(?50t)` where `?31t` and `?50t` have been unified with `?31t` as the root var. `resolve_vars_if_possible` doesn't resolve infer vars to their roots so these wind up with different structural identities so the fast path doesn't apply and we fall back to coercing to a `fn` ptr. cc rust-lang/rust#147193 which also fixes this
New solver probably just gets more inference variables here because canonicalization + generally different approach to normalization of opaques. Idk :3
### FCP worthy stuffy
there are some other FCP worthy things but they're in my FCP comment which also contains some analysis of the breaking nature of the previously listed changes in this PR: https://github.com/rust-lang/rust/pull/148602#issuecomment-3503497467
Matthias Krüger