`Conf` macro improvements part 2
changelog: none
Follow-up to #7150
I made the default value required again for `define_Conf!` so that it can be parsed by the magic Python. I guess it's just as well for readability.
r? `@flip1995`
MinGW driver for COFF LLD doesn't currently translate GNU-style `--threads=N` to native `/threads:N`, so we have to pass the option in its native form to avoid an error.
Also pass the `threads` flag to lld-link as well
Change librustdoc write!(.. \n) to writeln!(..); fix comment grammar
Howdy,
This PR does the following:
1. Updates the grammar of a comment in librustdoc.
2. Replaces a few write!(..\n) macros with writeln!(..\n) for clarity. (Please let me know if there is a reason why this might be wrong!)
Best,
Mautamu
parser: Remove support for inner attributes on non-block expressions
Remove support for attributes like
```rust
fn attrs() {
(#![print_target_and_args(fifth)] 1, 2);
[#![print_target_and_args(sixth)] 1 , 2];
[#![print_target_and_args(seventh)] true ; 5];
match 0 {
#![print_target_and_args(eighth)]
_ => {}
}
MyStruct { #![print_target_and_args(ninth)] field: true };
}
```
They are
- useless
- unstable (modulo holes like https://github.com/rust-lang/rust/issues/65860)
- pessimize compiler performance, namely token collection for macros (cc https://github.com/rust-lang/rust/pull/82608)
I still want to run crater on this to check whether the stability holes are exploited in practice, and whether such attributes are used at all.
Replace 'NULL' with 'null'
This replaces occurrences of "NULL" with "null" in docs, comments, and compiler error/lint messages. This is for the sake of consistency, as the lowercase "null" is already the dominant form in Rust. The all-caps NULL looks like the C macro (or SQL keyword), which seems out of place in a Rust context, given that NULL does not exist in the Rust language or standard library (instead having [`ptr::null()`](https://doc.rust-lang.org/stable/std/ptr/fn.null.html)).
Rollup of 6 pull requests
Successful merges:
- #84072 (Allow setting `target_family` to multiple values, and implement `target_family="wasm"`)
- #84744 (Add ErrorKind::OutOfMemory)
- #84784 (Add help message to suggest const for unused type param)
- #84811 (RustDoc: Fix bounds linking trait.Foo instead of traitalias.Foo)
- #84818 (suggestion for unit enum variant when matched with a patern)
- #84832 (Do not print visibility in external traits)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Do not print visibility in external traits
This PR fixes the bug that caused traits, which were re-exported, having visibility modifiers in front of methods, which is invalid.
It would be nice to add a test for this, but I don't even know if tests with multiple crates are possible.
Resolves#81274
Add ErrorKind::OutOfMemory
Ability to express `ENOMEM` as an `io::Error`.
I've used `OutOfMemory` as opposed to `NotEnoughMem` or `AllocationFailed`, because "OOM" is used in Rust already.
See also #84612
i8 and u8::to_string() specialisation (far less asm).
Take 2. Around 1/6th of the assembly to without specialisation.
https://godbolt.org/z/bzz8Mq
(partially fixes#73533 )
Fix debuginfo for generators
First, all fields except the discriminant (including `outer_fields`) should be put into structures inside the variant part, which gives an equivalent layout but offers us much better integration with debuggers.
Second, artificial flags in generator variants should be removed.
- Literally, variants are not artificial. We have `yield` statements, upvars and inner variables in the source code.
- Functionally, we don't want debuggers to suppress the variants. It contains the state of the generator, which is useful when debugging. So they shouldn't be marked artificial.
- Debuggers may use artificial flags to find the active variant. In this case, marking variants artificial will make debuggers not work properly.
Fixes#62572.
Fixes#79009.
And refer https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Debuginfo.20for.20generators.
