| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Don't give APITs names with macro expansion placeholder fragments in it
The `DefCollector` previously called `pprust::ty_to_string` to construct a name for APITs (arg-position impl traits). The `ast::Ty` that was being formatted however has already had its macro calls replaced with "placeholder fragments", which end up rendering like `!()` (or ICEing, in the case of rust-lang/rust#140333, since it led to a placeholder struct field with no name).
Instead, collect the name of the APIT *before* we visit its macros and replace them with placeholders in the macro expander. This makes the implementation a bit more involved, but AFAICT there's no better way to do this since we can't do a reverse mapping from placeholder fragment -> original macro call AST.
Fixes rust-lang/rust#140333
|
|
tests: Do not run afoul of asm.validity.non-exhaustive in input-stats
This addresses one of the three powerpc64-unknown-linux-musl test failures in https://github.com/rust-lang/rust/issues/142280
I was motivated to cover it myself because technically this is also compile-time UB if we compile a program that has `asm!` with x86-64-specific instructions on another platform. That'll only mean something if this is ever switched to build-pass, or if checking emits object code, but conveniently "nop" is valid assembly on all platforms anyone has implemented Rust codegen for. Even the weird ones LLVM doesn't support, like PA-RISC or Common Intermediate Language.
...except GPUs. Not sure about those.
r? ```@nnethercote```
|
|
r=lolbinarycat
[rustdoc] Do not emit redundant_explicit_links lint if the doc comment comes from expansion
Fixes https://github.com/rust-lang/rust/issues/141553.
The problem was that we change the context for the attributes in some cases to get better error output, preventing us to detect if the attribute comes from expansion. Most of the changes are about keeping track of the "does this span comes from expansion" information.
r? ```@Manishearth```
|
|
r=lolbinarycat
[rustdoc] Do not emit redundant_explicit_links lint if the doc comment comes from expansion
Fixes https://github.com/rust-lang/rust/issues/141553.
The problem was that we change the context for the attributes in some cases to get better error output, preventing us to detect if the attribute comes from expansion. Most of the changes are about keeping track of the "does this span comes from expansion" information.
r? ```@Manishearth```
|
|
make `tidy-alphabetical` use a natural sort
The idea here is that these lines should be correctly sorted, even though a naive string comparison would say they are not:
```
foo2
foo10
```
This is the ["natural sort order"](https://en.wikipedia.org/wiki/Natural_sort_order).
There is more discussion in [#t-compiler/help > tidy natural sort](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/tidy.20natural.20sort/with/519111079)
Unfortunately, no standard sorting tools are smart enough to to this automatically (casting some doubt on whether we should make this change). Here are some sort outputs:
```
> cat foo.txt | sort
foo
foo1
foo10
foo2
mp
mp1e2
np",
np1e2",
> cat foo.txt | sort -n
foo
foo1
foo10
foo2
mp
mp1e2
np",
np1e2",
> cat foo.txt | sort -V
foo
foo1
foo2
foo10
mp
mp1e2
np1e2",
np",
```
Disappointingly, "numeric" sort does not actually have the behavior we want. It only sorts by numeric value if the line starts with a number. The "version" sort looks promising, but does something very unintuitive if you look at the final 4 values. None of the other options seem to have the desired behavior in all cases:
```
-b, --ignore-leading-blanks ignore leading blanks
-d, --dictionary-order consider only blanks and alphanumeric characters
-f, --ignore-case fold lower case to upper case characters
-g, --general-numeric-sort compare according to general numerical value
-i, --ignore-nonprinting consider only printable characters
-M, --month-sort compare (unknown) < 'JAN' < ... < 'DEC'
-h, --human-numeric-sort compare human readable numbers (e.g., 2K 1G)
-n, --numeric-sort compare according to string numerical value
-R, --random-sort shuffle, but group identical keys. See shuf(1)
--random-source=FILE get random bytes from FILE
-r, --reverse reverse the result of comparisons
--sort=WORD sort according to WORD:
general-numeric -g, human-numeric -h, month -M,
numeric -n, random -R, version -V
-V, --version-sort natural sort of (version) numbers within text
```
r? ```@Noratrieb``` (it sounded like you know this code?)
|
|
Simplify `ObligationCauseCode::IfExpression`
This originally started out as an experiment to do less incremental invalidation by deferring the span operations that happen on the good path in `check_expr_if`, but it ended up not helping much (or at least not showing up in our incremental tests).
As a side-effect though, I think the code is a lot cleaner and there are modest diagnostics improvements with overlapping spans, so I think it's still worth landing.
|
|
Suggest cloning `Arc` moved into closure
```
error[E0382]: borrow of moved value: `x`
--> $DIR/moves-based-on-type-capture-clause-bad.rs:9:20
|
LL | let x = "Hello world!".to_string();
| - move occurs because `x` has type `String`, which does not implement the `Copy` trait
LL | thread::spawn(move || {
| ------- value moved into closure here
LL | println!("{}", x);
| - variable moved due to use in closure
LL | });
LL | println!("{}", x);
| ^ value borrowed here after move
|
= note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider cloning the value before moving it into the closure
|
LL ~ let value = x.clone();
LL ~ thread::spawn(move || {
LL ~ println!("{}", value);
|
```
Fix rust-lang/rust#104232.
|
|
|
|
|
|
|
|
Only write join return value once join succeeds
|
|
|
|
Remove unnecesary uses of the 'current_func' field, replacing it with a call to function.
|
|
r=fee1-dead,WaffleLapkin
Add edition checks for some tests that had divergent output
In order to expose edition dependent divergences in some tests in the test suite, add explicit `edition` annotations. Some of these tests might require additional work to *avoid* the divergences, as they might have been unintentional. These are not exhaustive changes, purely opportunistic while I was looking at something else.
|
|
|
|
|
|
Salsa idiomize `VariantFields` query
|
|
|
|
fix: Prettify AST in `PathTransform` if it's coming from a macro
|
|
|
|
Parse new const trait syntax
|
|
|
|
Enforce in bootstrap that build must have stage at least 1
This PR is a step towards https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Proposal.20to.20cleanup.20stages.20and.20steps.20after.20the.20redesign/with/523586917. It's very hard or me to make self-contained changes to bootstrap at this moment, so this PR kind of does several things:
1) (first two commits) Try to reduce the usage of `Std::new` in bootstrap, and replace it with a `Builder::std` method (similar to `Builder::compiler`). This is mostly to remove executions of the `Std` step for stage 0, which doesn't make a lot of sense; I'd like to ideally have the invariant that when a step is invoked, it actually builds or does something. Eventually, I'd like for everything to go through `Builder::std`. (Note: I'm not totally married to this idea, if you don't like it, we can remove it from this PR. I mostly did it right now to remove stage 0 std steps from snapshot tests, which shouldn't be there, but we can also filter them out in a different way)
2) Make sure that when you pass `x build compiler`, only the `Assemble` root level step will be invoked, and not the `Rustc` step. Before, both were invoked, which actually ran `Rustc` twice, once with all `crates` filled, and once with no crates (but both actually represent the same situation). Since the `Rustc::make_run` step actually requests a compile that is one stage below it, this actually made `build compiler --stage 0` work, which we don't want to have anymore.
3) Enforce a bootstrap-global invariant that all `build` commands are always on stage `>=1`. If you try to `build` anything on stage 0, it will print a warning and exit bootstrap. This follows the intuition from the new staging rules after the stage redesign; artifacts that are "stage 0" come outside of bootstrap, and we can't really build something for which we don't have source (although we can still test it, but that's for another PR).
Now the logic for build should be quite simple. For pretty much everything except for `Std`, you first use the stage0 compiler to build stage 1. Then you can build a stage 2 <something> using the previously built stage 1 (and then you can continue to stage 3 etc.). And that's it. The default build stage for everything is 1 (modulo download-ci-rustc, but that's a separate can of worms).
The snapshot test infra isn't super nice at the moment, as one of next steps I want to create some simple Builder pattern that will allow us to configure the bootstrap invocations in a more "forward-compatible" way (e.g. now it's not possible to modify the config passed to `configure_with_args`).
There are some things not yet fully resolved for build stage 0:
1) Cargo is still a `ModeRustc` tool, even though it doesn't really have to be, it is buildable with the stage0 compiler
2) bootstrap tools (`opt-dist`, `build-manifest` etc.) are still called stage0 tools, and in the bootstrap output it says something like "stage 0 rustc builds stage 0 opt-dist". Which is a bit weird, but functionally there's no difference, it's just a slightly inconsistent output. We still haven't decided if we should make these tools ignore staging altogether (which is IMO the right choice) or if we want to allow building stage 1/2/3/... bootstrap tools.
r? `@jieyouxu`
try-job: x86_64-rust-for-linux
|
|
The name of the parameter changed from `op` to `val` in cbdcbf0d6a586792c5e0a0b8965a3179bac56120
|
|
|
|
to function.
|
|
Cleanup `provideCodeActions` vscode hook
|
|
|
|
|
|
|
|
feat: highlighting of return values while the cursor is on `match` / `if` / `=>`
|
|
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
Turn `stdarch` into a Josh subtree
In a similar vein as https://github.com/rust-lang/rust/pull/141229, this PR makes the `stdarch` repository a Josh subtree (it was previously a submodule). The initial commit of `stdarch` upon this is based is `5a7342fc16b208b1b16624e886937ed8509a6506`, which is the previous commit SHA of the `stdarch` submodule. The sync was performed according to https://hackmd.io/7pOuxnkdQDaL1Y1FQr65xg.
This was decided in https://github.com/rust-lang/stdarch/issues/1655.
Test pull PR on my fork: https://github.com/Kobzol/stdarch/pull/1
Test push PR on my fork: https://github.com/Kobzol/rust/pull/59
I plan to use the same Rust (miri-inspired) tooling that we use for `rustc-dev-guide` to enable pulls/pushes on stdarch.
Note that this repository currently doesn't have any stdarch-specific tests, so before that, the subtree should only be modified through this repository only when dealing with changes that contain "cyclical dependencies" between stdarch and rustc. The long term vision is to integrate stdarch into rust-lang/rust completely.
CC `@Amanieu`
try-job: aarch64-apple
try-job: aarch64-gnu
try-job: `x86_64-msvc-*`
try-job: x86_64-gnu
try-job: x86_64-gnu-aux
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
`match`, `if`, or match arm arrow (`=>`)
|
|
minor: Decrease minimal toolchain version for `comp-time-deps` to `1.89.0`
|
|
Rustc pull update
|
|
|
|
|
|
|
|
|
|
|
