| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
bound that is likely to change. In that case, it will change to 'static,
so then scan down the graph to see whether there are any hard
constraints that would prevent 'static from being a valid value
here. Report a warning.
|
|
region-bound is expected to change in Rust 1.3, but don't use it for
anything in this commit. Note that this is not a "significant" part of
the type (it's not part of the formal model) so we have to normalize
this away or trans starts to get confused because two equal types wind
up with distinct LLVM types.
|
|
for now.
|
|
This pull request removes `ParamBounds` a old holdover in the type checker that we (@nikomatsakis and I) had wanted to remove. I'm not sure if the current form is the best possible refactor but I figured we can use this as a place to discuss it.
r? @nikomatsakis
|
|
|
|
|
|
|
|
Regressed by #26326
|
|
|
|
Previously it also tried to find out the best way to translate the
expression, which could ICE during type-checking.
Fixes #23173
Fixes #24322
Fixes #25757
|
|
Expand the "givens" set to cover transitive relations. The givens array
stores relationships like `'c <= '0` (where `'c` is a free region and
`'0` is an inference variable) that are derived from closure
arguments. These are (rather hackily) ignored for purposes of inference,
preventing spurious errors. The current code did not handle transitive
cases like `'c <= '0` and `'0 <= '1`. Fixes #24085.
r? @pnkfelix
cc @bkoropoff
*But* I am not sure whether this fix will have a compile-time hit. I'd like to push to try branch observe cycle times.
|
|
stores relationships like `'c <= '0` (where `'c` is a free region and
`'0` is an inference variable) that are derived from closure
arguments. These are (rather hackily) ignored for purposes of inference,
preventing spurious errors. The current code did not handle transitive
cases like `'c <= '0` and `'0 <= '1`. Fixes #24085.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes #25700.
|
|
associated types are involved.
|
|
|
|
r=pcwalton
When we successfully resolve a trait reference with no type/lifetime parameters, like `i32: Foo` or `Box<u32>: Sized`, this is in fact globally true. This patch adds a simple global to the tcx to cache such cases. The main advantage of this is really about caching things like `Box<Vec<Foo>>: Sized`. It also points to the need to revamp our caching infrastructure -- the current caches make selection cost cheaper, but we still wind up paying a high cost in the confirmation process, and in particular unrolling out dependent obligations. Moreover, we should probably do caching more uniformly and with a key that takes the where-clauses into account. But that's for later.
For me, this shows up as a reasonably nice win (20%) on Servo's script crate (when built in dev mode). This is not as big as my initial measurements suggested, I think because I was building my rustc with more debugging enabled at the time. I've not yet done follow-up profiling and so forth to see where the new hot spots are. Bootstrap times seem to be largely unaffected.
cc @pcwalton
This is technically a [breaking-change] in that functions with unsatisfiable where-clauses may now yield errors where before they may have been accepted. Even before, these functions could never have been *called* by actual code. In the future, such functions will probably become illegal altogether, but in this commit they are still accepted, so long as they do not rely on the unsatisfiable where-clauses. As before, the functions still cannot be called in any case.
|
|
Rebase of #21468.
Fix #25960.
|
|
|
|
|
|
again, do it once and then just remember the expanded form. At the same
time, filter globally nameable predicates out of the environment, since
they can cause cache errors (and they are not necessary in any case).
|
|
that are known to have been satisfied *somewhere*. This means that if
one fn finds that `SomeType: Foo`, then every other fn can just consider
that to hold.
Unfortunately, there are some complications:
1. If `SomeType: Foo` includes dependent conditions, those conditions
may trigger an error. This error will be repored in the first fn
where `SomeType: Foo` is evaluated, but not in the other fns, which
can lead to uneven error reporting (which is sometimes confusing).
2. This kind of caching can be unsound in the presence of
unsatisfiable where clauses. For example, suppose that the first fn
has a where-clause like `i32: Bar<u32>`, which in fact does not
hold. This will "fool" trait resolution into thinking that `i32:
Bar<u32>` holds. This is ok currently, because it means that the
first fn can never be calle (since its where clauses cannot be
satisfied), but if the first fn's successful resolution is cached, it
can allow other fns to compile that should not. This problem is fixed
in the next commit.
|
|
|
|
Arrays and slices are closely related, but not that closely; making the
separation more explicit is generally more clear.
|
|
Use camel-case naming, and use names which actually make sense in modern Rust.
|
|
Pull request for #26188.
|
|
|
|
|
|
- Successful merges: #26142, #26143, #26145, #26146, #26164, #26174
- Failed merges:
|
|
Using two terms for one thing is confusing, these are called 'raw pointers' today.
|
|
Still some references left to this old term, I've updated them to say boxes.
Related to #25851
|
|
Gets libsyntax one step closer to running on stable (see #24518).
Closes #24757, erickt's previous attempt at this.
|
|
Closes #15609
|
|
Before:
581.72user 4.75system 7:42.74elapsed 126%CPU (0avgtext+0avgdata 1176224maxresident)k
llvm took 359.183
After:
550.63user 5.09system 7:20.28elapsed 126%CPU (0avgtext+0avgdata 1165516maxresident)k
llvm took 354.801
|
|
|
