| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
[beta] Clippy backport
r? `@Mark-Simulacrum`
Really small backport this time:
- https://github.com/rust-lang/rust-clippy/pull/12961
Fixes a quite annoying bug of this lint, that got into the last stable release 1.79.0. There were already 3 issues opened about it in the Clippy repo. It would be great to get this fixed for the next stable release.
I confirmed that this commit is already part of `master`
|
|
Fix incorrect suggestion for `manual_unwrap_or_default`
Fixes #12928.
If this not a "simple" pattern, better not emit the lint.
changelog: Fix incorrect suggestion for `manual_unwrap_or_default`
|
|
binutils 2.40 is required by LLVM 19, as older versions do not
know about the zmmull extension.
I've had to backport some patches to glibc and gcc as well,
as they don't build with binutils 2.40. Alternatively, we could
also switch to glibc 2.35 and gcc 12 (I think). I figured we'd
want to avoid the glibc version change, but if that's fine for
riscv I can go with that instead.
|
|
|
|
(cherry picked from commit 3d699a4fa1eee76a8d8951e449d5df37061af658)
|
|
The CDN has been down for a few hours. Switch to an alternative for the
time being so we can unblock CI.
It appears that the CDN is quite a bit faster, so we will likely want to
switch back when available.
(cherry picked from commit 42ac903f4fe4e9894f8c6e97538696bdbae848dc)
|
|
(cherry picked from commit da81d0d940481827fb2bdd164ea0038832e3779e)
|
|
CentOS 7 is going EOL on June 30, after which its package repos will no
longer exist on the regular mirrors. We'll still be able to access
packages from the vault server though, and can start doing so now. This
affects `dist-i686-linux` and `dist-x86_64-linux`.
I also removed `epel-release` because we were only using that for its
`cmake3`, but we've been building our own version for a while.
(cherry picked from commit 6d2493bf5d6c97bc52aa109944a7f27ee456192e)
|
|
|
|
|
|
|
|
Rollup of 11 pull requests
Successful merges:
- #124012 (Stabilize `binary_heap_as_slice`)
- #124214 (Parse unsafe attributes)
- #125572 (Detect pub structs never constructed and unused associated constants)
- #125781 (prefer `compile::stream_cargo` for building tools)
- #126030 (Update `./x fmt` command in library/std/src/sys/pal/windows/c/README.md)
- #126047 (Simplify the rayon calls in the installer)
- #126052 (More `rustc_parse` cleanups)
- #126077 (Revert "Use the HIR instead of mir_keys for determining whether something will have a MIR body.")
- #126089 (Stabilize Option::take_if)
- #126112 (Clean up source root in run-make tests)
- #126119 (Improve docs for using custom paths with `--emit`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Improve docs for using custom paths with `--emit`
Recently I found myself concluding that this feature didn't exist (https://github.com/rust-lang/rust/pull/126111#discussion_r1630707215), despite having read the documentation, because it was hidden away in the middle of a paragraph full of other information.
Giving this documentation more space of its own should make it easier to find.
|
|
Clean up source root in run-make tests
The name `S` isn't exactly the most descriptive, and we also shouldn't need to pass it when building (actually I think that most of the env. vars that we pass to `cargo` here are probably not really needed).
Related issue: https://github.com/rust-lang/rust/issues/126071
r? ```@jieyouxu```
|
|
Simplify the rayon calls in the installer
Rayon's `try_for_each` makes the `CombinedEncoder` a lot simpler.
|
|
prefer `compile::stream_cargo` for building tools
Previously, we were running bare commands for `ToolBuild` step and were unable to utilize some of the flags which are already handled by `compile::stream_cargo`.
This change makes `ToolBuild` to use `compile::stream_cargo`, allowing us to benefit from the flags supported by the bootstrap cargo.
Resolves #125666
|
|
Parse unsafe attributes
Initial parse implementation for #123757
This is the initial work to parse unsafe attributes, which is represented as an extra `unsafety` field in `MetaItem` and `AttrItem`. There's two areas in the code where it appears that parsing is done manually and not using the parser stuff, and I'm not sure how I'm supposed to thread the change there.
|
|
|
|
|
|
It doesn't really make sense to skip part of the source when we're
parsing it, so parse the whole doctest. This simplifies things too.
|
|
This code turns the raw code given by the user into something actually
runnable, e.g. by adding a `main` function if it doesn't already exist.
I also made a couple other items private that didn't need to be
crate-public.
|
|
|
|
I moved some local arguments and options to either the local options
struct or, if it made sense, the global options struct.
|
|
It should instead be the actual input to the running logic. Currently
it's not actually quite runnable since it's still missing some
information.
|
|
|
|
This was used to get the line number of the first line from the current
docstring, which was then used together with an offset within the
docstring. It's simpler to just pass the offset to the visitor and have
it do the math because it's clearer and this calculation only needs to
be done in one place (the Rust doctest visitor).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The new name more accurately captures what it is.
|
|
|
|
Revert: create const block bodies in typeck via query feeding
as per the discussion in https://github.com/rust-lang/rust/pull/125806#discussion_r1622563948
It was a mistake to try to shoehorn const blocks and some specific anon consts into the same box and feed them during typeck. It turned out not simplifying anything (my hope was that we could feed `type_of` to start avoiding the huge HIR matcher, but that didn't work out), but instead making a few things more fragile.
reverts the const-block-specific parts of https://github.com/rust-lang/rust/pull/124650
`@bors` rollup=never had a small perf impact previously
fixes https://github.com/rust-lang/rust/issues/125846
r? `@compiler-errors`
|
|
This reverts commit ddc5f9b6c1f21da5d4596bf7980185a00984ac42.
|
|
|
|
|
|
Revert "Disallow ambiguous attributes on expressions" on nightly
As discussed in [today's t-compiler meeting](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202024-06-06/near/443079505), this reverts PR #124099 to fix P-critical beta regressions #125199.
r? ``@wesleywiser``
Opening as draft so that ``@wesleywiser`` and ``@apiraino,`` you can tell me whether you wanted:
1. a `beta-accepted` revert of #124099 on nightly (this PR)? That will need to be backported to beta (even though #126093 may be the last of those)
2. a revert of #124099 on beta?
3. all of the above?
I also opened #126102, another draft PR to revert #124099 on beta, should you choose options 2 or 3.
|
|
|
|
|
|
|
|
Rollup of 12 pull requests
Successful merges:
- #125220 (Repair several `riscv64gc-unknown-linux-gnu` codegen tests)
- #126033 (CI: fix publishing of toolstate history)
- #126034 (Clarify our tier 1 Windows Server support)
- #126035 (Some minor query system cleanups)
- #126051 (Clarify an `x fmt` error.)
- #126059 (Raise `DEFAULT_MIN_STACK_SIZE` to at least 64KiB)
- #126064 (Migrate `run-make/manual-crate-name` to `rmake.rs`)
- #126072 (compiletest: Allow multiple `//@ run-flags:` headers)
- #126073 (Port `tests/run-make-fulldeps/obtain-borrowck` to ui-fulldeps)
- #126081 (Do not use relative paths to Rust source root in run-make tests)
- #126086 (use windows compatible executable name for libcxx-version)
- #126096 ([RFC-2011] Allow `core_intrinsics` when activated)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
use windows compatible executable name for libcxx-version
Resolves #https://github.com/rust-lang/rust/pull/125411#discussion_r1629915724
|
|
Do not use relative paths to Rust source root in run-make tests
Pre-requisite for https://github.com/rust-lang/rust/issues/126080.
Fixes: https://github.com/rust-lang/rust/issues/126071
r? `@jieyouxu`
|
|
compiletest: Allow multiple `//@ run-flags:` headers
While working on some tests, I was annoyed to find that multiple `// `@run-flags:`` headers do not combine with each other (as `//@ compile-flags:` headers do), and instead all but one are silently discarded.
This makes it impossible to split long flag lists into multiple lines.
Fortunately it's easy to just recycle the existing logic from the other command-line-flags headers.
|
