Use `LocalDefId` instead of `NodeId` in `resolve_str_path_error`
Together with https://github.com/rust-lang/rust/pull/72777 this should remove all uses of `NodeId` in `rustdoc`.
cc #50928
r? @petrochenkov
Update the Fuchsia linker defaults
This updates the linker defaults aligning them with Clang. Specifically,
we use 4K pages on all platforms, we always use BIND_NOW, we prefer all
loadable segments be separate and page aligned, and we support RELR
relocations.
rustdoc: remove calls to `local_def_id_from_node_id`
rustdoc calls `local_def_id_from_node_id(CRATE_NODE_ID)` when it can just creates a top level `DefId` using `DefId::local(CRATE_DEF_INDEX)`.
cc #50928
r? @petrochenkov
Fix is_char_boundary documentation
Given the "start _and/or end_" wording in the original, the way I understood it was that the `str::is_char_boundary` method would also return `true` for the last byte in a UTF-8 code point sequence. (Which would have meant that for a string consisting of nothing but 1 and 2 byte UTF-8 code point sequences, it would return nothing but `true`.)
In practice the method returns `true` only for the starting byte of each sequence and the end of the string: [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e9f5fc4d6bf2f1bf57a75f3c9a180770)
I was also somewhat tempted to remove the _The start and end of the string are considered to be boundaries_, since that's implied by the first sentence, but I decided to avoid bikeshedding over it and left it as it was since it's not wrong in relation to how the method behaves.
miri validation: clarify valid values of 'char'
The old text said "expected a valid unicode codepoint", which is not actually correct -- it has to be a scalar value (which is a code point that is not part of a surrogate pair).
rustc_lexer: Optimize shebang detection slightly
Sorry, I just couldn't resist.
It shouldn't make any difference in practice.
Also, documented a previously unnoticed case with doc comments treated as regular comments during shebang detection.
Fix missing parentheses Fn notation error
Fixes #72611
Well, fixes the error output, I think E0658 is the right error to throw in this case so I didn't change that
Add -Z profile-emit=<path> for Gcov gcda output.
Adds a -Z flag to control the file path that the Gcov gcda output is
written to during runtime. This flag expects a path and filename, e.g.
-Z profile-emit=gcov/out/lib.gcda.
This works similar to GCC/Clang's -fprofile-dir flag which allows
control over the output path for gcda coverage files.
Allow types (with lifetimes/generics) in impl_lint_pass
cc https://github.com/rust-lang/rust-clippy/pull/5279#discussion_r430790267
This allows to implement `LintPass` for types with lifetimes and/or generics. The only thing, I'm not sure of is the `LintPass::name` function, which now includes the lifetime(s) (which will be `'_` most of the time) in the name returned for the lint pass, if it exists. But I don't think that this should be a problem, since the `LintPass::name` is never used for output for the user (?).
Improve inline asm error diagnostics
Previously we were just using the raw LLVM error output (with line, caret, etc) as the diagnostic message, which ends up looking rather out of place with our existing diagnostics.
The new diagnostics properly format the diagnostics and also take advantage of LLVM's per-line `srcloc` attribute to map an error in inline assembly directly to the relevant line of source code.
Incidentally also fixes#71639 by disabling `srcloc` metadata during LTO builds since we don't know what crate it might have come from. We can only resolve `srcloc`s from the currently crate since it indexes into the source map for the current crate.
Fixes#72664Fixes#71639
r? @petrochenkov
### Old style
```rust
#![feature(llvm_asm)]
fn main() {
unsafe {
let _x: i32;
llvm_asm!(
"mov $0, $1
invalid_instruction $0, $1
mov $0, $1"
: "=&r" (_x)
: "r" (0)
:: "intel"
);
}
}
```
```
error: <inline asm>:3:14: error: invalid instruction mnemonic 'invalid_instruction'
invalid_instruction ecx, eax
^~~~~~~~~~~~~~~~~~~
--> src/main.rs:6:9
|
6 | / llvm_asm!(
7 | | "mov $0, $1
8 | | invalid_instruction $0, $1
9 | | mov $0, $1"
... |
12 | | :: "intel"
13 | | );
| |__________^
```
### New style
```rust
#![feature(asm)]
fn main() {
unsafe {
asm!(
"mov {0}, {1}
invalid_instruction {0}, {1}
mov {0}, {1}",
out(reg) _,
in(reg) 0i64,
);
}
}
```
```
error: invalid instruction mnemonic 'invalid_instruction'
--> test.rs:7:14
|
7 | invalid_instruction {0}, {1}
| ^
|
note: instantiated into assembly here
--> <inline asm>:3:14
|
3 | invalid_instruction rax, rcx
| ^^^^^^^^^^^^^^^^^^^
```
Account for missing lifetime in opaque and trait object return types
When encountering an opaque closure return type that needs to bound a
lifetime to the function's arguments, including borrows and type params,
provide appropriate suggestions that lead to working code.
Get the user from
```rust
fn foo<G, T>(g: G, dest: &mut T) -> impl FnOnce()
where
G: Get<T>
{
move || {
*dest = g.get();
}
}
```
to
```rust
fn foo<'a, G: 'a, T>(g: G, dest: &'a mut T) -> impl FnOnce() +'a
where
G: Get<T>
{
move || {
*dest = g.get();
}
}
```
When encountering an opaque closure return type that needs to bound a
lifetime to the function's arguments, including borrows and type params,
provide appropriate suggestions that lead to working code.
Get the user from
```rust
fn foo<G, T>(g: G, dest: &mut T) -> impl FnOnce()
where
G: Get<T>
{
move || {
*dest = g.get();
}
}
```
to
```rust
fn foo<'a, G: 'a, T>(g: G, dest: &'a mut T) -> impl FnOnce() +'a
where
G: Get<T>
{
move || {
*dest = g.get();
}
}
```
multiple Return terminators are possible
@ecstatic-morse mentioned in https://github.com/rust-lang/rust/issues/72515 that multiple `Return` terminators are possible. Update the docs accordingly.
Cc @rust-lang/wg-mir-opt
mir: adjust conditional in recursion limit check
Fixes#67552.
This PR adjusts the condition used in the recursion limit check of
the monomorphization collector, from `>` to `>=`.
In #67552, the test case had infinite indirect recursion, repeating a
handful of functions (from the perspective of the monomorphization
collector): `rec` -> `identity` -> `Iterator::count` -> `Iterator::fold`
-> `Iterator::next` -> `rec`.
During this process, `resolve_associated_item` was invoked for
`Iterator::fold` (during the construction of an `Instance`), and
ICE'd due to substitutions needing inference. However, previous
iterations of this recursion would have called this function for
`Iterator::fold` - and did! - and succeeded in doing so (trivially
checkable from debug logging, `()` is present where `_` is in the substs
of the failing execution).
The expected outcome of this test case would be a recursion limit error
(which is present when the `identity` fn indirection is removed), and
the recursion depth of `rec` is increasing (other functions finish
collecting their neighbours and thus have their recursion depths reset).
When the ICE occurs, the recursion depth of `rec` is 256 (which matches
the recursion limit), which suggests perhaps that a different part of
the compiler is using a `>=` comparison and returning a different result
on this recursion rather than what it returned in every previous
recursion, thus stopping the monomorphization collector from reporting
an error on the next recursion, where `recursion_depth_of_rec > 256`
would have been true.
With grep and some educated guesses, we can determine that
the recursion limit check at line 818 in
`src/librustc_trait_selection/traits/project.rs` is the other check that
is using a different comparison. Modifying either comparison to be `>` or
`>=` respectively will fix the error, but changing the monomorphization
collector produces the nicer error.
