| Age | Commit message (Collapse) | Author | Lines |
|---|
|
predecessors cache
|
|
|
|
invalidate cache when accessing unique terminator
|
|
|
|
predecessors_for to slice
|
|
|
|
Miri engine: proper support for `Assert` MIR terminators
This puts down the basis for https://github.com/rust-lang/miri/issues/1070, and I also did some clean-up. The Miri side of this is at https://github.com/rust-lang/miri/pull/1084.
r? @oli-obk
|
|
|
|
Conditional compilation for sanitizers
Configure sanitize option when compiling with a sanitizer to make
it possible to execute different code depending on whether given
sanitizer is enabled or not.
|
|
|
|
add reusable MachineStop variant to Miri engine error enum
Replace the Miri-tool-specific `Exit` error variant with something dynamically typed that all clients of the Miri engine can use.
r? @oli-obk
Cc https://github.com/rust-lang/rust/issues/66902
|
|
rustc: don't just show raw DefIndex's in BrNamed's fmt::Debug impl.
Context: these `fmt::Debug` impls only get used with `-Z verbose` (which some tests use).
I was going to print the path like in #66850 (or rather, use `DefId`'s `fmt::Debug`, which is close but not as nice), but then I realized that most of the `DefId`s were `crate0:DefIndex(0)`, i.e. the crate root.
As the crate root is not a lifetime, they're clearly dummies of some sort, and we don't have to print anything other than the name for them.
This means that out of all the tests, there's only 5 instances of `BrNamed` that now print the full path to the lifetime parameter, and everything else is shorter instead, which doesn't feel too bad.
cc @nikomatsakis
|
|
rustc_plugin: Remove some remaining plugin features
- Plugin arguments (`#![plugin(my_plugin(args))]`) are no longer supported.
- Registering additional plugins from command line (`-Z extra-plugins=my_plugin`) is no longer supported, `-Z crate-attr=plugin(my_plugin)` can be used instead.
- Lint `plugin_as_library` is removed as mostly useless now, when plugins exist as a compatibility feature with greatly reduced functionality.
- Plugins registering additional LLVM passes (`Registry::register_llvm_pass`) are no longer supported, `-C passes=my_passes` can be used instead.
r? @Centril
|
|
rustc: hide HirId's fmt::Debug output from -Z span_free_formats.
This replaces the only occurrences of `HirId {...}` from tests with paths, i.e.:
```rust
[closure@HirId { owner: DefIndex(4), local_id: 15 } q:&i32, t:&T]
```
becomes, after this PR:
```rust
[closure@foo<T>::{{closure}}#0 q:&i32, t:&T]
```
r? @oli-obk cc @michaelwoerister
|
|
rustc: move mir::SourceScopeLocalData to a field of SourceScopeData.
By having one `ClearCrossCrate<SourceScopeLocalData>` for each scope, as opposed to a single `ClearCrossCrate` for all the `SourceScopeLocalData`s, we can represent the fact that some scopes have `SourceScopeLocalData` associated with them, and some don't.
This is useful when doing MIR inlining across crates, because the `ClearCrossCrate` will be `Clear` for the cross-crate MIR scopes and `Set` for the local ones.
Also see https://github.com/rust-lang/rust/pull/66203#issuecomment-555589574 for some context around this approach.
Fixes #51314.
|
|
|
|
|
|
|
|
|
|
|
|
Configure sanitize option when compiling with a sanitizer to make
it possible to execute different code depending on whether given
sanitizer is enabled or not.
|
|
const_prop: detect and avoid catching Miri errors that require allocation
r? @wesleywiser @oli-obk
|
|
Use recursion_limit for const eval stack limit
cc https://github.com/rust-lang/miri/issues/643 @orium @RalfJung
I'm really not certain how exactly to handle this change, but it looks like it's that simple.
Reuse `recursion_limit` ("The maximum recursion limit for potentially infinitely recursive operations such as auto-dereference and monomorphization") which is configurable by the user for the const evaluation stack frame limit.
The other option is to make `const_eval_stack_frame_limit` configurable in the same way as `recursion_limit` (but I'm not sure how to do that and it'd be a bigger change).
Fixes https://github.com/rust-lang/miri/issues/643.
|
|
Improve lifetime errors with implicit trait object lifetimes
r? @matthewjasper
cc @estebank
I still think the ideal solution would be to construct a `BrAnon`, but that seems like a more invasive change, and can be done later. This at least gets rid of the hack in `OutliveSuggestion` and is slightly more principled.
|
|
Feature gating *declarations* => new crate `rustc_feature`
This PR moves the data-oriented parts of feature gating into its own crate, `rustc_feature`.
The parts consist of some data types as well as `accepted`, `active`, `removed`, and `builtin_attrs`.
Feature gate checking itself remains in `syntax::feature_gate::check`. The parts which define how to emit feature gate errors could probably be moved to `rustc_errors` or to the new `rustc_session` crate introduced in #66878. The visitor itself could probably be moved as a pass in `rustc_passes` depending on how the dependency edges work out.
The PR also contains some drive-by cleanup of feature gate checking. As such, the PR probably best read commit-by-commit.
r? @oli-obk
cc @petrochenkov
cc @Mark-Simulacrum
|
|
rustc_typeck: gate AnonConst's generics on feature(const_generics).
This PR employs the fix for #43408 when `#![feature(const_generics)]` is enabled, making the feature-gate the opt-in for all the possible breakage this may incur.
For example, if this PR lands, this will cause a cycle error (due to #60471):
```rust
#![feature(const_generics)]
fn foo<T: Into<[u8; 4]>>() {}
```
And so will anything with type-level const expressions, in its bounds.
Surprisingly, `impl`s don't seem to be affected (if they were, even libcore wouldn't compile).
One thing I'm worried about is not knowing how much unstable code out there, using const-generics, will be broken. But types like `Foo<{N+1}>` never really worked, and do after this PR, just not in bounds - so ironically, it's type-level const expressions that don't depend on generics, which will break (in bounds).
Also, if we do this, we'll have effectively blocked stabilization of const generics on #60471.
r? @oli-obk cc @varkor @yodaldevoid @nikomatsakis
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Record temporary static references in generator witnesses
Closes #66695
* Record the pointer to static's type in MIR.
* Normalize the static's type (so that constants can be compared correctly).
|
|
Handle GlobalCtxt directly from librustc_interface query system
This PR constructs the `GlobalCtxt` as a member of the `Queries` in librustc_interface.
This simplifies the code to construct it, at the expense of added complexity in the query control flow.
This allows to handle the arenas directly from librustc_interface.
Based on #66707
r? @Zoxc
|
|
Allow customising ty::TraitRef's printing behavior
This pr allows to explicitly choose which representation of `TraitRef` (`<T as Trait<U>>` or `Trait<U>`) you want to print. `Debug` and `Display` representations of `TraitRef` now match.
Closes #59188.
|
|
Async fn resume after completion
#65419 -- Attempting to run an async fn after completion mentions generators
Not yet ready for review - work in progress
Just need to run the tests on a proper build server
|
|
|
|
rustc_metadata: Privatize more things and a couple of other refactorings
This PR continues https://github.com/rust-lang/rust/pull/66496 and hits the point of diminishing returns.
All fields of `CrateRoot` and `CrateMetadata` are privatized.
For read-only fields this certainly makes sense, but for a few fields updateable from outside of `rmeta.rs` (mostly `creader.rs`) it was done mostly for consistency, I can make them `pub(crate)` again if requested.
`cstore.rs` (which became small after #66496) was merged into `creader.rs`.
A few things noticed while making the privacy changes were addressed in the remaining refactoring commits.
Fixes https://github.com/rust-lang/rust/issues/66550
r? @eddyb @Mark-Simulacrum
|
|
fix clippy
allow customising ty::TraitRef's printing behavior
fix clippy
stylistic fix
|
|
remove the 'dereferenceable' attribute from Box
Fixes https://github.com/rust-lang/rust/issues/66600
r? @eddyb @rkruppe
|
|
Apply proper commit from PR #63934
While working on PR #63934, I accidentally reverted to an older version
of the PR while working on a rebase. The PR was then merged, not with
the later, approved changes, but with earlier, unapproved changes.
This PR applies the changes that were *suppoesd* to be mereged in
PR #63934. All of the proper tests appear to have been merged
in PR #63934, so this PR adds no new tests
|
|
|
|
|
|
|
|
While working on PR #63934, I accidentally reverted to an older version
of the PR while working on a rebase. The PR was then merged, not with
the later, approved changes, but with earlier, unapproved changes.
This PR applies the changes that were *suppoesd* to be mereged in
PR #63934. All of the proper tests appear to have been merged
in PR #63934, so this PR adds no new tests
Fixes #66580
|
|
|
|
|
|
|
