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
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
Add a warn-by-default `unused_visibility` lint for visibility qualifiers
on `const _` declarations - e.g. `pub const _: () = ();`.
These have no effect.
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
Move attribute lints to `rustc_lint`
This PR changes two things:
- This decouples the `AttributeLintKind` from the `Lint` it is emitted in. `cx.emit_lint` now takes both as an argument, rather than inferring the `Lint` from the `AttributeLintKind`. This is nice because:
- It allows us to remove `AttributeLintKind::InvalidMacroExportArguments`
- It allows us to move the choice between `USELESS_DEPRECATED` and `UNUSED_ATTRIBUTES` out of the lint emitting code
- It allows the next change:
- This moves `AttributeLintKind` to `rustc_lint_defs`, and the decorating code to `rustc_lint`. This is nice because:
- It allows attribute lint decorating code to access the TypeCtxt, which unblocks https://github.com/rust-lang/rust/pull/149215
- It might allow most early buffered attribute lints to become dyn lint diagnostics in the future, as in https://github.com/rust-lang/rust/pull/147634
- It deduplicates `IllFormedAttributeInput`
This PR does not change observable output of the compiler, as can be seen by no uitests being affected.
r? `@jdonszelmann`
`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`
interpret: test SNaN handling of float min/max and update comments
Also see https://github.com/rust-lang/rust/pull/149563.
I also renamed these enum variants so they are not almost identical.
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.
Fix for LLVM22 making lowering decisions dependent on RuntimeLibraryInfo.
LLVM added codegen decision making based on RuntimeLibraryInfo. Mirror the change in Rust's codegen.
LLVM reference commit:
04c81a9973.
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`
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
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.
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#147224 (Emscripten: Turn wasm-eh on by default)
- rust-lang/rust#149405 (Recover on misspelled item keyword)
- rust-lang/rust#149443 (Tidying up UI tests [6/N])
- rust-lang/rust#149524 (Move attribute safety checking to attribute parsing)
- rust-lang/rust#149593 (powf, powi: point out SNaN non-determinism)
- rust-lang/rust#149605 (Use branch name instead of HEAD when unshallowing)
- rust-lang/rust#149612 (Apply the `bors` environment also to the `outcome` job)
- rust-lang/rust#149623 (Don't require a normal tool build of clippy/rustfmt when running their test steps)
- rust-lang/rust#149627 (Point to the item that is incorrectly annotated with `#[diagnostic::on_const]`)
r? `@ghost`
`@rustbot` modify labels: rollup
Move attribute safety checking to attribute parsing
This PR moves attribute safety checking to be done during attribute parsing. The `cfg` and `cfg_attr` attribute no longer need special-cased safety checking, yay!
This PR is a part 1 of 2, in the second part I'd like to define attribute safety in the attribute parsers rather than getting the information from BUILTIN_ATTRIBUTE_MAP, but to keep PRs reviewable lets do that separately.
Fixes https://github.com/rust-lang/rust/issues/148453 by reordering the diagnostics. The "cannot find attribute" diagnostic now appears first, but both diagnostics still appear.
r? `@jdonszelmann`
Recover on misspelled item keyword
the title says everything. first commit adds a test that shows how current `main` behaves on misspelled item keyword. second commit adds the recovery, which allows to emit many more errors.
This removes variance information from some diagnostics. However,
that variance information is not actually relevant here. Casting
`*const dyn Cat<'a>` to `*const S<dyn Cat<'static>>` is an error
regardless of whether `S` requires its argument to be invariant.
Wide-pointer casts always require the trait object arguments to be
invariant.
