| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
update `measureme` to 10.1.2 to deduplicate `parking_lot`
This PR updates `measureme` to the latest release to remove the last duplicates of `parking_lot` 0.11 we had in our dependency tree.
```console
Updating measureme v10.1.1 -> v10.1.2
Removing parking_lot v0.11.2
Removing parking_lot_core v0.8.6
```
Also removes `instant` from the allowed list of dependencies, as it's no longer used.
r? `@michaelwoerister` (Thanks for the release in the first place 🙏)
|
|
Add -Zunpretty=stable-mir output test
As strongly suggested here https://github.com/rust-lang/rust/pull/118364#issuecomment-1827974148 this adds output test for `-Zunpretty=stable-mir`, added test shows almost all the functionality of the current printer.
r? `@compiler-errors`
|
|
|
|
|
|
use c literals in compiler and library
Relands refreshed https://github.com/rust-lang/rust/pull/111647
|
|
On borrow return type, suggest borrowing from arg or owned return type
When we encounter a function with a return type that has an anonymous lifetime with no argument to borrow from, besides suggesting the `'static` lifetime we now also suggest changing the arguments to be borrows or changing the return type to be an owned type.
```
error[E0106]: missing lifetime specifier
--> $DIR/variadic-ffi-6.rs:7:6
|
LL | ) -> &usize {
| ^ expected named lifetime parameter
|
= help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from
help: consider using the `'static` lifetime, but this is uncommon unless you're returning a borrowed value from a `const` or a `static`
|
LL | ) -> &'static usize {
| +++++++
help: instead, you are more likely to want to change one of the arguments to be borrowed...
|
LL | x: &usize,
| +
help: ...or alternatively, to want to return an owned value
|
LL - ) -> &usize {
LL + ) -> usize {
|
```
Fix #85843.
|
|
use bold magenta instead of bold white for highlighting
according to a poll of gay people in my phone, purple is the most popular color to use for highlighting
| color | percentage |
| ---------- | ---------- |
| bold white | 6% |
| blue | 14% |
| cyan | 26% |
| purple | 37% |
| magenta | 17% |
unfortunately, purple is not supported by 16-color terminals, which rustc apparently wants to support for some reason.
until we require support for full 256-color terms (e.g. by doing the same feature detection as we currently do for urls), we can't use it.
instead, i have collapsed the purple votes into magenta on the theory that they're close, and also because magenta is pretty.
before:
after:
other colors for comparison:
blue: 
cyan: 
purple: 
magenta without bolding: 
r? ``@estebank``
|
|
according to a poll of gay people in my phone, purple is the most popular color to use for highlighting
| color | percentage |
| ---------- | ---------- |
| bold white | 6% |
| blue | 14% |
| cyan | 26% |
| purple | 37% |
| magenta | 17% |
unfortunately, purple is not supported by 16-color terminals, which rustc apparently wants to support for some reason.
until we require support for full 256-color terms (e.g. by doing the same feature detection as we currently do for urls), we can't use it.
instead, i have collapsed the purple votes into magenta on the theory that they're close, and also because magenta is pretty.
|
|
This is desired for #118702.
|
|
Use `unwinding` crate for unwinding on Xous platform
This patch adds support for using [unwinding](https://github.com/nbdd0121/unwinding) on platforms where libunwinding isn't viable. An example of such a platform is `riscv32imac-unknown-xous-elf`.
### Background
The Rust project maintains a fork of llvm at [llvm-project](https://github.com/rust-lang/llvm-project/) where it applies patches on top of the llvm project. This mostly seems to be to get unwinding support for the SGX project, and there may be other patches that I'm unaware of.
There is a lot of machinery in the build system to support compiling `libunwind` on other platforms, and I needed to add additional patches to llvm in order to add support for Xous.
Rather than continuing down this path, it seemed much easier to use a Rust-based library. The `unwinding` crate by `@nbdd0121` fits this description perfectly.
### Future work
This could potentially replace the custom patches for `libunwind` on other platforms such as SGX, and could enable unwinding support on many more exotic platforms.
### Anti-goals
This is not designed to replace `libunwind` on tier-one platforms or those where unwinding support already exists. There is already a well-established approach for unwinding there. Instead, this aims to enable unwinding on new platforms where C++ code may be difficult to compile.
|
|
Add `unwinding` as a permitted dependency of rustc, as it is now used as
part of panic unwinding within platforms such as Xous.
Signed-off-by: Sean Cross <sean@xobs.io>
|
|
str replacements
|
|
|
|
|
|
|
|
This removes the check to ensure that `rustfix` between
* src/tools/cargo
* src/tools/compiletest
has the same version,
since `rust-lang/rustfix` has migrated to under `rust-lang/cargo`.
|
|
When we encounter a function with a return type that has an anonymous
lifetime with no argument to borrow from, besides suggesting the
`'static` lifetime we now also suggest changing the arguments to be
borrows or changing the return type to be an owned type.
```
error[E0106]: missing lifetime specifier
--> $DIR/variadic-ffi-6.rs:7:6
|
LL | ) -> &usize {
| ^ expected named lifetime parameter
|
= help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from
help: consider using the `'static` lifetime, but this is uncommon unless you're returning a borrowed value from a `const` or a `static`
|
LL | ) -> &'static usize {
| +++++++
help: instead, you are more likely to want to change one of the arguments to be borrowed...
|
LL | x: &usize,
| +
help: ...or alternatively, to want to return an owned value
|
LL - ) -> &usize {
LL + ) -> usize {
|
```
Fix #85843.
|
|
Apply structured suggestion that allows test to work since 1.64
Close #73497.
|
|
Subtree update of `rust-analyzer`
r? `@HKalbasi`
|
|
|
|
|
|
implements https://github.com/rust-lang/rust/pull/117632#issuecomment-1795027801 suggestion
|
|
Update ICU4X
This updates all ICU4X crates and regenerates rustc_baked_icu_data.
Since the new unicode license under which they are licensed does not have an SPDX identifier yet, we define some exceptions. The license has to be reviewed to make sure it is still fine to use here, but I assume that is the case.
I also added an exception for rustc_icu_data to the unexplained ignore doctest tidy lint. This is a bit hacky but the whole style.rs in tidy is a mess so I didn't want to touch it more than this small hack.
part of #112865
r? `@davidtwco` `@wesleywiser` `@Manishearth`
|
|
drop num_cpus from rust-installer as not used
update rayon, rayon-core, which drops it's deps on num_cpus and crossbeam-channel (for bootstrap too) (https://github.com/rayon-rs/rayon/blob/v1.8.0/RELEASES.md)
update erro, which drops errno-dragonfly (https://github.com/lambda-fairy/rust-errno/blob/5341791935df601306ffc57a665763c4ecd72755/CHANGELOG.md)
|
|
Close #73497.
|
|
This updates all ICU4X crates and regenerates rustc_baked_icu_data.
Since the new unicode license under which they are licensed does not
have an SPDX identifier yet, we define some exceptions. The license has
to be reviewed to make sure it is still fine to use here, but I assume
that is the case.
I also added an exception for rustc_icu_data to the unexplained ignore
doctest tidy lint. This is a bit hacky but the whole style.rs in tidy is
a mess so I didn't want to touch it more than this small hack.
|
|
enable parallel rustc front end in nightly builds
Refers to the [MCP](https://github.com/rust-lang/compiler-team/issues/681), this pr does:
1. Enable the parallel front end in nightly builds, and keep the default number of threads as 1. Then users can use the parallel rustc front end via -Z threads=n option.
2. Set it up to serial front end for beta/stable builds via bootstrap.
3. Switch over the alt builders from parallel rustc to serial, so we have artifacts without parallel to test against the artifacts with parallel.
r? `@oli-obk`
cc `@cjgillot` `@nnethercote` `@bjorn3` `@Kobzol`
|
|
|
|
Update cargo
8 commits in b4d18d4bd3db6d872892f6c87c51a02999b80802..65e297d1ec0dee1a74800efe600b8dc163bcf5db
2023-10-31 18:19:10 +0000 to 2023-11-03 20:56:31 +0000
- fix(cli): Clarify --test is for targets, not test functions (rust-lang/cargo#12915)
- Updating "features" documentation to add a note about the new limit on number of features (rust-lang/cargo#12913)
- fix: merge `trim-paths` from different profiles (rust-lang/cargo#12908)
- Add regression test for issue 6915: features and transitive dev deps (rust-lang/cargo#12907)
- chore(deps): update rust crate gix to 0.55.2 (rust-lang/cargo#12906)
- chore(deps): update compatible (rust-lang/cargo#12905)
- docs(ref): Fix open-semver-range issue link (rust-lang/cargo#12904)
- docs(ref): Highlight commands to answer dep resolution questions (rust-lang/cargo#12903)
r? ghost
|
|
Remove license exception of `byteyarn` as it is no longer used
|
|
Run tidy license checker on more workspaces
The license checker didn't run on several workspaces before this PR. The same applied to the "external package sources" check. There were also two missing lockfiles which I have added now.
|
|
|
|
|
|
tidy: add unit tests for alphabetical checks
I discovered there aren't any tests while working on #117068.
r? `@Nilstrieb`
|
|
|
|
This requires introducing `tidy_error_ext!` as an alternative to
`tidy_error!`. It is passed a closure that is called for an error. This
lets tests capture tidy error messages in a buffer instead of printing
them to stderr.
It also requires pulling part of `check` out into a new function
`check_lines`, so that tests can pass in an iterator over some strings
instead of a file.
|
|
- Tweak some comments.
- No need to do the `concat!` trick on `START_MARKER` because it's
immediately followed by `END_MARKER`.
- Fix an off-by-one error in the line number for an error message.
- When a second start marker is found without an intervening end marker,
after giving an error, treat it as though it ends the section. It's
hard to know exactly what to do in this case, but it makes unit
testing this case a little simpler (in the next commit).
- If an end marker occurs without a preceding start marker, issue an
error.
|
|
These are comment lines in `Cargo.toml` files.
But exclude lines starting with `#!` from the skipping, because we want
to check them. (Rust `#![feature(...)]` lines.)
Also allow empty lines, which are occasionally useful.
|
|
Currently, if a `tidy-alphabetical-end` marker appears on the last line
of a file, tidy will erroneously issue a "reach end of file expecting
`tidy-alphabetical-end`" error. This is because it uses `take_while`
within `check_section`, which consumes the line with the end marker, and
then after `check_section` returns `check` peeks for at least one more
line, which won't be there is the marker was on the last line.
This commit fixes the problem, by removing the use of `take_while`, and
doing the "reached end of file" test within `check_section` without
using `peek`.
It also renames `{START,END}_COMMENT` as `{START,END}_MARKER`, which is
a more appropriate name.
|
|
|
|
|
|
Use tidy to enforce alphabetical dependency ordering
I get annoyed when dependencies in `Cargo.toml` files are not in alphabetical order. The [style guide](https://github.com/rust-lang/rust/blob/master/src/doc/style-guide/src/cargo.md) agrees with me.
There are ongoing efforts to provide linting/formatting of `Cargo.toml` files, e.g. https://github.com/rust-lang/rustfmt/pull/5240, https://crates.io/crates/cargo-toml-lint, and https://github.com/TimonPost/cargo-toml-format. But it's far from clear what's the right approach.
So this PR does something very simple: it uses the order checking already present in tidy. This allows incremental application of ordering, starting right now, and avoiding the need for any kind of all-at-once conversion.
If we do end up using some more comprehensive `Cargo.toml` linting/formatting solution in the future, the `tidy-alphabetical` lines will be easy to remove.
r? `@wesleywiser`
|
|
It's a better name, and lets "active features" refer to the features
that are active in a particular program, due to being declared or
enabled by the edition.
The commit also renames `Features::enabled` as `Features::active` to
match this; I changed my mind and have decided that "active" is a little
better thatn "enabled" for this, particularly because a number of
pre-existing comments use "active" in this way.
Finally, the commit renames `Status::Stable` as `Status::Accepted`, to
match `ACCEPTED_FEATURES`.
|
|
|
|
|
|
|
|
Otherwise the results may be outdated compared to a build at a later
time. Also disable checking for the backtrace workspace until Cargo.lock
is committed.
|
|
|
|
|
