| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Rollup of 3 pull requests
Successful merges:
- #115478 (Emit unused doc comment warnings for pat and expr fields)
- #115490 (rustdoc: update comment in search.js for #107629)
- #115503 (Migrate GUI colors test to original CSS color format)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Migrate GUI colors test to original CSS color format
Follow-up of https://github.com/rust-lang/rust/pull/111459.
r? `@notriddle`
|
|
rustdoc: update comment in search.js for #107629
Addressing https://github.com/rust-lang/rust/pull/107629#issuecomment-1693460106
r? `@jsha`
|
|
Emit unused doc comment warnings for pat and expr fields
Fixes #115462
|
|
optimize bootstrap dep tree
bumped `pretty_assertations` in favor of removing duplicated `syn`, and bumped `hermit-abi` from the yanked version.
|
|
Don't manually compute param indices when adding implicit `Sized` and `ConstParamHasTy`
We can just use resolve_bound_vars to compute these indices faithfully.
This also makes the code easier to support where clauses on `non_lifetime_binders` (like `where for<T: Debug> ...`, etc, which I've got a [WIP implementation of](https://github.com/rust-lang/rust/compare/master...compiler-errors:rust:non-lifetime-binder-where-clauses)).
r? `@cjgillot`
|
|
|
|
|
|
update Miri
There were conflicts on the last pull, so make sure it's all in sync both ways
r? `@ghost`
|
|
add stable provenance
r? `@spastorino`
implements rust-lang/project-stable-mir#22
|
|
Rustup
|
|
|
|
|
|
make it more clear what 'Tier 2' (without host tools) means
When saying that Rust "builds official binary releases for each tier 2 target", it's not at all clear that this does not mean we build a compiler and cargo for that target.
|
|
fix the repetitive word
|
|
|
|
|
|
[rustdoc] Fix type based search
Fixes https://github.com/rust-lang/rust/issues/114522.
The problem was a bit more tricky than I originally thought it would be: we only kept type ID and generics in short, but as soon as there was a full path in the user query, the element didn't get an ID anymore because the ID map didn't know about `x::y` (although it knew about `y`). So for this first problem, I instead always pass the element name to get the ID.
Then a new problem occurred: we actually needed to check if paths matched, otherwise whatever the path, as long as the "end types" match, it's all good. meaning, we needed to add path information, but to do so, we needed it to be added into the search index directly as there was no mapping between `"p"` and `"q"`.
I hope this explanation makes sense to someone else than me. ^^'
r? `@notriddle`
|
|
|
|
Migrate GUI colors test to original CSS color format
Follow-up of https://github.com/rust-lang/rust/pull/111459.
r? `@notriddle`
|
|
|
|
also skip musl checks when BOOTSTRAP_SKIP_TARGET_SANITY is set
Currently I cannot test musl targets in Miri via x.py; this PR fixes that.
|
|
|
|
Optimize Take::{fold, for_each} when wrapping TrustedRandomAccess iterators
|
|
|
|
Fall through when resolving elided assoc const lifetimes
`@QuineDot` makes a good point in https://github.com/rust-lang/rust/issues/115010#issuecomment-1702127634 that we probably should not accept *more* code due to #115011 even though that code will eventually become a forbid-warning in a few versions (https://github.com/rust-lang/rust/issues/115010#issuecomment-1701598067).
Fall through when walking thru the `AnonymousWarnToStatic` (renamed to `AnonymousWarn`) rib so that we can resolve as a fresh lifetime like we did before.
|
|
|
|
bootstrap: use git merge-base for LLVM CI download logic
This re-lands https://github.com/rust-lang/rust/pull/113588, now that the perf issues are hopefully fixed by https://github.com/rust-lang/rustc-perf/pull/1684.
r? `@lqd` `@Mark-Simulacrum`
Fixes https://github.com/rust-lang/rust/issues/101907
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #114349 (rustc_llvm: Link to `zlib` on dragonfly and solaris)
- #114845 (Add alignment to the NPO guarantee)
- #115427 (kmc-solid: Fix `is_interrupted`)
- #115443 (feat(std): Stabilize 'os_str_bytes' feature)
- #115444 (Create a SMIR visitor)
- #115449 (Const-stabilize `is_ascii`)
- #115456 (Add spastorino on vacation)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Add spastorino on vacation
|
|
Const-stabilize `is_ascii`
Resolves #111090
FCP completed in https://github.com/rust-lang/rust/issues/111090#issuecomment-1688490049
|
|
Create a SMIR visitor
r? ``@spastorino``
Doesn't have tests or examples yet, but I think we could land it and implement it for the rest of the types.
|
|
feat(std): Stabilize 'os_str_bytes' feature
Closes #111544
|
|
kmc-solid: Fix `is_interrupted`
Follow-up to #115228. Fixes a build error in [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets.
```
error[E0603]: function `is_interrupted` is private
--> library\std\src\sys\solid\mod.rs:77:12
|
77 | error::is_interrupted(code)
| ^^^^^^^^^^^^^^ private function
|
note: the function `is_interrupted` is defined here
--> library\std\src\sys\solid\error.rs:35:1
|
35 | fn is_interrupted(er: abi::ER) -> bool {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
|
|
Add alignment to the NPO guarantee
This PR [changes](https://github.com/rust-lang/rust/pull/114845#discussion_r1294363357) "same size" to "same size and alignment" in the option module's null pointer optimization docs in <https://doc.rust-lang.org/std/option/#representation>.
As far as I know, this has been true for a long time in the actual rustc implementation, but it's not in the text of those docs, so I figured I'd bring this up to FCP it.
I also see no particular reason that we'd ever *want* to have higher alignment on these. In many of the cases it's impossible, as the minimum alignment is already the size of the type, but even if we *could* do things like on 32-bit we could say that `NonZeroU64` is 4-align but `Option<NonZeroU64>` is 8-align, I just don't see any value in doing that, so feel completely fine closing this door for the few things on which the NPO is already guaranteed. These are basically all primitives, and should end up with the same size & alignment as those primitives.
(There's no layout guarantee for something like `Option<[u8; 3]>`, where it'd be at least plausible to consider raising the alignment from 1 to 4 on, say, some hypothetical target that doesn't have efficient unaligned 4-byte load/stores. And even if we ever did start to offer some kind of guarantee around such a type, I doubt we'd put it under the "null pointer" optimization header.)
Screenshots for the new examples:
|
|
rustc_llvm: Link to `zlib` on dragonfly and solaris
On native builds `llvm-config` picks up `zlib` and this gets pased into
the rust build tools, but on cross builds `llvm-config` is explicitly
ignored as it contains information for the host system and cannot be
trusted to be accurate for the target system.
Both DragonFly and Solaris contain `zlib` in the base system, so this is
both a safe assumption and required for a successful cross build unless
`zlib` support is disabled in LLVM.
This is more or less in the same vein as rust-lang#75713 and rust-lang#75655.
|
|
Skip rendering metadata strings from include_str!/include_bytes!
The const rendering code in rustdoc completely ignores consts from expansions, but the compiler was rendering all consts. So some consts (namely those from `include_bytes!`) were rendered then ignored.
Most of the diff here is from moving `print_const_expr` from rustdoc into `rustc_hir_pretty` so that it can be used in rustdoc and when building rmeta files.
|
|
Use `OnceLock` for `SingleCache`
This uses `OnceLock` for `SingleCache` instead of `Lock<Option<T>>` so lookups are lock-free.
r? `@cjgillot`
|
|
Rustup
|
|
|
|
|
|
|
|
Implement Step for ascii::Char
This allows iterating over ranges of `ascii::Char`, similarly to ranges of `char`.
Note that `ascii::Char` is still unstable, tracked in #110998.
|
|
remove the repetitive word
Signed-off-by: cui fliter <imcusg@gmail.com>
|
|
r=GuillaumeGomez
rustdoc: correctly deal with self ty params when eliding default object lifetimes
Fixes #115179.
|
|
|
