Apple: Avoid redundant `-Wl,-dylib` flag when linking
Seems to have been introduced all the way back in e338a4154b, but should be redundant, `-dynamiclib` should already make `cc` set `-dylib` when linking.
Spotted this while trying to get `-Clinker-flavor=gcc` and `-Clinker-flavor=ld` closer together, not that important to fix.
`@rustbot` label O-apple
fix/update teach_note from 'escaping mutable ref/ptr' const-check
The old note was quite confusing since it talked about statics, but the message is also shown for consts. So let's reword to something that is true for both of them.
Fix a few relative paths in rustc doc
## Changes
- Don't inline the doc for re-exporting some structs that have relative paths in doc.
## Context
See #124028.
- Most of the relative links in rustdoc are there because of circular import (so syntax like `[MyType]: rustc_foo::bar` is difficult to achieve when we cannot import `rustc_xxx` due to circular import)
- Here, I disable new links for re-exports. I think it's fine for re-exported items in `hir::*`.
- There is a few more relative links in other `rustc` crates, however they are not addressed in this PR, as they are not re-exported and/so the relative paths are working.
Closes#124028.
r? `@fmease`
Let me know if I miss anything or there's any other way to address this issue.
LLVM 20 split out what used to be called b16b16 and correspond to aarch64
FEAT_SVE_B16B16 into sve-b16b16 and sme-b16b16.
Add sme-b16b16 as an explicit feature and update the codegen accordingly.
Don't warn on proc macro generated code in `needless_return`
Fixes#13458Fixes#13457Fixes#13467Fixes#13479Fixes#13481Fixes#13526Fixes#13486
The fix is unfortunately a little more convoluted than just simply adding a `is_from_proc_macro`. That check *does* fix the issue, however it also introduces a bunch of false negatives in the tests, specifically when the returned expression is in a different syntax context, e.g. `return format!(..)`.
The proc macro check builds up a start and end pattern based on the HIR nodes and compares it to a snippet of the span, however that would currently fail for `return format!(..)` because we would have the patterns `("return", <something inside of the format macro>)`, which doesn't compare equal. So we now return an empty string pattern for when it's in a different syntax context.
"Hide whitespace" helps a bit for reviewing the proc macro detection change
changelog: none
disable `download-rustc` if LLVM submodule has changes in CI
We can't use CI rustc while using in-tree LLVM (which happens in LLVM submodule update PRs) and this PR handles that by ignoring CI-rustc in CI and failing in non-CI environments.
Rollup of 7 pull requests
Successful merges:
- #131382 (Add "reference" as a known compiletest header)
- #131420 (Dont ICE when encountering post-mono layout cycle error)
- #131424 (compiler: Stop reexporting enum-globs from `rustc_target::abi`)
- #131426 (Fix quotation marks around debug line in `src/ci/run.sh`)
- #131435 (Ignore broken-pipe-no-ice on apple (specifically macOS) for now)
- #131447 (add more crash tests)
- #131456 (Fix typo in E0793)
r? `@ghost`
`@rustbot` modify labels: rollup
Decouple WASIp2 sockets from WasiFd
This is a follow up to #129638, decoupling WASIp2's socket implementation from WASIp1's `WasiFd` as discussed with `@alexcrichton.`
Quite a few trait implementations in `std::os::fd` rely on the fact that there is an additional layer of abstraction between `Socket` and `OwnedFd`. I thus had to add a thin `WasiSocket` wrapper struct that just "forwards" to `OwnedFd`. Alternatively, I could have added a lot of conditional compilation to `std::os::fd`, which feels even worse.
Since `WasiFd::sock_accept` is no longer accessible from `TcpListener` and since WASIp2 has proper support for accepting sockets through `Socket::accept`, the `std::os::wasi::net` module has been removed from WASIp2, which only contains a single `TcpListenerExt` trait with a `sock_accept` method as well as an implementation for `TcpListener`. Let me know if this is an acceptable solution.
Fix needless_lifetimes in rustc_serialize
Hi,
This PR fixes the following clipy warnings:
```
warning: the following explicit lifetimes could be elided: 'a
--> compiler/rustc_serialize/src/serialize.rs:328:6
|
328 | impl<'a, S: Encoder, T: Encodable<S>> Encodable<S> for Cow<'a, [T]>
| ^^ ^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_lifetimes
= note: `#[warn(clippy::needless_lifetimes)]` on by default
help: elide the lifetimes
|
328 - impl<'a, S: Encoder, T: Encodable<S>> Encodable<S> for Cow<'a, [T]>
328 + impl<S: Encoder, T: Encodable<S>> Encodable<S> for Cow<'_, [T]>
|
warning: the following explicit lifetimes could be elided: 'a
--> compiler/rustc_serialize/src/serialize.rs:348:6
|
348 | impl<'a, S: Encoder> Encodable<S> for Cow<'a, str> {
| ^^ ^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_lifetimes
help: elide the lifetimes
|
348 - impl<'a, S: Encoder> Encodable<S> for Cow<'a, str> {
348 + impl<S: Encoder> Encodable<S> for Cow<'_, str> {
|
warning: the following explicit lifetimes could be elided: 'a
--> compiler/rustc_serialize/src/serialize.rs:355:6
|
355 | impl<'a, D: Decoder> Decodable<D> for Cow<'a, str> {
| ^^ ^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_lifetimes
help: elide the lifetimes
|
355 - impl<'a, D: Decoder> Decodable<D> for Cow<'a, str> {
355 + impl<D: Decoder> Decodable<D> for Cow<'_, str> {
```
Best regards,
Michal
Reserve guarded string literals (RFC 3593)
Implementation for RFC 3593, including:
- lexer / parser changes
- diagnostics
- migration lint
- tests
We reserve `#"`, `##"`, `###"`, `####`, and any other string of four or more repeated `#`. This avoids infinite lookahead in the lexer, though we still use infinite lookahead in the parser to provide better forward compatibility diagnostics.
This PR does not implement any special lexing of the string internals:
- strings preceded by one or more `#` are denied
- regardless of the number of trailing `#`
- string contents are lexed as if it was just a bare `"string"`
Tracking issue: #123735
RFC: rust-lang/rfcs#3593
