rustc: Lower link args to `@`-files on Windows more
When spawning a linker rustc has historically been known to blow OS limits for
the command line being too large, notably on Windows. This is especially true of
incremental compilation where there can be dozens of object files per
compilation. The compiler currently has logic for detecting a failure to spawn
and instead passing arguments via a file instead, but this failure detection
only triggers if a process actually fails to spawn.
Unfortunately on Windows we've got something else to worry about which is
`cmd.exe`. The compiler may be running a linker through `cmd.exe` where
`cmd.exe` has a limit of 8192 on the command line vs 32k on `CreateProcess`.
Moreso rustc actually succeeds in spawning `cmd.exe` today, it's just that after
it's running `cmd.exe` fails to spawn its child, which rustc doesn't currently
detect.
Consequently this commit updates the logic for the spawning the linker on
Windows to instead have a heuristic to see if we need to pass arguments via a
file. This heuristic is an overly pessimistic and "inaccurate" calculation which
just calls `len` on a bunch of `OsString` instances (where `len` is not
precisely the length in u16 elements). This number, when exceeding the 6k
threshold, will force rustc to always pass arguments through a file.
This strategy should avoid us trying to parse the output on Windows of the
linker to see if it successfully spawned yet failed to actually sub-spawn the
linker. We may just be passing arguments through files a little more commonly
now...
The motivation for this commit was a recent bug in Gecko [1] when beta testing,
notably when incremental compilation was enabled it blew out the limit on
`cmd.exe`. This commit will also fix#46999 as well though as emscripten uses a
bat script as well (and we're blowing the limit there).
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1430886Closes#46999
renumber regions in generators
This fixes#47189, but I think we still have to double check various things around how to treat generators in MIR type check + borrow check (e.g., what borrows should be invalidated by a `Suspend`? What consistency properties should type check be enforcing anyway around the "interior" type?)
Also fixes#47587 thanks to @spastorino's commit.
r? @pnkfelix
Implement repr(transparent)
r? @eddyb for the functional changes. The bulk of the PR is error messages and docs, might be good to have a doc person look over those.
cc #43036
cc @nox
Custom error when moving arg outside of its closure
When given the following code:
```rust
fn give_any<F: for<'r> FnOnce(&'r ())>(f: F) {
f(&());
}
fn main() {
let mut x = None;
give_any(|y| x = Some(y));
}
```
provide a custom error:
```
error: borrowed data cannot be moved outside of its closure
--> file.rs:7:27
|
6 | let mut x = None;
| ----- borrowed data cannot be moved into here...
7 | give_any(|y| x = Some(y));
| --- ^ cannot be moved outside of its closure
| |
| ...because it cannot outlive this closure
```
instead of the generic lifetime error:
```
error[E0495]: cannot infer an appropriate lifetime due to conflicting requirements
--> file.rs:7:27
|
7 | give_any(|y| x = Some(y));
| ^
|
note: first, the lifetime cannot outlive the anonymous lifetime #2 defined on the body at 7:14...
--> file.rs:7:14
|
7 | give_any(|y| x = Some(y));
| ^^^^^^^^^^^^^^^
note: ...so that expression is assignable (expected &(), found &())
--> file.rs:7:27
|
7 | give_any(|y| x = Some(y));
| ^
note: but, the lifetime must be valid for the block suffix following statement 0 at 6:5...
--> file.rs:6:5
|
6 | / let mut x = None;
7 | | give_any(|y| x = Some(y));
8 | | }
| |_^
note: ...so that variable is valid at time of its declaration
--> file.rs:6:9
|
6 | let mut x = None;
| ^^^^^
```
Fix#45983.
When spawning a linker rustc has historically been known to blow OS limits for
the command line being too large, notably on Windows. This is especially true of
incremental compilation where there can be dozens of object files per
compilation. The compiler currently has logic for detecting a failure to spawn
and instead passing arguments via a file instead, but this failure detection
only triggers if a process actually fails to spawn.
Unfortunately on Windows we've got something else to worry about which is
`cmd.exe`. The compiler may be running a linker through `cmd.exe` where
`cmd.exe` has a limit of 8192 on the command line vs 32k on `CreateProcess`.
Moreso rustc actually succeeds in spawning `cmd.exe` today, it's just that after
it's running `cmd.exe` fails to spawn its child, which rustc doesn't currently
detect.
Consequently this commit updates the logic for the spawning the linker on
Windows to instead have a heuristic to see if we need to pass arguments via a
file. This heuristic is an overly pessimistic and "inaccurate" calculation which
just calls `len` on a bunch of `OsString` instances (where `len` is not
precisely the length in u16 elements). This number, when exceeding the 6k
threshold, will force rustc to always pass arguments through a file.
This strategy should avoid us trying to parse the output on Windows of the
linker to see if it successfully spawned yet failed to actually sub-spawn the
linker. We may just be passing arguments through files a little more commonly
now...
The motivation for this commit was a recent bug in Gecko [1] when beta testing,
notably when incremental compilation was enabled it blew out the limit on
`cmd.exe`. This commit will also fix#46999 as well though as emscripten uses a
bat script as well (and we're blowing the limit there).
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1430886Closes#46999
Tweaks to invalid ctor messages
- Do not suggest using a constructor that isn't accessible
- Suggest the appropriate syntax (`()`/`{}` as appropriate)
- Add note when trying to use `Self` as a ctor
CC #22488, fix#47085.
check_match: fix handling of privately uninhabited types
the match-checking code used to use TyErr for signaling "unknown,
inhabited" types for a long time. It had been switched to using the
exact type in #38069, to handle uninhabited types.
However, in #39980, we discovered that we still needed the "unknown
inhabited" logic, but I used `()` instead of `TyErr` to handle that.
Revert to using `TyErr` to fix that problem.
Fixes#46964.
r? @nikomatsakis
remove bogus assertion and comments
The code (incorrectly) assumed that constants could not have generics
in scope, but it's not really a problem if they do.
Fixes#47153
r? @pnkfelix
Closure argument mismatch tweaks
- use consistent phrasing for expected and found arguments
- suggest changing arguments to tuple if possible
- suggest changing single tuple argument to arguments if possible
Fix#44150.
Add transpose conversions for nested Option and Result
These impls are useful when working with combinator
methods that expect an option or a result, but you
have a `Result<Option<T>, E>` instead of an `Option<Result<T, E>>`
or vice versa.
Thew `_raw` prefix is included because the fact that `Box`’s ownership
semantics are "dissolved" or recreated seem more important than the exact
parameter type or return type.
- use consistent phrasing for expected and found arguments
- suggest changing arugments to tuple if possible
- suggest changing single tuple argument to arguments if possible
avoid double-unsizing arrays in bytestring match lowering
The match lowering code, when lowering matches against bytestrings,
works by coercing both the scrutinee and the pattern to `&[u8]` and
then comparing them using `<[u8] as Eq>::eq`.
If the scrutinee is already of type `&[u8]`, then unsizing it is both
unneccessary and a trait error caught by the new and updated MIR typeck,
so this PR changes lowering to avoid doing that (match lowering tried to
avoid that before, but that attempt was quite broken).
Fixes#46920.
r? @eddyb
Don't include DefIndex in proc-macro registrar function symbol.
There can only ever be one registrar function per plugin or proc-macro crate, so adding the `DefIndex` to the function's symbol name does not serve a real purpose. Remove the `DefIndex` from the symbol name makes it stable across incremental compilation sessions.
This should fix issue #47292.
On E0283, point at method with the requirements
On required type annotation diagnostic error, point at method with the
requirements if the span is available.
CC #45453.
rustdoc: Populate external_traits with traits only seen in impls
This means default methods can always be found and "Important traits" will include all spotlight traits.
Test rustdoc js
Add tests for the rustdoc search. It was heavily required because of all the recent breaking changes that happened while I went through improvements in doc search (add search in/for generic search for example).
Point at unused arguments for format string
Avoid overlapping spans by only pointing at the arguments that are not
being used in the argument string. Enable libsyntax to have diagnostics
with multiple primary spans by accepting `Into<MultiSpan>` instead of
`Span`.
Partially addresses #41850.
private no-mangle lints: only suggest `pub` if it doesn't already exist
Fixes#47383 (function or static can be `pub` but unreachable because it's in a private module; adding another `pub` is nonsensical).
r? @estebank
remove noop landing pads in cleanup shims
No-op landing pads are already removed in the normal optimization pipeline - so also removing them on the shim pipeline should slightly improve codegen performance, as these cleanup blocks are known to hurt LLVM.
This un-regresses and is therefore a fix for #47442. However, the reporter of that issue should try using `-C panic=abort` instead of carefully avoiding panics.
r? @eddyb
Don't include bang in macro replacement suggestion
When we suggest the replacement for a macro we include the "!" in the suggested replacement but the span only contains the name of the macro itself. Using that replacement would cause a duplicate "!" in the resulting code.
I originally tried to extend the span to be replaced by 1 byte in rust-lang/rust#47424. However, @zackmdavis pointed out that there can be whitespace between the macro name and the bang.
Instead, just remove the bang from the suggested replacement.
Fixes#47418
r? @estebank
fix mispositioned span
This fixes#47377
The output now looks like this
```
error[E0369]: binary operation `+` cannot be applied to type `&str`
--> h.rs:3:11
|
3 | let _a = b + ", World!";
| ^^^^^^^^^^^^^^ `+` can't be used to concatenate two `&str` strings
help: `to_owned()` can be used to create an owned `String` from a string reference. String concatenation appends the string on the right to the string on the left and may require reallocation. This requires ownership of the string on the left
|
3 | let _a = b.to_owned() + ", World!";
| ^^^^^^^^^
error: aborting due to previous error
```
For the case when emojis are involved, it gives the new output for proper indentation.
But for an indentation as follows,
```
fn main() {
let b = "hello";
let _a = b + ", World!";
}
```
it still mispositions the span
```
3 | println!("🦀🦀🦀🦀🦀"); let _a = b + ", World!";
| ^^^^^^^^^^^^^^ `+` can't be used to concatenate two `&str` strings
|
3 | println!("🦀🦀🦀🦀🦀"); let _a = b.to_owned() + ", World!";
| ^^^^^^^
error: aborting due to previous erro
```
cc @estebank @est31
The match lowering code, when lowering matches against bytestrings,
works by coercing both the scrutinee and the pattern to `&[u8]` and
then comparing them using `<[u8] as Eq>::eq`.
If the scrutinee is already of type `&[u8]`, then unsizing it is both
unneccessary and a trait error caught by the new and updated MIR typeck,
so this PR changes lowering to avoid doing that (match lowering tried to
avoid that before, but that attempt was quite broken).
Fixes#46920.
