Matthias Krüger [Mon, 27 Jun 2022 06:06:46 +0000 (08:06 +0200)]
Rollup merge of #97780 - compiler-errors:field-wfcheck-before-sized, r=jackh726
Check ADT field is well-formed before checking it is sized
Fixes #96810.
There is one diagnostics regression, in [`src/test/ui/generic-associated-types/bugs/issue-80626.stderr`](https://github.com/rust-lang/rust/pull/97780/files#diff-53795946378e78a0af23a10277c628ff79091c18090fdc385801ee70c1ba6963). I am not super concerned about it, since it's GAT related.
We _could_ fix it, possibly by using the `FieldSized` obligation cause code instead of `BuiltinDerivedObligation`. But that would require changing `Sized` trait confirmation and the `adt_sized_constraint` query.
Before this change, the compiler suggests the failure ordering is too strong and suggests choosing a weaker ordering. After this change, it instead suggests the success ordering is not strong enough, and suggests chosing a stronger one. This is more likely to be correct.
Also, before this change, the compiler suggested downgrading an invalid AcqRel failure ordering to Relaxed, without mentioning Acquire as an option.
bors [Sun, 26 Jun 2022 21:28:24 +0000 (21:28 +0000)]
Auto merge of #98187 - mystor:fast_span_call_site, r=eddyb
proc_macro/bridge: cache static spans in proc_macro's client thread-local state
This is the second part of https://github.com/rust-lang/rust/pull/86822, split off as requested in https://github.com/rust-lang/rust/pull/86822#pullrequestreview-1008655452. This patch removes the RPC calls required for the very common operations of `Span::call_site()`, `Span::def_site()` and `Span::mixed_site()`.
Some notes:
This part is one of the ones I don't love as a final solution from a design standpoint, because I don't like how the spans are serialized immediately at macro invocation. I think a more elegant solution might've been to reserve special IDs for `call_site`, `def_site`, and `mixed_site` at compile time (either starting at 1 or from `u32::MAX`) and making reading a Span handle automatically map these IDs to the relevant values, rather than doing extra serialization.
This would also have an advantage for potential future work to allow `proc_macro` to operate more independently from the compiler (e.g. to reduce the necessity of `proc-macro2`), as methods like `Span::call_site()` could be made to function without access to the compiler backend.
That was unfortunately tricky to do at the time, as this was the first part I wrote of the patches. After the later part (#98188, #98189), the other uses of `InternedStore` are removed meaning that a custom serialization strategy for `Span` is easier to implement.
If we want to go that path, we'll still need the majority of the work to split the bridge object and introduce the `Context` trait for free methods, and it will be easier to do after `Span` is the only user of `InternedStore` (after #98189).
bors [Sun, 26 Jun 2022 19:02:00 +0000 (19:02 +0000)]
Auto merge of #98545 - matthiaskrgr:rollup-njely29, r=matthiaskrgr
Rollup of 11 pull requests
Successful merges:
- #97140 (std: use an event-flag-based thread parker on SOLID)
- #97295 ([rustc_parse] Forbid `let`s in certain places)
- #97743 (make const_err show up in future breakage reports)
- #97908 (Stabilize NonZero* checked operations constness.)
- #98297 (Transform help popup into a pocket menu)
- #98428 (macros: use typed identifiers in diag and subdiag derive)
- #98528 (Respect --color when building rustbuild itself)
- #98535 (Add regression test for generic const in rustdoc)
- #98538 (Add a ui test for issue #91883)
- #98540 (Add regression test for #87558)
- #98541 (Update `std::alloc::System` doc example code style)
Matthias Krüger [Sun, 26 Jun 2022 17:47:04 +0000 (19:47 +0200)]
Rollup merge of #98428 - davidtwco:translation-derive-typed-identifiers, r=oli-obk
macros: use typed identifiers in diag and subdiag derive
Using typed identifiers instead of strings with the Fluent identifiers in the diagnostic and subdiagnostic derives - this enables the diagnostic derive to benefit from the compile-time validation that comes with typed identifiers, namely that use of a non-existent Fluent identifier will not compile.
Matthias Krüger [Sun, 26 Jun 2022 17:47:01 +0000 (19:47 +0200)]
Rollup merge of #97743 - RalfJung:const-err-future-breakage, r=estebank
make const_err show up in future breakage reports
As tracked in https://github.com/rust-lang/rust/issues/71800, const_err should become a hard error Any Day Now (TM). I'd love to move forward with that sooner rather than later; it has been deny-by-default for many years and a future incompat lint since https://github.com/rust-lang/rust/pull/80394 (landed more than a year ago). Some CTFE errors are already hard errors since https://github.com/rust-lang/rust/pull/86194. But before we truly make it a hard error in all cases, we now have one more intermediate step we can take -- to make it show up in future breakage reports.
Matthias Krüger [Sun, 26 Jun 2022 17:47:00 +0000 (19:47 +0200)]
Rollup merge of #97295 - c410-f3r:yet-another-let-chain, r=compiler-errors
[rustc_parse] Forbid `let`s in certain places
Currently only forbids in locals to resolve https://github.com/rust-lang/rust/pull/94927#issuecomment-1099605024 but feel free to point any other places.
Matthias Krüger [Sun, 26 Jun 2022 17:46:59 +0000 (19:46 +0200)]
Rollup merge of #97140 - joboet:solid_parker, r=m-ou-se
std: use an event-flag-based thread parker on SOLID
`Mutex` and `Condvar` are being replaced by more efficient implementations, which need thread parking themselves (see #93740). Therefore, the generic `Parker` needs to be replaced on all platforms where the new lock implementation will be used, which, after #96393, are SOLID, SGX and Hermit (more PRs coming soon).
SOLID, conforming to the [μITRON specification](http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf), has event flags, which are a thread parking primitive very similar to `Parker`. However, they do not make any atomic ordering guarantees (even though those can probably be assumed) and necessitate a system call even when the thread token is already available. Hence, this `Parker`, like the Windows parker, uses an extra atomic state variable.
I future-proofed the code by wrapping the event flag in a `WaitFlag` structure, as both SGX and Hermit can share the Parker implementation, they just have slightly different primitives (SGX uses signals and Hermit has a thread blocking API).
`````@kawadakk````` I assume you are the target maintainer? Could you test this for me?
bors [Sun, 26 Jun 2022 12:16:10 +0000 (12:16 +0000)]
Auto merge of #98518 - RalfJung:miri, r=RalfJung
update Miri
Fixes https://github.com/rust-lang/rust/issues/98493 (this is a flaky test, that's why the toolstate already says Miri is fixed)
r? `@ghost` Cc `@rust-lang/miri`
bors [Sun, 26 Jun 2022 07:12:16 +0000 (07:12 +0000)]
Auto merge of #98521 - JohnTitor:rollup-tl9sblx, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #98371 (Fix printing `impl trait` under binders)
- #98385 (Work around llvm 12's memory ordering restrictions.)
- #98474 (x.py: Support systems with only `python3` not `python`)
- #98488 (Bump RLS to latest master on rust-lang/rls)
- #98491 (Fix backtrace UI test when panic=abort is used)
- #98502 (Fix source sidebar hover in ayu theme)
- #98509 (diagnostics: consider parameter count when suggesting smart pointers)
- #98513 (Fix LLVM rebuild with download-ci-llvm.)
Yuki Okushi [Sun, 26 Jun 2022 04:15:03 +0000 (13:15 +0900)]
Rollup merge of #98513 - ehuss:rebuild-llvm-download, r=Mark-Simulacrum
Fix LLVM rebuild with download-ci-llvm.
This fixes an issue where updating a local checkout that includes a change in `src/version` causes a linking failure.
The cause is that the `rustc_llvm` build script uses `rerun-if-changed` of `llvm-config` to know if it needs to rerun. Cargo only compares the timestamp of the last time the build script to the file. However, extracting the tar files retains the timestamps in the tarball which may be some time in the past. Since `src/version` is included in the LLVM `.so` filename, `rustc` attempts to load the wrong shared library since the `rustc_llvm` build script doesn't rerun.
https://github.com/rust-lang/cargo/issues/10791 contains a more detailed explanation.
The solution here is a hack which updates the timestamp of `llvm-config` to the current time when it is extracted.
This is a bit of a hack, but seems to be the best solution I can think of until https://github.com/rust-lang/cargo/issues/10791 is fixed. There are likely several other situations where this is a problem (such as using system LLVM), and this isn't really a complete fix.
Note that apple platforms are not directly affected by this problem because they don't have a version in the dylib filename.
It's because the CSS selector was not precise enough and was "overloaded" with another one. This PR fixes it and adds a test for the colors in the source sidebar.
Yuki Okushi [Sun, 26 Jun 2022 04:15:00 +0000 (13:15 +0900)]
Rollup merge of #98491 - antoyo:fix/ui-test-backtrace-panic-abort, r=Dylan-DPC
Fix backtrace UI test when panic=abort is used
The function `contains_verbose_expected` is only used when the panic strategy is not abort, so it caused a warning when it was abort, which made the UI test failed on stderr comparison.
Yuki Okushi [Sun, 26 Jun 2022 04:14:59 +0000 (13:14 +0900)]
Rollup merge of #98488 - Mark-Simulacrum:bump-rls, r=pietroalbini
Bump RLS to latest master on rust-lang/rls
Of primary interest, this merges
rust-lang/rls@ece09b88c0365947af79c0ffdeea02bc6c1eec25 into rust-lang/rust,
which brings in the changes that fix RLS tests broken by #97853. #97853 already
introduced that commit's changes (under
rust-lang/rls@27f4044df03d15c7c38a483c3e4635cf4f51807d) but without putting those changes on
rust-lang/rls as a branch, so we ended up with an orphan commit that caused
trouble when updating submodules in rust-lang/rust.
This commit, once merged into rust-lang/rust, should continue to let RLS tests
to pass on rust-lang/rust's side and move us back into a healthy state where tip
of the submodule points to a valid master commit in the rust-lang/rls
repository.
cc https://github.com/rust-lang/rust/issues/98451, but not marking as fixed as I believe we need to add verification to prevent future oversights.
Yuki Okushi [Sun, 26 Jun 2022 04:14:57 +0000 (13:14 +0900)]
Rollup merge of #98385 - m-ou-se:llvm-12-memory-order, r=petrochenkov
Work around llvm 12's memory ordering restrictions.
Older llvm has the pre-C++17 restriction on success and failure memory ordering, requiring the former to be at least as strong as the latter. So, for llvm 12, this upgrades the success ordering to a stronger one if necessary.
See https://github.com/rust-lang/rust/issues/68464
bors [Sat, 25 Jun 2022 21:01:10 +0000 (21:01 +0000)]
Auto merge of #97513 - jyn514:submodule-handling, r=Mark-Simulacrum
Fully remove submodule handling from bootstrap.py
These submodules were previously updated in python because Cargo gives a hard error if toml files
are missing from the workspace:
```
error: failed to load manifest for workspace member `/home/jnelson/rust-lang/rust/src/tools/rls`
Caused by:
failed to read `/home/jnelson/rust-lang/rust/src/tools/rls/Cargo.toml`
Caused by:
No such file or directory (os error 2)
failed to run: /home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo build --manifest-path /home/jnelson/rust-lang/rust/src/bootstrap/Cargo.toml
```
However, bootstrap doesn't actually need to be part of the workspace.
Remove it so we can move submodule handling fully to Rust, avoiding duplicate code between Rust and Python.
Note that this does break `cargo run`; it has to be `cd src/bootstrap && cargo run` now.
Given that we're planning to make the main entrypoint a shell script (or rust binary),
I think this is a good tradeoff for reduced complexity in bootstrap.py.
To get this working, I also had to remove support for vendoring when using the git sources, because `cargo vendor` requires all submodules to be checked out. I think this is ok; people who care about this are likely already using the pre-vendored `rustc-src` tarball.
Fixes https://github.com/rust-lang/rust/issues/90764. Helps with #94829
bors [Sat, 25 Jun 2022 15:19:31 +0000 (15:19 +0000)]
Auto merge of #98486 - matthiaskrgr:rollup-u7m508x, r=matthiaskrgr
Rollup of 9 pull requests
Successful merges:
- #96412 (Windows: Iterative `remove_dir_all`)
- #98126 (Mitigate MMIO stale data vulnerability)
- #98149 (Set relocation_model to Pic on emscripten target)
- #98194 (Leak pthread_{mutex,rwlock}_t if it's dropped while locked.)
- #98298 (Point to type parameter definition when not finding variant, method and associated item)
- #98311 (Reverse folder hierarchy)
- #98401 (Add tracking issues to `--extern` option docs.)
- #98429 (Use correct substs in enum discriminant cast)
- #98431 (Suggest defining variable as mutable on `&mut _` type mismatch in pats)
Mark Rousskov [Sat, 25 Jun 2022 13:56:56 +0000 (09:56 -0400)]
Bump RLS to latest master on rust-lang/rls
Of primary interest, this merges
rust-lang/rls@ece09b88c0365947af79c0ffdeea02bc6c1eec25 into rust-lang/rust,
which brings in the changes that fix RLS tests broken by #97853. #97853 already
introduced that commit's changes (under 27f4044df03d15c7c38a483c3e4635cf4f51807d) but without putting those changes on
rust-lang/rls as a branch, so we ended up with an orphan commit that caused
trouble when updating submodules in rust-lang/rust.
This commit, once merged into rust-lang/rust, should continue to let RLS tests
to pass on rust-lang/rust's side and move us back into a healthy state where tip
of the submodule points to a valid master commit in the rust-lang/rls
repository.
Matthias Krüger [Sat, 25 Jun 2022 13:14:14 +0000 (15:14 +0200)]
Rollup merge of #98431 - WaffleLapkin:mut_pat_suggestions, r=compiler-errors
Suggest defining variable as mutable on `&mut _` type mismatch in pats
Suggest writing `mut a` where `&mut a` was written but a non-ref type provided.
Since we still don't have "apply either one of the suggestions but not both" kind of thing, the interaction with the suggestion of removing `&[mut]` or moving it to the type is weird, and idk how to make it better..
Matthias Krüger [Sat, 25 Jun 2022 13:14:11 +0000 (15:14 +0200)]
Rollup merge of #98311 - eggyal:reverse-folder-hierarchy, r=jackh726
Reverse folder hierarchy
#91318 introduced a trait for infallible folders distinct from the fallible version. For some reason (completely unfathomable to me now that I look at it with fresh eyes), the infallible trait was a supertrait of the fallible one: that is, all fallible folders were required to also be infallible. Moreover the `Error` associated type was defined on the infallible trait! It's so absurd that it has me questioning whether I was entirely sane.
This trait reverses the hierarchy, so that the fallible trait is a supertrait of the infallible one: all infallible folders are required to also be fallible (which is a trivial blanket implementation). This of course makes much more sense! It also enables the `Error` associated type to sit on the fallible trait, where it sensibly belongs.
There is one downside however: folders expose a `tcx` accessor method. Since the blanket fallible implementation for infallible folders only has access to a generic `F: TypeFolder`, we need that trait to expose such an accessor to which we can delegate. Alternatively it's possible to extract that accessor into a separate `HasTcx` trait (or similar) that would then be a supertrait of both the fallible and infallible folder traits: this would ensure that there's only one unambiguous `tcx` method, at the cost of a little additional boilerplate. If desired, I can submit that as a separate PR.
Matthias Krüger [Sat, 25 Jun 2022 13:14:08 +0000 (15:14 +0200)]
Rollup merge of #98149 - hoodmane:emscripten-pic, r=petrochenkov
Set relocation_model to Pic on emscripten target
So we can support dynamically linking libraries with Emscripten (otherwise we need to use nightly and `-Zbuild-std` to rebuild std with relocations).
`````@sbc100`````
Matthias Krüger [Sat, 25 Jun 2022 13:14:07 +0000 (15:14 +0200)]
Rollup merge of #98126 - fortanix:raoul/mitigate_stale_data_vulnerability, r=cuviper
Mitigate MMIO stale data vulnerability
Intel publicly disclosed the MMIO stale data vulnerability on June 14. To mitigate this vulnerability, compiler changes are required for the `x86_64-fortanix-unknown-sgx` target.
cc: ````@jethrogb````
bors [Sat, 25 Jun 2022 13:03:53 +0000 (13:03 +0000)]
Auto merge of #96820 - r-raymond:master, r=cuviper
Make RwLockReadGuard covariant
Hi, first time contributor here, if anything is not as expected, please let me know.
`RwLockReadGoard`'s type constructor is invariant. Since it behaves like a smart pointer to an immutable reference, there is no reason that it should not be covariant. Take e.g.
```
fn test_read_guard_covariance() {
fn do_stuff<'a>(_: RwLockReadGuard<'_, &'a i32>, _: &'a i32) {}
let j: i32 = 5;
let lock = RwLock::new(&j);
{
let i = 6;
do_stuff(lock.read().unwrap(), &i);
}
drop(lock);
}
```
where the compiler complains that &i doesn't live long enough. If `RwLockReadGuard` is covariant, then the above code is accepted because the lifetime can be shorter than `'a`.
In order for `RwLockReadGuard` to be covariant, it can't contain a full reference to the `RwLock`, which can never be covariant (because it exposes a mutable reference to the underlying data structure). By reducing the data structure to the required pieces of `RwLock`, the rest falls in place.
If there is a better way to do a test that tests successful compilation, please let me know.
bors [Fri, 24 Jun 2022 10:35:00 +0000 (10:35 +0000)]
Auto merge of #98447 - JohnTitor:rollup-pponoo3, r=JohnTitor
Rollup of 9 pull requests
Successful merges:
- #91264 (Add macro support in jump to definition feature)
- #96955 (Remove (transitive) reliance on sorting by DefId in pretty-printer)
- #97633 (Session object: Set OS/ABI)
- #98039 (Fix `panic` message for `BTreeSet`'s `range` API and document `panic` cases)
- #98214 (rustc_target: Remove some redundant target properties)
- #98280 (Improve suggestion for calling fn-like expr on type mismatch)
- #98394 (Fixup missing renames from `#[main]` to `#[rustc_main]`)
- #98411 (Update tendril)
- #98419 (Remove excess rib while resolving closures)
David Wood [Thu, 23 Jun 2022 15:12:52 +0000 (16:12 +0100)]
macros: use typed identifiers in subdiag derive
As in the diagnostic derive, using typed identifiers in the
subdiagnostic derive improves the diagnostics of using the subdiagnostic
derive as Fluent messages will be confirmed to exist at compile-time.
David Wood [Thu, 23 Jun 2022 13:51:44 +0000 (14:51 +0100)]
macros: use typed identifiers in diag derive
Using typed identifiers instead of strings with the Fluent identifier
enables the diagnostic derive to benefit from the compile-time
validation that comes with typed identifiers - use of a non-existent
Fluent identifier will not compile.
Yuki Okushi [Fri, 24 Jun 2022 07:43:49 +0000 (16:43 +0900)]
Rollup merge of #98419 - WaffleLapkin:remove_excess_rib, r=compiler-errors
Remove excess rib while resolving closures
I've mentioned this on [zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.60ClosureOrAsyncRibKind.60.20weirdness/near/286982959), in `rustc_resolve`, while resolving closures we add an excess `ClosureOrAsyncRibKind`. It's excess because we later add another one in `visit_fn`.
I couldn't find a way in which removing this will break anything, all test seem to pass, etc.
Yuki Okushi [Fri, 24 Jun 2022 07:43:48 +0000 (16:43 +0900)]
Rollup merge of #98411 - ehuss:update-tendril, r=Mark-Simulacrum
Update tendril
The 0.4.1 version of `tendril` (used by mdbook) triggers the `unaligned_references` lint which is now reported as a future-compatibility warning as of #95372. This updates it to 0.4.3 which does not trigger the warning. This update also triggered the update of `futf` from 0.1.4 to 0.1.5.
Yuki Okushi [Fri, 24 Jun 2022 07:43:47 +0000 (16:43 +0900)]
Rollup merge of #98394 - Enselic:fixup-rustc_main-renames, r=petrochenkov
Fixup missing renames from `#[main]` to `#[rustc_main]`
In #84217 `#[main]` was removed and replaced with `#[rustc_main]`. In some places the rename was forgotten, which makes the current code confusing, because at first glance it seems that `#[main]` is still around. Perform the renames also in these places.
I noticed this (after first being confused by it) when working on #97802.
Yuki Okushi [Fri, 24 Jun 2022 07:43:46 +0000 (16:43 +0900)]
Rollup merge of #98280 - compiler-errors:better-call-closure-on-type-err, r=estebank
Improve suggestion for calling fn-like expr on type mismatch
1.) Suggest calling values of with RPIT types (and probably TAIT) when we expect `Ty` and have `impl Fn() -> Ty`
2.) Suggest calling closures even when they're not assigned to a local variable first
3.) Drive-by fix of a pretty-printing bug (`impl Fn()-> Ty` => `impl Fn() -> Ty`)
Yuki Okushi [Fri, 24 Jun 2022 07:43:45 +0000 (16:43 +0900)]
Rollup merge of #98214 - petrochenkov:islike, r=compiler-errors
rustc_target: Remove some redundant target properties
`is_like_emscripten` is equivalent to `os == "emscripten"`, so it's removed.
`is_like_fuchsia` is equivalent to `os == "fuchsia"`, so it's removed.
`is_like_osx` also falls into the same category and is equivalent to `vendor == "apple"`, but it's commonly used so I kept it as is for now.
`is_like_(solaris,windows,wasm)` are combinations of different operating systems or architectures (see compiler/rustc_target/src/spec/tests/tests_impl.rs) so they are also kept as is.
I think `is_like_wasm` (and maybe `is_like_osx`) are sufficiently closed sets, so we can remove these fields as well and replace them with methods like `fn is_like_wasm() { arch == "wasm32" || arch == "wasm64" }`.
On other hand, `is_like_solaris` and `is_like_windows` are sufficiently open and I can imagine custom targets introducing other values for `os`.
This is kind of a gray area.
Yuki Okushi [Fri, 24 Jun 2022 07:43:44 +0000 (16:43 +0900)]
Rollup merge of #98039 - tnballo:master, r=thomcc
Fix `panic` message for `BTreeSet`'s `range` API and document `panic` cases
Currently, the `panic` cases for [`BTreeSet`'s `range` API](https://doc.rust-lang.org/std/collections/struct.BTreeSet.html#method.range) are undocumented and produce a slightly wrong `panic` message (says `BTreeMap` instead of `BTreeSet`).
Panic case 1 code:
```rust
use std::collections::BTreeSet;
use std::ops::Bound::Excluded;
fn main() {
let mut set = BTreeSet::new();
set.insert(3);
set.insert(5);
set.insert(8);
for &elem in set.range((Excluded(&3), Excluded(&3))) {
println!("{elem}");
}
}
```
Panic case 1 message:
```
thread 'main' panicked at 'range start and end are equal and excluded in BTreeMap', /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/alloc/src/collections/btree/search.rs:105:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Panic case 2 code:
```rust
use std::collections::BTreeSet;
use std::ops::Bound::Included;
fn main() {
let mut set = BTreeSet::new();
set.insert(3);
set.insert(5);
set.insert(8);
for &elem in set.range((Included(&8), Included(&3))) {
println!("{elem}");
}
}
```
Panic case 2:
```
thread 'main' panicked at 'range start is greater than range end in BTreeMap', /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/alloc/src/collections/btree/search.rs:110:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
This PR fixes the output messages to say `BTreeSet`, adds the relevant unit tests, and updates the documentation for the API.
This depends on
* https://github.com/gimli-rs/object/pull/438
This adapts LLVM's behavior of [`MCELFObjectTargetWriter::getOSABI`](https://github.com/llvm/llvm-project/blob/8c8a2679a20f621994fa904bcfc68775e7345edc/llvm/include/llvm/MC/MCELFObjectWriter.h#L72-L86).
Yuki Okushi [Fri, 24 Jun 2022 07:43:41 +0000 (16:43 +0900)]
Rollup merge of #91264 - GuillaumeGomez:macro-jump-to-def, r=jsha
Add macro support in jump to definition feature
Fixes #91174.
To do so, I check if the span comes from an expansion, and if so, I infer the original macro `DefId` or `Span` depending if it's a defined in the current crate or not.
There is one limitation due to macro expansion though:
```rust
macro_rules! yolo { () => {}}
fn foo() {
yolo!();
}
```
In `foo`, `yolo!` won't be linked because after expansion, it is replaced by nothing (which seems logical). So I can't get an item from the `Visitor` from which I could tell if its `Span` comes from an expansion.
I added a test for this specific limitation alongside others.
As for the empty macro issue that cannot create a jump to definition, you can see it [here](https://rustdoc.crud.net/imperio/macro-jump-to-def/src/foo/check-source-code-urls-to-def-std.rs.html#35).
bors [Fri, 24 Jun 2022 04:37:14 +0000 (04:37 +0000)]
Auto merge of #98395 - arlosi:update-cargo, r=ehuss
Update cargo
8 commits in 03a849043e25104e8b7ad0d4a96c525787b69379..a5e08c4703f202e30cdaf80ca3e7c00baa59c496
2022-06-20 14:47:36 +0000 to 2022-06-23 20:12:03 +0000
- Fix tests due to change in dead_code diagnostic. (rust-lang/cargo#10785)
- Stabilize config-cli (rust-lang/cargo#10755)
- Restrict duplicate deps warning only to published packages (rust-lang/cargo#10767)
- Use fingerprint_hash when computing fingerprints for custom targets (rust-lang/cargo#10746)
- Add preloading for workspace packages in `resolve_with_previous` (rust-lang/cargo#10761)
- capitalise, for consistency (rust-lang/cargo#10772)
- remove unused dependency from benchsuite (rust-lang/cargo#10774)
- docs(contrib): Add documentation for ui tests (rust-lang/cargo#10758)
bors [Fri, 24 Jun 2022 02:08:52 +0000 (02:08 +0000)]
Auto merge of #98438 - compiler-errors:rollup-fudubjn, r=compiler-errors
Rollup of 16 pull requests
Successful merges:
- #96173 (Fix documentation for `with_capacity` and `reserve` families of methods)
- #98184 (Give name if anonymous region appears in impl signature)
- #98259 (Greatly improve error reporting for futures and generators in `note_obligation_cause_code`)
- #98269 (Provide a `PathSegment.res` in more cases)
- #98283 (Point at private fields in struct literal)
- #98305 (prohibit_generics: don't alloc error string if no error emitted)
- #98310 (rustdoc: optimize loading of source sidebar)
- #98353 (Migrate two diagnostics from the `rustc_builtin_macros` crate)
- #98355 (Update no_default_libraries handling for emscripten target)
- #98364 (clarify Arc::clone overflow check comment)
- #98365 (Address review comments from #98259)
- #98388 (implement `iter_projections` function on `PlaceRef`)
- #98390 (Fixes handling of keywords in rustdoc json output)
- #98409 (triagebot.toml: Allow applying nominated labels)
- #98410 (Update books)
- #98422 (Update browser-ui-test version to 0.9.6)
projects / rust.git / log