Account for version number in NtIdent hack
Issue #74616 tracks a backwards-compatibility hack for certain macros.
This has is implemented by hard-coding the filenames and macro names of
certain code that we want to continue to compile.
However, the initial implementation of the hack was based on the
directory structure when building the crate from its repository (e.g.
`js-sys/src/lib.rs`). When the crate is build as a dependency, it will
include a version number from the clone from the cargo registry (e.g.
`js-sys-0.3.17/src/lib.rs`), which would fail the check.
This commit modifies the backwards-compatibility hack to check that
desired crate name (`js-sys` or `time-macros-impl`) is a prefix of the
proper part of the path.
See https://github.com/rust-lang/rust/issues/76070#issuecomment-687215646
for more details.
Disable use of `--eh-frame-hdr` on wasm32.
Set wasm32's `TargetOptions::eh_frame_header` to false so that we don't pass `--eh-frame-hdr` to `wasm-ld`, which doesn't support that flag.
r? @alexcrichton
CDB doesn't care that you're using static_cast between unrelated types.
VS(C) does. These should've been reinterpret_cast or C casts.
Cast is from e.g. `u8*` to `tuple<$T1, $T2>*`
rename MaybeUninit slice methods
The `first` methods conceptually point to the whole slice, not just its first element, so rename them to be consistent with the raw ptr methods on ref-slices.
Also, do the equivalent of https://github.com/rust-lang/rust/pull/76047 for the slice reference getters, and make them part of https://github.com/rust-lang/rust/issues/63569 (so far they somehow had no tracking issue).
* first_ptr -> slice_as_ptr
* first_ptr_mut -> slice_as_mut_ptr
* slice_get_ref -> slice_assume_init_ref
* slice_get_mut -> slice_assume_init_mut
Fix FP in `same_item_push`
Don't emit a lint when the pushed item doesn't have Clone trait
Fix#5979
changelog: Fix FP in `same_item_push` not to emit a lint when the pushed item doesn't have Clone trait
I believe the documentation is currently a little misleading.
For example, in the docs for `filter()`:
> If the closure returns `false`, it will try again, and call the closure on
> the next element, seeing if it passes the test.
This kind of implies that if the closure returns true then we *don't* "try
again" and no further elements are considered. In actuality that's not the
case, every element is tried regardless of what happened with the previous
element.
This change tries to clarify that by removing the uses of "try again"
altogether.
Previously, this called `check_full_res` for values and types, but not
macros. This would result in not showing when there was a partial
resolution for a parent of the item.
This now calls `check_full_res`. Additionally, it checks if there was a
disambiguator, and if so, says that specific kind wasn't found instead
of saying generically 'associated item'.
Before:
```
warning: unresolved link to `m`
--> m.rs:1:6
|
1 | /// [value@m]
| ^^^^^^^
|
= note: `#[warn(broken_intra_doc_links)]` on by default
= note: no item named `m` is in scope
= help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`
```
After:
```
warning: unresolved link to `m`
--> m.rs:1:6
|
1 | /// [value@m]
| ^^^^^^^ help: to link to the macro, use its disambiguator: `m!`
|
= note: `#[warn(broken_intra_doc_links)]` on by default
= note: this link resolves to the macro `m`, which is not in the value namespace
```
Previously, when looking for the associated items for primitives,
rustdoc would look for primitives in the current namespace.
But all primitives are in the type namespace. To fix this, rustdoc now
always looks for primitives in the namespace when considering them as a
stepping stone to the associated item.
However, fixing that bug caused several duplicate errors because rustdoc
now reports the same error in each namespace. To avoid this, rustdoc now
ignores all duplicate errors when issuing them.
Before:
```
= note: this link partially resolves to the struct `S`
= note: no `fmt` in `S`
```
After:
```
= note: the struct `S` has no field or associated item named `fmt`
```
Look at this beauty:
```rust
error: unresolved link to `S::h`
--> intra-link-errors.rs:51:6
|
51 | /// [type@S::h]
| ^^^^^^^^^ help: to link to the associated function, use its disambiguator: `S::h()`
|
= note: this link resolves to the associated function `h`, which is not in the type namespace
```
