cg_clif: Don't show verbose run-make cmd output for passing tests
Uses `--verbose-run-make-subprocess-output=false` added in rust-lang/rust#154587 to suppress verbose cmd dump for passing `run-make` tests.
Closesrust-lang/rust#154069.
Add better default spans for the `Ty` impl of `QueryKey`
This add default spans for `Ty` in its implementation of `QueryKey`. This is useful so we can get spans for the `layout_of` query which shows up in cycle errors.
CFI: Fix LTO for `#![no_builtins]` crates with CFI
Fixes LTO for `#![no_builtins]` crates with CFI enabled by using rustc's `EmitObj::Bitcode` path (and emitting LLVM bitcode in the `.o` for linker-based LTO).
It also adds tests that verify that the examples in [rust-cfi-examples](https://github.com/rcvalle/rust-cfi-examples) build and run with `-Zbuild-std` to prevent other future regressions.
Add `keepalive`, `set_keepalive` to `TcpStream` implementations
## What
The current implementation of `TcpStream` does not expose `SO_KEEPALIVE`: rust-lang/rust#69774
## Why
It seems the reason this has not yet been implemented is because the initial implementation went as far as to take the keepalive interval as a parameter. However, Windows does not directly expose these intervals for reading, causing there to be some debate about the shape of the API (see the discussion of this [here](https://github.com/rust-lang/rust/pull/31945#issuecomment-189784913)).
## How
I am proposing that this API is enabled with a `bool` parameter to align with the implementation in both Windows and Unix, as it is the least common denominator between the two of them. With regards to the call to `setsockopt`, [Windows expects a disable/enable](https://learn.microsoft.com/en-us/windows/win32/winsock/so-keepalive), and [Unix does as well](https://man7.org/linux/man-pages/man7/socket.7.html).
The extra configuration for Unix that allows the interval to be tweaked could be done through an additional API perhaps, but I don't think that's stopping us from exposing the switch to at least enable the behavior with the OS defaults.
Tracking issue: rust-lang/rust#155889
lint ImproperCTypes: refactor linting architecture (part 2)
This is the second PR in an effort to split https://github.com/rust-lang/rust/pull/134697 (refactor plus overhaul of the ImproperCTypes family of lints) into individually-mergeable parts.
Contains the changes of the first PR, and splits the core type checking function into several bits, each focused on a specific aspect of FFI-safety.
Some logic which was outside of said core function was also moved into the new functions.
Superset of: rust-lang/rust#146271
Document wasi-sdk minimum versions for WASI targets
This commit updates the documentation for WASI targets in the rustc book to mention a minimum version of wasi-sdk that's required.
Closesrust-lang/rust#155971
compiletest: prevent directives from having multiple revisions
Right now, a compiletest directive like `//@ [foo,bar] compile-flags: -Z hello` is accepted. While it looks similar to a `//[foo,bar]` error annotation matching multiple revisions, it will instead model a directive for a single revision named `foo,bar` and not for two revisions. Slightly inconsistent/confusing.
I don't know that it's common enough to make bigger changes to support it fully (`miri`'s test harness seems to support that use-case), but since I hit that today, this PR prevents that case for now. Otherwise, I think we'd have to turn all uses of `line_directive` as possibly creating multiple line directives, one per revision, etc.
Such a directive will now yield an error, with a best-effort suggestion to split it into multiple single-revision directives:
```
multiple revisions aren't supported yet in `//@ [foo,bar] compile-flags: -Z hello`, split them like
//@ [foo]: compile-flags: -Z hello
//@ [bar]: compile-flags: -Z hello
```
llvm: Use correct type for splat mask
After llvm/llvm-project#195486 , LLVM has explicit handling for null pointers in simd operations instead of using special handling based on zeroes.
This causes LLVM with asserts enabled to detect an improperly typed mask passed to splat (if the output vector does not have i32 elements), and can cause SIGSEGV in more complex cases with asserts disabled.
@rustbot label: +llvm-main
r? @durin42
Use special DefIds for aliases
Renewal of https://github.com/rust-lang/rust/pull/155025, after `AliasTermKind` was also ported.
Like we do for other things for better experience in rust-analyzer.
It's possible now that the `AliasTyKind` and `AliasTermKind` contains the DefId.
It does require a few `try_into().unwrap()`s since in the solver's `consider_X_candidate()` only get an untyped `DefId`. It's possible to reduce that considerably if we'd pass them the typed def id as a parameter, but I don't know what will be the impact on perf. Should I try to pursue that?
r? lcnr
Deny warnings in the test for crates that are available on stable
We've got a couple of crates, like `rustc_type_ir` that have parts disabled on stable. I believe part of this is so, for example, rust-analyzer can use bits of the compiler. We previously allowed warnings here, and I ran into one. This denies warnings in the test that compiles these stable crates (I chose not to on the crate itself, so you don't *constantly* run into the warnings if you have turned that off in `config.toml`). This test doesn't run by default, but it does run in CI.
Fewer global node_id_to_def_id lookups
Several of these are unnecessary if we track the `LocalDefId` together with the `NodeId`. We can't remove the `NodeId` entirely, as it is needed for lints, but it's a useful refactoring for splitting node_id_to_def_id into a per-owner table in the future
r? @petrochenkov
Lint unused pub items in binary crates
~~This PR adds a new unstable flag -Ztreat-pub-as-pub-crate as [@Kobzol](https://github.com/Kobzol) suggested.~~
~~When compiling binary crates with this flag, the seed worklist will only contain the entry fn and won't contain other reachable items. Then we can do the dead code analysis for pub items just like they are pub(crate).~~
Related zulip thread [#general > pub/pub(crate) within a binary is a footgun](https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/pub.2Fpub.28crate.29.20within.20a.20binary.20is.20a.20footgun/with/558931034).
---
Updated:
Adds a new lint `unused_pub_items_in_binary` (crate-level, default allow for now) instead of the previous unstable flag to lint unused `pub` items for binary crates.
See more details of implementation in https://github.com/rust-lang/rust/pull/149509#issuecomment-4102337689.
This lint is allowed by default, but I believe this has been better than the unstable flag. Making it warn-by-default will lead to a lot of noise for this PR (like bless many tests). So I'd like to make it warn-by-default in a separate PR in the future.
change the type of the argument of `drop_in_place` lang item to `&mut _`
We used to special case `core::ptr::drop_in_place` when computing LLVM argument attributes with this hack:
https://github.com/rust-lang/rust/blob/db5e2dc248fe5bb26f70d7baec46a3bca9fa3e1d/compiler/rustc_ty_utils/src/abi.rs#L383-L392
This is because even though `drop_in_place` takes a `*mut T` it is semantically a `&mut T` (remember how `&mut Self` is passed to `Drop::drop`). This is apparently relevant for perf.
This PR replaces this hack with a simpler solution -- it makes `drop_in_place` a thin wrapper around newly added `core::ptr::drop_glue`, which is the actual lang item and takes a `&mut T`:
https://github.com/rust-lang/rust/blob/d2563d5003bbecff1efc40c1f5673ceec603825b/library/core/src/ptr/mod.rs#L810-L833
------
The rest of the PR is blessing tests and cleaning up things which are not necessary after this change.
One thing that is a bit awkward is that now that `drop_glue` is the actual lang item, a lot of the comments referring to `drop_in_place` are outdated. Should I try fixing that?
I've also changed `async_drop_in_place` to take a `&mut T`, and it simplified the code handling it a bit. (since it's unstable we don't need to introduce a wrapper)
-------
cc @RalfJung
Closes https://github.com/rust-lang/rust/issues/154274
Fixes LTO for `#![no_builtins]` crates with CFI enabled by using rustc's
`EmitObj::Bitcode` path (and emitting LLVM bitcode in the `.o` for
linker-based LTO).
tests/ui: allow spaces in hashbrown src normalization
If one's home directory contains a space, the default location for the hashbrown source location also contains a space, and so the UI test normalization in issue-21763 fails to normalize as expected.
While this new regex does not handle all valid paths, such as those beginning with `\\?\` or `\\name\`, this handles most absolute UNIX and Windows paths. Relative paths don't seem to be applicable.
Don't return dummy MacroData in `get_macro`
I was experimenting with tool attributes and ast manipulation, and wasted some time figuring out that this was happening. AFAIK all users of `get_macro` are expecting an actual macro (and none were reading the dummy MacroData) so there should be no change in behavior.
Like we do for other things for better experience in rust-analyzer.
It's possible now that the `AliasTyKind` and `AliasTermKind` contains the DefId.
It does require a few `try_into().unwrap()`s since in the solver's `consider_X_candidate()` only get an untyped `DefId`. It's possible to reduce that considerably if we'd pass them the typed def id as a parameter, but I don't know what will be the impact on perf.
Nicholas Nethercote