Repository navigation
Rollup of 3 pull requests - #164099
Merged
Merged
Rollup of 3 pull requests#164099
Conversation
This commit stabilizes the `wide-arithmetic` target feature for WebAssembly targets. This [upstream WebAssembly proposal][repo] has [now reached phase 4][phase] in the WebAssembly CG standardization process which means that it's expected to ship shortly in browsers/engines and is considered stable. This is intended to be a sibling PR to rust-lang/rust to reflect the stability of the proposal in LLVM/engines to allow users to enable this in downstream code without warnings. To recap what `wide-arithmetic` is -- this is a target feature for all WebAssembly targets for Rust. This feature corresponds to the LLVM `wide-arithmetic` target feature and gates generation of four new instructions added in the [wide-arithmetic proposal][repo], primarily centered around 128-bit addition/subtraction and a widening 64x64-bit multiply producing a 128-bit result. This target feature has no library APIs, no impact on the Rust language, nor any impact on ABIs anywhere. The only change is that more efficient codegen is generated for some operations, primarily 128-bit multiplication. Generally speaking it's expected that users should be able to enable this feature, recompile with today's source code, and see speedups if these operations are bottlenecks. This feature is off-by-default and requires `-Ctarget-feature=...` or similar to enable it. This feature will not be on-by-default for quite some time while engine support percolates and (ideally) becomes pervasive. [repo]: https://github.com/webassembly/wide-arithmetic [phase]: WebAssembly/proposals#239
…rithmetic, r=JonathanBrouwer rustc: Stabilize the WebAssembly `wide-arithmetic` feature Reference PR: - rust-lang/reference#2324 This commit stabilizes the `wide-arithmetic` target feature for WebAssembly targets. This [upstream WebAssembly proposal][repo] has [now reached phase 4][phase] in the WebAssembly CG standardization process which means that it's expected to ship shortly in browsers/engines and is considered stable. This is intended to be a sibling PR to rust-lang/rust to reflect the stability of the proposal in LLVM/engines to allow users to enable this in downstream code without warnings. To recap what `wide-arithmetic` is -- this is a target feature for all WebAssembly targets for Rust. This feature corresponds to the LLVM `wide-arithmetic` target feature and gates generation of four new instructions added in the [wide-arithmetic proposal][repo], primarily centered around 128-bit addition/subtraction and a widening 64x64-bit multiply producing a 128-bit result. This target feature has no library APIs, no impact on the Rust language, nor any impact on ABIs anywhere. The only change is that more efficient codegen is generated for some operations, primarily 128-bit multiplication. Generally speaking it's expected that users should be able to enable this feature, recompile with today's source code, and see speedups if these operations are bottlenecks. This feature is off-by-default and requires `-Ctarget-feature=...` or similar to enable it. This feature will not be on-by-default for quite some time while engine support percolates and (ideally) becomes pervasive. [repo]: https://github.com/webassembly/wide-arithmetic [phase]: WebAssembly/proposals#239 <!-- Please read our [LLM policy] before opening a PR, If you used an LLM to generate any part of this PR, including the PR description, please disclose that according to our [guidelines][disclosure guidelines]. LLM contributions are not banned, but are held to a higher standard of review and correctness. If you do not want your disclosure to be part of the permanent git history, add `<!-- homu-ignore:start` before it. [LLM policy]: https://forge.rust-lang.org/policies/llm-usage.html [disclosure guidelines]: https://rustc-dev-guide.rust-lang.org/llm-guidance/writing.html#disclosure-guidelines If this PR is related to an unstable feature or an otherwise tracked effort, please link to the relevant tracking issue here. If you don't know of a related tracking issue or there are none, feel free to ignore this. This PR will get automatically assigned to a reviewer. In case you would like a specific user to review your work, you can assign it to them by using r? <reviewer name> -->
…anBrouwer
Error on non-literal expressions in doc attributes on macro calls
Recently I discovered that, since Rust 1.94, doc attributes on macro invocations can have arbitrary expressions in them:
```rust
// accidentally stabilized in 1.94
#[doc = concat!("", "")]
#[doc = {
let a = 1;
let b = 1;
let sum = a + b;
assert_eq!(sum, 2);
}]
println!();
```
As part of the attribute parsing rework this was accidentally allowed. Note that doc attributes (or any doc comment) on macro invocations do nothing, because documentation for macro invocations is not rendered - this emits a lint saying macros must produce doc comments as part of their expansion.
With this PR, it now emits a FCW, like rust-lang#57571. As this is so niche it's probable this could go straight to an error but there's quite a crater queue so I'd rather do this now and try turning it into an error later.
```
error: invalid expression in `doc` attribute on macro invocation
--> $DIR/attr-on-mac-call.rs:115:13
|
LL | #[doc = concat!("", "")]
| --------^^^^^^^^^^^^^^^^^^^^^^^- help: remove the attribute
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue rust-lang#57571 <rust-lang#57571>
= note: `#[deny(ill_formed_attribute_input)]` (part of `#[deny(future_incompatible)]`) on by default
error: invalid expression in `doc` attribute on macro invocation
--> $DIR/attr-on-mac-call.rs:118:13
|
LL | #[doc = {
| ______- ^
| | _____________|
LL | || let a = 1;
LL | || let b = 1;
LL | || let sum = a + b;
LL | || assert_eq!(sum, 2);
LL | || }]
| ||_____^- help: remove the attribute
| |_____|
|
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue rust-lang#57571 <rust-lang#57571>
error: aborting due to 7 previous errors; 30 warnings emitted
```
Note that `#[doc = mac!()]` is included in this. While this is allowed everywhere else as normally attribute parsing only sees it after its expansion, it is not expanded here, but we do need to check attributes here since we can't check them later as they're lost by then.
```rust
#[doc = mac!()] // this would be expanded second, but any remaining attributes
// on macro invocations are dropped before they are expanded.
println!(); // this is expanded first
```
I don't think it is worth trying to make particular case work - this would involve checking that the expression would expand to a string literal:
- These expansions have a defined order (see also @petrochenkov's comment at [#t-compiler > attribute parsing rework @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/attribute.20parsing.20rework/near/615858530))
- so it would be quite a hack to check whether the expression would expand to a string literal
- changing macro expansion order might be possible but is a big can of worms and undesirable.
- it would serve no use case, as the attribute is dropped regardless
This change would also make it consistent with all other key-value attributes. For an example, the following are allowed
```rust
#[deprecated = "foo"] // just `unused_attributes` warning
println!();
#[deprecated = concat!()]
struct Foo;
```
but this is not:
```rust
#[deprecated = concat!()]
println!();
```
```
error: attribute value must be a literal
--> src/main.rs:2:20
|
2 | #[deprecated = concat!()]
```
r? @JonathanBrouwer
…nges, r=JonathanBrouwer Triagebot: Subscribe myself to AST/HIR size changes r? ghost
rustbot
added
A-attributes
Member
Author
|
@bors r+ p=5 force |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors
Bot
added
merged-by-bors
Contributor
Contributor
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 92f3cfc (parent) -> 6e4cba3 (this PR) Test differencesShow 2 test diffs2 doctest diffs were found. These are ignored, as they are noisy. Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 6e4cba3380a6f9e1e4d7672e11e40372bf04e873 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Contributor
|
📌 Perf builds for each rolled up PR:
parent commit: 92f3cfc688 In the case of a perf regression, run the following command with the SHAs of each PR you suspect might be the cause: |
Collaborator
|
Finished benchmarking commit (6e4cba3): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis perf run didn't have relevant results for this metric. Max RSS (memory usage)Results (secondary -3.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.3%, secondary -3.9%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary -0.1%, secondary -0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 488.853s -> 488.311s (-0.11%) |
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
5 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:
wide-arithmeticfeature #160877 (rustc: Stabilize the WebAssemblywide-arithmeticfeature)r? @ghost
Create a similar rollup