Added upper bound of what vecs and boxes can allocate
Fixed issue #68593
I added a line of documentation to these two files to reflect that vectors and boxes ensure that they never allocate more than `isize::MAX` bytes.
r? @steveklabnik
Install robots.txt into rust-docs tarballs
Fixes#68677.
I believe this might just work out from the central-station perspective, but even if it doesn't, this is a prerequisite step anyway.
codegen: create DIVariables ahead of using them with llvm.dbg.declare.
Instead of having `rustc_codegen_llvm` bundle creation of a `DIVariable` and `llvm.dbg.declare` into a single operation, they are now two separate methods, and the `DIVariable` is created earlier, specifically when `mir::VarDebugInfo`s are being partitioned into locals.
While this isn't currently needed, it's a prerequisite for #48300, which adds fragmented debuginfo, where one `mir::VarDebugInfo` has multiple parts of itself mapped to different `mir::Place`s.
For debuggers to see one composite variable instead of several ones with the same name, we need to create a single `DIVariable` and share it between multiple `llvm.dbg.declare` calls, which are likely pointing to different MIR locals.
That makes the `per_local_var_debug_info` partitioning a good spot to do this in, as we can create *exactly* one `DIVariable` per `mir::VarDebugInfo`, and refer to it as many things as needed.
I'm opening this PR separately because I want to test its perf impact in isolation (see https://github.com/rust-lang/rust/pull/48300#issuecomment-580121438).
r? @nagisa or @oli-obk cc @michaelwoerister @nikomatsakis
Avoid exponential behaviour when relating types
When equating bound types we check subtyping in both directions. Since closures are invariant in their substs, we end up comparing the two types an exponential number of times. If there are no bound variables this isn't needed.
Closes#68061
parser: syntactically allow `self` in all `fn` contexts
Part of https://github.com/rust-lang/rust/pull/68728.
`self` parameters are now *syntactically* allowed as the first parameter irrespective of item context (and in function pointers). Instead, semantic validation (`ast_validation`) is used.
r? @petrochenkov
Rollup of 7 pull requests
Successful merges:
- #68460 (Use BufWriter for emitting MIR)
- #68681 (Suggest path separator for single-colon typos)
- #68688 ([docs] remind bug reporters to update nightly)
- #68704 (Ignore `build` dir formatting)
- #68727 (Remove a comment about pretty printer in formatting tests)
- #68736 (Remove `Alloc` in favor of `AllocRef`)
- #68740 (Do not suggest things named underscore)
Failed merges:
r? @ghost
Remove `Alloc` in favor of `AllocRef`
`AllocRef` was reexported as `Alloc` in #68529 in order to not break toolstate in the week before the next stable release.
r? @Amanieu
Ignore `build` dir formatting
I've noticed that rustfmt tries to parse and check the formatting of code in `build` if `.git` is missing (which includes test artifacts and generated code). This should fix that.
[docs] remind bug reporters to update nightly
Hi and thanks for rust! Today I reported a bug in nightly that was already fixed, so I thought other potential bug reporters might appreciate a reminder to update before reporting. I wasn't sure if this would apply for other channels as well.
Suggest path separator for single-colon typos
This commit adds guidance for when a user means to type a path, but ends
up typing a single colon, such as `<<Impl as T>:Ty>`.
This change seemed pertinent as the current error message is
particularly misleading, emitting `error: unmatched angle bracket`,
despite the angle bracket being matched later on, leaving the user to
track down the typo'd colon.
Use BufWriter for emitting MIR
I noticed that `--emit=mir` takes long time on a large crate. https://github.com/rust-lang/rust/pull/64344 seem to have fixed `-Zdump-mir`, but not `--emit=mir`.
