Rollup of 7 pull requests #127956
Merged
Rollup of 7 pull requests #127956
Conversation
This file contains 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
…teral
```
error[E0533]: expected value, found struct variant `E::Empty3`
--> $DIR/empty-struct-braces-expr.rs:18:14
|
LL | let e3 = E::Empty3;
| ^^^^^^^^^ not a value
|
help: you might have meant to create a new value of the struct
|
LL | let e3 = E::Empty3 {};
| ++
```
```
error[E0533]: expected value, found struct variant `E::V`
--> $DIR/struct-literal-variant-in-if.rs:10:13
|
LL | if x == E::V { field } {}
| ^^^^ not a value
|
help: you might have meant to create a new value of the struct
|
LL | if x == (E::V { field }) {}
| + +
```
```
error[E0618]: expected function, found enum variant `Enum::Unit`
--> $DIR/suggestion-highlights.rs:15:5
|
LL | Unit,
| ---- enum variant `Enum::Unit` defined here
...
LL | Enum::Unit();
| ^^^^^^^^^^--
| |
| call expression requires function
|
help: `Enum::Unit` is a unit enum variant, and does not take parentheses to be constructed
|
LL - Enum::Unit();
LL + Enum::Unit;
|
```
```
error[E0599]: no variant or associated item named `tuple` found for enum `Enum` in the current scope
--> $DIR/suggestion-highlights.rs:36:11
|
LL | enum Enum {
| --------- variant or associated item `tuple` not found for this enum
...
LL | Enum::tuple;
| ^^^^^ variant or associated item not found in `Enum`
|
help: there is a variant with a similar name
|
LL | Enum::Tuple(/* i32 */);
| ~~~~~~~~~~~~~~~~;
|
```
…le struct type
```
error[E0560]: struct `S` has no field named `x`
--> $DIR/nested-non-tuple-tuple-struct.rs:8:19
|
LL | pub struct S(f32, f32);
| - `S` defined here
...
LL | let _x = (S { x: 1.0, y: 2.0 }, S { x: 3.0, y: 4.0 });
| ^ field does not exist
|
help: `S` is a tuple struct, use the appropriate syntax
|
LL | let _x = (S(/* f32 */, /* f32 */), S { x: 3.0, y: 4.0 });
| ~~~~~~~~~~~~~~~~~~~~~~~
```
In <rust-lang#126922>, the `binary_asm_labels` lint was added which flags labels such as `0:` and `1:`. Before that change, LLVM was giving a confusing error on x86/x86_64 because of an incorrect interpretation. However, targets other than x86 and x86_64 never had the error message and have not been a problem. This means that the lint was causing code that previously worked to start failing (e.g. `compiler_builtins`), rather than only providing a more clear messages where there has always been an error. Adjust the lint to only fire on x86 and x86_64 assembly to avoid this regression.
The link pointed to a closed issue. Create a new one and point the link to it. Also add a help message to hint what change the user could make. Fixes: rust-lang#127821
The `Option`s within the `ReplaceRange`s within the hashmap are always `None`. This PR omits them and inserts them when they are extracted from the hashmap.
It's no shorter than `ret.attrs()`, and `ret.attrs()` is used multiple times earlier in the function.
This puts it just before the `replace_ranges` initialization, which makes sense because the two variables are closely related.
Currently in `collect_tokens_trailing_token`, `start_pos` and `end_pos` are 1-indexed by `replace_ranges` is 0-indexed, which is really confusing. Making them both 0-indexed makes debugging much easier.
Adding details, clarifying lots of little things, etc. In particular, the commit adds details of an example. I find this very helpful, because it's taken me a long time to understand how this code works.
Disable a test that now only passes on x86 and make the link point to the new (open) LLVM bug.
…ethercote Handle .init_array link_section specially on wasm Given that wasm-ld now has support for [.init_array](https://github.com/llvm/llvm-project/blob/8f2bd8ae68883592a333f4bdbed9798d66e68630/llvm/lib/MC/WasmObjectWriter.cpp#L1852), it appears we can easily implement that section by falling through to the normal path rather than taking the typical custom_section path for wasm. The wasm-ld appears to have a bunch of limitations. Only one static with the `link_section` in a crate or else you hit the fatal error in the link above "only one .init_array section fragment supported". They do not get merged. You can still call multiple constructors by setting it to an array. ``` unsafe extern "C" fn ctor() { println!("foo"); } #[used] #[link_section = ".init_array"] static FOO: [unsafe extern "C" fn(); 2] = [ctor, ctor]; ``` Another issue appears to be that if crate *A* depends on crate *B*, but *A* doesn't call any symbols from *B* and *B* doesn't `#[export_name = ...]` any symbols, then crate *B*'s constructor will not be called. The workaround to this is to provide an exported symbol in crate *B*.
Migrate `macos-fat-archive`, `manual-link` and `archive-duplicate-names` `run-make` tests to rmake Part of rust-lang#121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html). Please try: try-job: x86_64-msvc try-job: aarch64-apple
Tweak suggestions when using incorrect type of enum literal
More accurate suggestions when writing wrong style of enum variant literal:
```
error[E0533]: expected value, found struct variant `E::Empty3`
--> $DIR/empty-struct-braces-expr.rs:18:14
|
LL | let e3 = E::Empty3;
| ^^^^^^^^^ not a value
|
help: you might have meant to create a new value of the struct
|
LL | let e3 = E::Empty3 {};
| ++
```
```
error[E0533]: expected value, found struct variant `E::V`
--> $DIR/struct-literal-variant-in-if.rs:10:13
|
LL | if x == E::V { field } {}
| ^^^^ not a value
|
help: you might have meant to create a new value of the struct
|
LL | if x == (E::V { field }) {}
| + +
```
```
error[E0618]: expected function, found enum variant `Enum::Unit`
--> $DIR/suggestion-highlights.rs:15:5
|
LL | Unit,
| ---- enum variant `Enum::Unit` defined here
...
LL | Enum::Unit();
| ^^^^^^^^^^--
| |
| call expression requires function
|
help: `Enum::Unit` is a unit enum variant, and does not take parentheses to be constructed
|
LL - Enum::Unit();
LL + Enum::Unit;
|
```
```
error[E0599]: no variant or associated item named `tuple` found for enum `Enum` in the current scope
--> $DIR/suggestion-highlights.rs:36:11
|
LL | enum Enum {
| --------- variant or associated item `tuple` not found for this enum
...
LL | Enum::tuple;
| ^^^^^ variant or associated item not found in `Enum`
|
help: there is a variant with a similar name
|
LL | Enum::Tuple(/* i32 */);
| ~~~~~~~~~~~~~~~~;
|
```
Tweak "field not found" suggestion when giving struct literal for tuple struct type:
```
error[E0560]: struct `S` has no field named `x`
--> $DIR/nested-non-tuple-tuple-struct.rs:8:19
|
LL | pub struct S(f32, f32);
| - `S` defined here
...
LL | let _x = (S { x: 1.0, y: 2.0 }, S { x: 3.0, y: 4.0 });
| ^ field does not exist
|
help: `S` is a tuple struct, use the appropriate syntax
|
LL | let _x = (S(/* f32 */, /* f32 */), S { x: 3.0, y: 4.0 });
| ~~~~~~~~~~~~~~~~~~~~~~~
…g_token-cleanups, r=petrochenkov `collect_tokens_trailing_token` cleanups More cleanups I made while understanding the code for processing `cfg_attr`, to fix test failures in rust-lang#124141. r? `@petrochenkov`
…bzol Migrate `lto-smoke-c` and `link-path-order` `run-make` tests to rmake Part of rust-lang#121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
…y, r=estebank,Urgau Change `binary_asm_labels` to only fire on x86 and x86_64 In <rust-lang#126922>, the `binary_asm_labels` lint was added which flags labels such as `0:` and `1:`. Before that change, LLVM was giving a confusing error on x86/x86_64 because of an incorrect interpretation. However, targets other than x86 and x86_64 never had the error message and have not been a problem. This means that the lint was causing code that previously worked to start failing (e.g. `compiler_builtins`), rather than only providing a more clear messages where there has always been an error. Adjust the lint to only fire on x86 and x86_64 assembly to avoid this regression. Also update the help message. Fixes: rust-lang#127821
… r=jieyouxu [compiletest] Search *.a when getting dynamic libraries on AIX AIX uses `.a` as dylib suffix. Support it in compiletest.
rustbot
added
A-run-make
rustbot
added
T-bootstrap
|
@bors r+ rollup=never There are a few rollup=never jobs waiting, I won't bump this rollup's priority until the next one gets picked up |
bors
added
S-waiting-on-bors
|
@bors p=10 |
|
@bors p=7 |
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 8c3a94a1c7 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Jul 19, 2024
|
Finished benchmarking commit (11e5724): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 770.782s -> 769.908s (-0.11%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
macos-fat-archive,manual-linkandarchive-duplicate-namesrun-maketests to rmake #127825 (Migratemacos-fat-archive,manual-linkandarchive-duplicate-namesrun-maketests to rmake)collect_tokens_trailing_tokencleanups #127902 (collect_tokens_trailing_tokencleanups)lto-smoke-candlink-path-orderrun-maketests to rmake #127928 (Migratelto-smoke-candlink-path-orderrun-maketests to rmake)binary_asm_labelsto only fire on x86 and x86_64 #127935 (Changebinary_asm_labelsto only fire on x86 and x86_64)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup