Rollup of 4 pull requests - #161554
Closed
JonathanBrouwer wants to merge 14 commits into
Closed
Conversation
Honor build.docs-minification=false for rustdoc suites run via compiletest by forwarding --disable-minification to rustdoc.
A braced const argument that is a call, like `Ty<{ Ty::f() }>`, is lowered
as a tuple constructor. When the callee's self type cannot host a
tuple-variant constructor (a struct, union, primitive, or foreign type),
the call is an associated function, not a constructor, and must be wrapped
in a `const { ... }` block.
Detect that from the self type's resolution before lowering it, and emit
the existing "complex const arguments must be placed inside of a `const`
block" diagnostic. A generic struct written without its arguments, as
`tracing`'s logging macros generate, would otherwise produce a spurious
E0107 "missing generics" cascade; a primitive or foreign type would
surface an opaque "invalid base path" error.
Enums, aliases, `Self`, and type parameters are left to constructor
lowering, since each may resolve to an enum.
Add UI tests for struct, union, primitive, and foreign self types, plus
the `const { ... }`-wrapped form that compiles.
…157152, r=BoxyUwU
Reject non-constructor self types in const-arg tuple-call lowering
Turning on `min_generic_const_args` makes `tracing` stop compiling. Its logging macros expand a field name to something like `FieldName<{ FieldName::len(stringify!(field)) }>`, and under mgca a braced call in const-arg position gets lowered as a tuple constructor. So lowering tries to resolve the bare self type `FieldName` (written without its `const N`), which kicks off an `E0107 "missing generics"` cascade pointing deep into macro code. But `FieldName::len(..)` is just an associated fn, not a constructor, so lowering it like a `TupleCall` was wrong in the first place. See rust-lang#157152.
Only an enum can host a tuple-variant ctor, so for any other self type that can't (struct, union, primitive, foreign type) the call has to be an assoc fn and needs wrapping in `const { ... }`. We catch those from the self type's resolution before lowering it and emit the existing "complex const arguments must be placed inside of a `const` block" error, which is the message you'd want anyway. Enums, aliases, `Self` and type params get left alone since they might resolve to an enum. tbh the bare generic *enum* case (`Option::Some(0)`) still E0107s, and imo that's better as a follow-up since catching it needs the variant type before lowering. Tests cover struct/union/primitive/foreign plus the wrapped forms that compile, and I checked it against the real `tracing` 0.1.44 crate too.
_fwiw just the code changes and tests were implemented with AI help and I verified/reproduced/tested everything locally before sending to remote._
…rward-disable-minification, r=lolbinarycat compiletest: forward disable-minification from bootstrap `build.docs-minification = false` was already honored when building docs through bootstrap's doc steps, but compiletest-driven rustdoc suites always generated minified CSS/JS. Bootstrap now forwards `--disable-minification` to compiletest when docs minification is disabled, and compiletest passes `-Zunstable-options --disable-minification` to rustdoc for HTML/JS/JSON/UI doc generation. Fixes rust-lang#142737.
…, r=Mark-Simulacrum feat: add symmetric PartialEq impls for Vec, &[T], &mut [T] versus Cow<'_, [T]> add the missing reverse `PartialEq<Cow<'_, [U]>>` impls for `Vec<T, A>`, `&[T]`, and `&mut [T]`, essentially mirroring the existing forwards in `library/alloc/src/vec/partial_eq.rs` partially addresses rust-lang#152830. The `VecDeque` half of that issue is being handled separately by rust-lang#152972, so there is no overlap with this PR also fyi: verified locally with `./x test library/alloctests --stage 1` and the new `test_partial_eq_cow_symmetric` test passes alongside the existing alloc test suite
…kingjubilee target_features: sse (or at least avx2) is incompatible with soft-float ABI Fixes rust-lang#117938 Enabling both the avx2 and soft-float target features is [not supported by LLVM](rust-lang#117938 (comment)) and can crash the backend. Let's preempt that with rust-level checks. (I still think there's also an LLVM bug here, it shouldn't just SIGILL on unexpected target feature configurations, but that's a different discussion.) What is not clear to me is whether this just affects just avx2 or also avx or even sse (we don't support mmx/3dnow separately). @dianqk do you know more about this? To be safe, let's reject "sse" and therefore by implication also all other x86 vector target features. This PR turns `#[target_feature(enable = "sse")]` on a softfloat target into an FCW similar to what we do on aarch64 (see rust-lang#135160). The FCW only affects people building for soft-float targets which is a fairly small percentage of our overall users (and which means we cannot meaningfully crater this). I hence went for "report in deps" immediately so that the people building the actual binaries see these warnings that their upstreams probably will never see.
rustbot
added
A-compiletest
Member
Author
|
@bors r+ p=5 |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
rust-bors
Bot
added
the
S-waiting-on-author
Contributor
|
This pull request was unapproved due to being closed. |
rust-bors
Bot
removed
the
S-waiting-on-bors
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
r? @ghost
Create a similar rollup