Provide a `PathSegment.res` in more cases
I find that in many cases, the `res` associated with a `PathSegment` is `Res::Err` even though the path was fully resolved. A few diagnostics use this `res` and their error messages suffer because of the lack of resolved segment.
This fixes it a bit, but it's obviously not complete and I'm not exactly sure if it's correct.
Greatly improve error reporting for futures and generators in `note_obligation_cause_code`
Most futures don't go through this code path, because they're caught by
`maybe_note_obligation_cause_for_async_await`. But all generators do,
and `maybe_note` is imperfect and doesn't catch all futures. Improve the error message for those it misses.
At some point, we may want to consider unifying this with the code for `maybe_note_async_await`,
so that `async_await` notes all parent constraints, and `note_obligation` can point to yield points.
But both functions are quite complicated, and it's not clear to me how to combine them;
this seems like a good incremental improvement.
Helps with https://github.com/rust-lang/rust/issues/97332.
r? ``@estebank`` cc ``@eholk`` ``@compiler-errors``
Fix documentation for `with_capacity` and `reserve` families of methods
Fixes#95614
Documentation for the following methods
- `with_capacity`
- `with_capacity_in`
- `with_capacity_and_hasher`
- `reserve`
- `reserve_exact`
- `try_reserve`
- `try_reserve_exact`
was inconsistent and often not entirely correct where they existed on the following types
- `Vec`
- `VecDeque`
- `String`
- `OsString`
- `PathBuf`
- `BinaryHeap`
- `HashSet`
- `HashMap`
- `BufWriter`
- `LineWriter`
since the allocator is allowed to allocate more than the requested capacity in all such cases, and will frequently "allocate" much more in the case of zero-sized types (I also checked `BufReader`, but there the docs appear to be accurate as it appears to actually allocate the exact capacity).
Some effort was made to make the documentation more consistent between types as well.
Temporarily disable submodule archive downloads.
The `llvm-project` `/archive/` download has been timing out with a 504 error since yesterday. This changes it so that it uses a normal submodule clone, but also uses `--depth 1` since GitHub now supports `allowReachableSHA1InWant` which allows for fetching a specific revision. That should be reasonably fast (but not as fast as an archive download) to unstick CI.
Fixes 5395
In PR 5239 we switched from using `structopt` to `clap`. It seems that
the default behavior for `clap` is to override the `--version` flag,
which prevented our custom version display code from running.
The fix as outlined in https://github.com/clap-rs/clap/issues/3405 was
to set `#[clap(global_setting(AppSettings::NoAutoVersion))]` to prevent
clap from setting its own default behavior for the `--version` flag.
In fc357039f9 `#[main]` was removed and replaced with `#[rustc_main]`.
In some place 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.
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.
