| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
This map is calculated in resolve, but we want to be sure to track it for
incremental compliation. Hide it behind a query to get more refactorings later.
|
|
|
|
incr.comp.: Cache Hir-DepNodeIndices in the HIR map.
In preparation for red/green. This should also be faster than before without any additional memory cost.
r? @nikomatsakis
|
|
Desugar parenthesized generic arguments in HIR
Fixes ICE in https://github.com/rust-lang/rust/issues/43431 and maybe some other similar issues.
r? @eddyb
|
|
|
|
|
|
Generate builtin impls for `Clone`
This fixes a long-standing ICE and limitation where some builtin types implement `Copy` but not `Clone` (whereas `Clone` is a super trait of `Copy`).
However, this PR has a few side-effects:
* `Clone` is now marked as a lang item.
* `[T; N]` is now `Clone` if `T: Clone` (currently, only if `T: Copy` and for `N <= 32`).
* `fn foo<'a>() where &'a mut (): Clone { }` won't compile anymore because of how bounds for builtin traits are handled (e.g. same thing currently if you replace `Clone` by `Copy` in this example). Of course this function is unusable anyway, an error would pop as soon as it is called.
Hence, I'm wondering wether this PR would need an RFC...
Also, cc-ing @nikomatsakis, @arielb1.
Related issues: #28229, #24000.
|
|
|
|
|
|
|
|
Fixes #28229.
Fixes #24000.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TypeckTables.
|
|
|
|
|
|
Some assorted region hashing fixes.
This PR contains three changes.
1. It changes what we implement `HashStable` for. Previously, the trait was implemented for things in the local `TyCtxt`. That was OK, since we only invoked hashing with a `TyCtxt<'_, 'tcx, 'tcx>` where there is no difference. With query result hashing this becomes a problem though. So we now implement `HashStable` for things in `'gcx`.
2. The PR makes the regular `HashStable` implementation *not* anonymize late-bound regions anymore. It's a waste of computing resources and it's not clear that it would always be correct to do so.
3. The PR adds an option for stable hashing to treat all regions as erased and uses this new option when computing the `TypeId`. This should help with https://github.com/rust-lang/rust/issues/41875.
I did not add a test case for (3) since that's not possible yet. But it looks like @zackmdavis has something in the pipeline there `:)`.
r? @eddyb
|
|
|
|
|
|
|
|
In preparation for incremental compilation this commit refactors the lint
handling infrastructure in the compiler to be more "eager" and overall more
incremental-friendly. Many passes of the compiler can emit lints at various
points but before this commit all lints were buffered in a table to be emitted
at the very end of compilation. This commit changes these lints to be emitted
immediately during compilation using pre-calculated lint level-related data
structures.
Linting today is split into two phases, one set of "early" lints run on the
`syntax::ast` and a "late" set of lints run on the HIR. This commit moves the
"early" lints to running as late as possible in compilation, just before HIR
lowering. This notably means that we're catching resolve-related lints just
before HIR lowering. The early linting remains a pass very similar to how it was
before, maintaining context of the current lint level as it walks the tree.
Post-HIR, however, linting is structured as a method on the `TyCtxt` which
transitively executes a query to calculate lint levels. Each request to lint on
a `TyCtxt` will query the entire crate's 'lint level data structure' and then go
from there about whether the lint should be emitted or not.
The query depends on the entire HIR crate but should be very quick to calculate
(just a quick walk of the HIR) and the red-green system should notice that the
lint level data structure rarely changes, and should hopefully preserve
incrementality.
Overall this resulted in a pretty big change to the test suite now that lints
are emitted much earlier in compilation (on-demand vs only at the end). This in
turn necessitated the addition of many `#![allow(warnings)]` directives
throughout the compile-fail test suite and a number of updates to the UI test
suite.
|
|
|
|
APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.
As part of the CTFE initiative, we're forced to find a solution for floating-point operations.
By design, IEEE-754 does not explicitly define everything in a deterministic manner, and there is some variability between platforms, at the very least (e.g. NaN payloads).
If types are to evaluate constant expressions involving type (or in the future, const) generics, that evaluation needs to be *fully deterministic*, even across `rustc` host platforms.
That is, if `[T; T::X]` was used in a cross-compiled library, and the evaluation of `T::X` executed a floating-point operation, that operation has to be reproducible on *any other host*, only knowing `T` and the definition of the `X` associated const (as either AST or HIR).
Failure to uphold those rules allows an associated type (e.g. `<Foo as Iterator>::Item`) to be seen as two (or more) different types, depending on the current host, and such type safety violations typically allow writing of a `transmute` in safe code, given enough generics.
The options considered by @rust-lang/compiler were:
1. Ban floating-point operations in generic const-evaluation contexts
2. Emulate floating-point operations in an uniformly deterministic fashion
The former option may seem appealing at first, but floating-point operations *are allowed today*, so they can't be banned wholesale, a distinction has to be made between the code that already works, and future generic contexts. *Moreover*, every computation that succeeded *has to be cached*, otherwise the generic case can be reproduced without any generics. IMO there are too many ways it can go wrong, and a single violation can be enough for an unsoundness hole.
Not to mention we may end up really wanting floating-point operations *anyway*, in CTFE.
I went with the latter option, and seeing how LLVM *already* has a library for this exact purpose (as it needs to perform optimizations independently of host floating-point capabilities), i.e. `APFloat`, that was what I ended up basing this PR on.
But having been burned by the low reusability of bindings that link to LLVM, and because I would *rather* the floating-point operations to be wrong than not deterministic or not memory-safe (`APFloat` does far more pointer juggling than I'm comfortable with), I decided to RIIR.
This way, we have a guarantee of *no* `unsafe` code, a bit more control over the where native floating-point might accidentally be involved, and non-LLVM backends can share it.
I've also ported all the testcases over, *before* any functionality, to catch any mistakes.
Currently the PR replaces all CTFE operations to go through `apfloat::ieee::{Single,Double}`, keeping only the bits of the `f32` / `f64` memory representation in between operations.
Converting from a string also double-checks that `core::num` and `apfloat` agree on the interpretation of a floating-point number literal, in case either of them has any bugs left around.
r? @nikomatsakis
f? @nagisa @est31
<hr/>
Huge thanks to @edef1c for first demoing usable `APFloat` bindings and to @chandlerc for fielding my questions on IRC about `APFloat` peculiarities (also upstreaming some bugfixes).
|
|
Add MIR Validate statement
This adds statements to MIR that express when types are to be validated (following [Types as Contracts](https://internals.rust-lang.org/t/types-as-contracts/5562)). Obviously nothing is stabilized, and in fact a `-Z` flag has to be passed for behavior to even change at all.
This is meant to make experimentation with Types as Contracts in miri possible. The design is definitely not final.
Cc @nikomatsakis @aturon
|
|
|
|
default binding modes: add pat_binding_modes
This PR kicks off the implementation of the [default binding modes RFC][1] by
introducing the `pat_binding_modes` typeck table mentioned in the [mentoring
instructions][2].
It is a WIP because I wasn't able to avoid all uses of the binding modes as
not all call sites are close enough to the typeck tables. I added marker
comments to any line matching `BindByRef|BindByValue` so that reviewers
are aware of all of them.
I will look into changing the HIR (as suggested in [2]) to not carry a
`BindingMode` unless one was explicitly specified, but this PR is good for
a first round of comments.
The actual changes are quite small and CI will fail due to overlong lines
caused by the marker comments.
See #42640.
cc @nikomatsakis
[1]: https://github.com/rust-lang/rfcs/pull/2005
[2]: https://github.com/rust-lang/rust/issues/42640#issuecomment-313535089
|
|
This PR kicks off the implementation of the [default binding modes RFC][1] by
introducing the `pat_binding_modes` typeck table mentioned in the [mentoring
instructions][2].
`pat_binding_modes` is populated in `librustc_typeck/check/_match.rs` and
used wherever the HIR would be scraped prior to this PR. Unfortunately, one
blemish, namely a two callers to `contains_explicit_ref_binding`, remains.
This will likely have to be removed when the second part of [1], the
`pat_adjustments` table, is tackled. Appropriate comments have been added.
See #42640.
[1]: https://github.com/rust-lang/rfcs/pull/2005
[2]: https://github.com/rust-lang/rust/issues/42640#issuecomment-313535089
|
|
Cleanup some remains of `hr_lifetime_in_assoc_type` compatibility lint
r? @nikomatsakis
|
|
|
|
different Lvalue type
|
|
This matters if the lvalues that is suspended involves Deref'ing a reference --
that reference's lifetime will then not be in the type any more
|
|
when we can rely on them being locked in memory
|
|
|
|
No need to be mixed!
|
|
|
|
|
|
|
|
|
