| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
rustc_plugin: Remove support for syntactic plugins
This part of the plugin interface was successfully replaced by token-based procedural macros in theory and in practice.
cc https://github.com/rust-lang/rust/issues/29597
cc https://github.com/rust-lang/rust/pull/64675
r? @Centril
|
|
Rework raw ident suggestions
Use heuristics to determine whethersuggesting raw identifiers is
appropriate.
Account for raw identifiers when printing a path in a `use` suggestion.
Fix #66126.
|
|
|
|
parser: recover on nested ADTs as enum variants
Closes: https://github.com/rust-lang/rust/issues/66127
|
|
Scope format! temporaries
This places the temporaries that `format!` generates to refer to its arguments (through `&dyn Trait`) in a short-lived scope surrounding just the invocation of `format!`. This enables `format!` to be used in generators without the temporaries preventing the generator from being `Send` (due to `dyn Trait` not being `Sync`).
See rust-lang/rust#64477 for details.
|
|
Use heuristics to determine whethersuggesting raw identifiers is
appropriate.
Account for raw identifiers when printing a path in a `use` suggestion.
|
|
r=GuillaumeGomez
rustdoc: Mark `--extern-private` as unstable
It's not even stable in rustc so it shouldn't be stable in rustdoc.
r? @kinnison
|
|
Point at type in `let` assignment on type errors
Fix #61067.
|
|
Stabilize cfg(doc)
cc #43781.
|
|
r=michaelwoerister
debuginfo: Support for std::collections::Hash* in windows debuggers.
Okay, I finally needed to debug code involving a HashMap! Added support for HashSet s as well.
r? @michaelwoerister
### Local Testing
Verified these are passing locally:
```cmd
:: cmd.exe
python x.py test --stage 1 --build x86_64-pc-windows-msvc src/test/debuginfo
python x.py test --stage 1 --build i686-pc-windows-msvc src/test/debuginfo
python x.py test --stage 1 src/tools/tidy
:: MinGW MSYS2
./x.py test --stage 1 --build x86_64-pc-windows-gnu src/test/debuginfo
```
### Related Issues
* https://github.com/rust-lang/rust/issues/36503
* https://github.com/rust-lang/rust/issues/40460
* https://github.com/rust-gamedev/wg/issues/20
|
|
|
|
Enable `if` and `match` in constants behind a feature flag
This PR is an initial implementation of #49146. It introduces a `const_if_match` feature flag and does the following if it is enabled:
- Allows `Downcast` projections, `SwitchInt` terminators and `FakeRead`s for matched places through the MIR const-checker.
- Allows `if` and `match` expressions through the HIR const-checker.
- Stops converting `&&` to `&` and `||` to `|` in `const` and `static` items.
As a result, the following operations are now allowed in a const context behind the feature flag:
- `if` and `match`
- short circuiting logic operators (`&&` and `||`)
- the `assert` and `debug_assert` macros (if the `const_panic` feature flag is also enabled)
However, the following operations remain forbidden:
- `while`, `loop` and `for` (see #52000)
- the `?` operator (calls `From::from` on its error variant)
- the `assert_eq` and `assert_ne` macros, along with their `debug` variants (calls `fmt::Debug`)
This PR is possible now that we use dataflow for const qualification (see #64470 and #66385).
r? @oli-obk
cc @rust-lang/wg-const-eval @eddyb
|
|
It's not even stable in rustc so it shouldn't be stable in rustdoc.
|
|
Handle statics in MIR as const pointers
This is the first PR towards the goal of removing `PlaceBase::Static`. In this PR:
* Statics are lowered to dereferencing a const pointer.
* The temporaries holding such pointers are tracked in MIR, for the most part this is only used for diagnostics. There are two exceptions:
* The borrow checker has some checks for thread-locals that directly use this data.
* Const checking will suppress "cannot dereference raw pointer" diagnostics for pointers to `static mut`/`extern static`. This is to maintain the current behaviour (12 tests fail otherwise).
The following are left to future PRs (I think that @spastorino will be working on the first 3):
* Applying the same treatments to promoted statics.
* Removing `PlaceBase::Static`.
* Replacing `PlaceBase` with `Local`.
* Moving the ever growing collection of metadata that we have for diagnostics in MIR passes somewhere more appropriate.
r? @oli-obk
|
|
Remove pretty printing of specific nodes in AST
The ability to print a specific item as identified by NodeId or path
seems not particularly useful, and certainly carries quite a bit of
complexity with it.
This is intended to simplify our CLI parsing a bit and remove a
non-uncomplicated piece of it; I largely did this to remove the
dependency on NodeId from librustc/session but it's not really
necessary to do so in this invasive a way. The alternative is
moving it to librustc_interface or driver, probably.
|
|
*Syntactically* permit visibilities on trait items & enum variants
Fixes #65041
Suppose we have `$vis trait_item` or `$vis enum_variant` and `$vis` is a `:vis` macro fragment. Before this PR, this would fail to parse. This is now instead allowed as per language team consensus in https://github.com/rust-lang/rust/issues/65041#issuecomment-538105286. (See added tests for elaboration.)
Moreover, we now also permit visibility modifiers on trait items & enum variants *syntactically* but reject them with semantic checks (in `ast_validation`):
```rust
#[cfg(FALSE)]
trait Foo { pub fn bar(); } // OK
#[cfg(FALSE)]
enum E { pub U } // OK
```
|
|
Move process_configure_mod to rustc_parse
This removes the hack in favor of perhaps a less principled, but less painful, approach.
This also supports my work to decouple `Session` from librustc, as `ParseSess` currently has `Attribute` as "part" of it but after this PR will no longer do so.
|
|
Support multiple revisions in `compiletest`
The `//[X]~` syntax filters errors for tests that are run across multiple cfgs with `// revisions:`. This commit extends that syntax to accept `//[X,Y]~`, which will match multiple cfgs to the same error annotation. This is functionally the same as writing two comments, `//[X]~` and `//[Y]~`, but can fit on a single line.
While refactoring `compiletest` to support this, I also uncovered a small bug that was causing an incremental test to always pass, despite no errors being emitted.
r? @Centril
|
|
|
|
This creates a new test directory, `ui/consts/control-flow` to hold
tests related to control flow in a const context. It also blesses all
existing tests with the new error messages, and adds new tests for the
`const_if_match` feature.
|
|
[mir-opt] asking `?`s in a more optimized fashion
This PR works towards https://github.com/rust-lang/rust/issues/66234 by providing two optimization passes meant to run in sequence:
- `SimplifyArmIdentity` which transforms something like:
```rust
_LOCAL_TMP = ((_LOCAL_1 as Variant ).FIELD: TY );
((_LOCAL_0 as Variant).FIELD: TY) = move _LOCAL_TMP;
discriminant(_LOCAL_0) = VAR_IDX;
```
into:
```rust
_LOCAL_0 = move _LOCAL_1
```
- `SimplifyBranchSame` which transforms `SwitchInt`s to identical basic blocks into a `goto` to the first reachable target.
Together, these are meant to simplify the following into just `res`:
```rust
match res {
Ok(x) => Ok(x),
Err(x) => Err(x),
}
```
It should be noted however that the desugaring of `?` includes a function call and so the first pass in this PR relies on inlining to substitute that function call for identity on `x`. Inlining requires `mir-opt-level=2` so this might not have any effect in perf-bot but let's find out.
r? @oli-obk -- This is WIP, but I'd appreciate feedback. :)
|
|
|
|
This test does not actually emit any warnings, since
`#![allow(warnings)]` was specified. `compiletest` was erroneously
ignoring `//~` tests and looking only for `//[X]~` ones. As a result of
the changes in the previous commit, we now look for `//~` comments in
incremental tests and expect them to appear in *all* revisions.
|
|
Aggregation of drive-by cosmetic changes for trait-upcasting PR
Cherry-picked from #60900.
As requested by @Centril (and @nikomatsakis, I believe).
r? @Centril
|
|
|
|
|
|
This optimization depends on inlining for the identity
conversions introduced by the lowering of the `?`.
To take advantage of `SimplifyArmIdentity`, `-Z mir-opt-level=2`
is required because that triggers the inlining MIR optimization.
|
|
|
|
Specific labels when referring to "expected" and "found" types
|
|
|
|
|
|
Suggest to add lifetime constraint at explicit ouput of functions
Closes #62097
|
|
|
|
|
|
Also remove `never_type` the feature-gate test.
|
|
|
|
The previous commit removes the use of this, and now we cleanup.
|
|
pnkfelix:issue-66568-ignore-reproducible-build-2-on-macos, r=alexcrichton
Ignore run-make reproducible-build-2 on Mac
Ignore run-make reproducible-build-2 on Mac (we already ignore it on Windows).
Until we can dedicate resources to fixing this properly, I think we are best off just ignoring this test on platforms/contexts where it does not matter as much.
cc #66568
|
|
Avoid ICE when `break`ing to an unreachable label
Fix #62480.
|
|
Making ICEs and test them in incremental
This adds:
- A way to make the compiler ICE
- A way to check for ICE in `cfail` tests with `should-ice`
- A regression test for issue #65401
I am not sure the attribute added `should-ice` is the best for this job
|
|
The ability to print a specific item as identified by NodeId or path
seems not particularly useful, and certainly carries quite a bit of
complexity with it.
|
|
Rollup of 8 pull requests
Successful merges:
- #65665 (Update Source Code Pro and include italics)
- #66478 (rustc_plugin: Remove the compatibility shim)
- #66497 (Fix #53820)
- #66526 (Add more context to `async fn` trait error)
- #66532 (Generate DWARF address ranges for faster lookups)
- #66546 (Remove duplicate function)
- #66548 ([RISCV] Disable Atomics on all Non-A RISC-V targets)
- #66553 (remove HermitCore leftovers from sys/unix)
Failed merges:
r? @ghost
|
|
Until we can dedicate resources to fixing this properly, I think we are
best off just ignoring this test on platforms/contexts where it does not
matter as much.
|
|
Add more context to `async fn` trait error
Follow up to #65937. Fix #65899.
|
|
Fix #53820
This fixes ICE #53820 by being more clever when matching large arrays with slice patterns.
In particular, it avoids treating large arrays like large tuples, and instead reuses the `VarLenSlice` constructor behaviour to only consider as little values as needed.
As a side-effect, such matches also get improved diagnostics, by reporting `[true, ..]` missing instead of `[true, _, _, _, _, _, _, _]`.
|
|
Do not ICE on trait aliases with missing obligations
Fix #65673.
|
|
Generic arg disambiguation
Using the tactic suggested by @petrochenkov in https://github.com/rust-lang/rust/issues/60804#issuecomment-516769465 and on [zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/generic.20argument.20disambiguation), this change checks type arguments to see if they are really incorrectly-parsed const arguments.
it should be noted that `segments.len() == 1 && segments[0].arg.is_none()` was reduced to `segments.len() == 1` as suggested by @petrochenkov in [zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/generic.20argument.20disambiguation/near/177848002). This change allowed a few more existing tests to have their braces removed.
There are a couple of "problems" with these changes that I should note. First, there was a regression in the error messages found in "src/test/ui/privacy-ns1.rs" and "src/test/ui/privacy-ns1.rs". Second, some braces were unable to be removed from "src/test/ui/const-generics/fn-const-param-infer.rs". Those on line 24 caused the statement to stop equating when removed, and those on line 20 cause a statement that should not equate to produce no error when removed.
I have not looked further into any of these issues yet, though I would be willing to look into them before landing this. I simply wanted to get some other eyes on this before going further.
Fixes #60804
cc @varkor @jplatte
|
|
resolve: Give derive helpers highest priority during resolution
So they just shadow everything else and don't create ambiguity errors.
This matches the old pre-#64694 behavior most closely.
---
The change doesn't apply to this "compatibility" case
```rust
#[trait_helper] // The helper attribute is used before it introduced.
// Sadly, compiles on stable, supported via hacks.
// I plan to make a compatibility warning for this.
#[derive(Trait)]
struct S;
```
, such attributes still create ambiguities, but #64694 didn't change anything for this case.
Fixes https://github.com/rust-lang/rust/issues/66508
Fixes https://github.com/rust-lang/rust/issues/66525
|
|
Add explanation message for E0641
Part of #61137
|
