| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This fixes a double-free in the `clone_from` function if dropping an
existing element in the table panics. See
https://github.com/rust-lang/hashbrown/pull/348 for more details.
|
|
This removes the last dependencies on hashbrown 0.11.
|
|
Fixes #100066
|
|
This effectively reverts https://github.com/rust-lang/rust/pull/97684 for CTFE
|
|
|
|
Revert "Stabilize $$ in Rust 1.63.0"
This mechanically reverts commit 9edaa76adce4de737db54194eb13d6c298827b37, the one commit from #95860.
https://github.com/rust-lang/rust/issues/99035; the behavior of `$$crate` is potentially unexpected and not ready to be stabilized. https://github.com/rust-lang/rust/pull/99193 attempts to forbid `$$crate` without also destabilizing `$$` more generally.
`@rustbot` modify labels +T-compiler +T-lang +P-medium +beta-nominated +relnotes
(applying the labels I think are accurate from the issue and alternative partial revert)
cc `@Mark-Simulacrum`
|
|
|
|
In NLL, when we are promoting a bound out from a closure,
if we have a requirement that `T: 'a` where `'a` is in a
higher universe, we were previously ignoring that, which is
totally wrong. We should be promoting those constraints to `'static`,
since universes are not expressible across closure boundaries.
|
|
|
|
else would work anyway.
|
|
sure we don't accidentally mark something as ok-modulo-regions if there are opaque types involved
|
|
|
|
hidden types for opaque types
|
|
|
|
|
|
This return value is iterated upon by borrowck, hence the need to preserve
a deterministic iteration order.
|
|
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)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
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.
r? ``@compiler-errors``
cc ``@davidtwco``
|
|
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.
r? `@petrochenkov`
(since you reviewed the other PR)
|
|
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`)
r? ```@estebank```
|
|
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.
|
|
Session object: Set OS/ABI
Closes https://github.com/rust-lang/rust/issues/97535.
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).
|
|
Remove (transitive) reliance on sorting by DefId in pretty-printer
This moves us a step closer to removing the `PartialOrd/`Ord` impls
for `DefId`. See #90317
|
|
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.
Demo: https://rustdoc.crud.net/imperio/macro-jump-to-def/src/foo/check-source-code-urls-to-def-std.rs.html
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).
r? ```@jyn514```
|
|
fix universes in the NLL type tests
In the NLL code, we were not accommodating universes in the
`type_test` logic.
Fixes #98095.
r? `@compiler-errors`
This breaks some tests, however, so the purpose of this branch is more explanatory and perhaps to do a crater run.
|
|
implement `iter_projections` function on `PlaceRef`
this makes the api more flexible. the original function now calls the PlaceRef
version to avoid duplicating the code.
|
|
r=eholk
Address review comments from #98259
It got approved so fast I didn't have time to make changes xD
r? ``@eholk``
|
|
Update no_default_libraries handling for emscripten target
```@sbc100``` says:
> `-sDEFAULT_LIBRARY_FUNCS_TO_INCLUDE=[]` is almost certainly wrong/out-of-date. This setting defaults to the empty list anyway these days so its redundant. Also we now support `-nodefaultlibs` so you can use that, as with other toolchains.
https://github.com/rust-lang/rust/issues/98303#issuecomment-1162163684
|
|
Migrate two diagnostics from the `rustc_builtin_macros` crate
Migrate two diagnostics to use the struct derive and be translatable.
r? ```@davidtwco```
|
|
prohibit_generics: don't alloc error string if no error emitted
Noticed unreaded allocs in DHAT.
|
|
r=compiler-errors
Point at private fields in struct literal
closes #95872
|
|
r=petrochenkov
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``
|
|
Give name if anonymous region appears in impl signature
Fixes #98170
We probably should remove the two unwraps in [`report_general_error`](https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_borrowck/diagnostics/region_errors.rs.html#683-685), but I have no idea what to provide if those regions are missing, so I've kept those in. Let me know if I should try harder to remove those.
|
|
|
|
per aliemjay's suggestion
|
|
|
|
Hat-tip: aliemjay
|
|
Co-authored-by: Oli Scherer <github35764891676564198441@oli-obk.de>
|
|
|
|
|
|
|
|
This adapts LLVM's behavior of MCELFObjectTargetWriter::getOSABI [1].
[1]: https://github.com/llvm/llvm-project/blob/8c8a2679a20f621994fa904bcfc68775e7345edc/llvm/include/llvm/MC/MCELFObjectWriter.h#L72-L86
|
|
|
|
|
|
This moves us a step closer to removing the `PartialOrd/`Ord` impls
for `DefId`. See #90317
|
|
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.
|
|
this makes the api more flexible. the original function now calls the PlaceRef
version to avoid duplicating the code.
|
|
Create elided lifetime parameters for function-like types
Split from https://github.com/rust-lang/rust/pull/97720
This PR refactor lifetime generic parameters in bare function types and parenthesized traits to introduce the additional required lifetimes as fresh parameters in a `for<>` bound.
This PR does the same to lifetimes appearing in closure signatures, and as-if introducing `for<>` bounds on closures (without the associated change in semantics).
r? `@petrochenkov`
|
|
Simplify `likely!` and `unlikely!` macro
The corresponding intrinsics have long been safe-to-call, so the unsafe block is no longer needed.
|
