| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
use fmt::Result where applicable
This is a quite boring PR, but I think the type alias improves readability, so why not use it?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
InternedString
|
|
|
|
|
|
|
|
|
|
|
|
Chalk wants to be able to pass these constraints around. Also, the
form we were using in our existing queries was not as general as we
are going to need.
|
|
Fixes #49690
|
|
Implement Chalk lowering rule Normalize-From-Impl
This extends the Chalk lowering pass with the "Normalize-From-Impl" rule for generating program clauses from a trait definition as part of #49177.
r? @nikomatsakis
|
|
Fix save-analysis generation with extern_in_paths/extern_absolute_paths
Fixes #48742.
|
|
|
|
Don't abort const eval due to long running evals, just warn
one check-box of #49930
r? @nagisa (https://github.com/rust-lang/rfcs/pull/2344#issuecomment-368246665)
|
|
|
|
|
|
|
|
Hygiene 2.0: Avoid comparing fields by name
There are two separate commits here (not counting tests):
- The first one unifies named (`obj.name`) and numeric (`obj.0`) field access expressions in AST and HIR. Before field references in these expressions are resolved it doesn't matter whether the field is named or numeric (it's just a symbol) and 99% of code is common. After field references are resolved we work with
them by index for all fields (see the second commit), so it's again not important whether the field was named or numeric (this includes MIR where all fields were already by index).
(This refactoring actually fixed some bugs in HIR-based borrow checker where borrows through names (`S {
0: ref x }`) and indices (`&s.0`) weren't considered overlapping.)
- The second commit removes all by-name field comparison and instead resolves field references to their indices once, and then uses those resolutions. (There are still a few name comparisons in save-analysis, because save-analysis is weird, but they are made correctly hygienic).
Thus we are fixing a bunch of "secondary" field hygiene bugs (in borrow checker, lints).
Fixes https://github.com/rust-lang/rust/issues/46314
|
|
|
|
Resolve them into field indices once and then use those resolutions
+ Fix rebase
|
|
|
|
union, and projection types. added a feature gate and tests for these scenarios.
|
|
|
|
|
|
|
|
Allow for re-using monomorphizations in upstream crates.
Followup to #48611. This implementation is pretty much finished modulo failing tests if there are any. Not quite ready for review yet though.
### DESCRIPTION
This PR introduces a `share-generics` mode for RLIBs and Rust dylibs. When a crate is compiled in this mode, two things will happen:
- before instantiating a monomorphization in the current crate, the compiler will look for that monomorphization in all upstream crates and link to it, if possible.
- monomorphizations are not internalized during partitioning. Instead they are added to the list of symbols exported from the crate.
This results in less code being translated and LLVMed. However, there are also downsides:
- it will impede optimization somewhat, since fewer functions can be internalized, and
- Rust dylibs will have bigger symbol tables since they'll also export monomorphizations.
Consequently, this PR only enables the `shared-generics` mode for opt-levels `No`, `Less`, `Size`, and `MinSize`, and for when incremental compilation is activated. `-O2` and `-O3` will still generate generic functions per-crate.
Another thing to note is that this has a somewhat similar effect as MIR-only RLIBs, in that monomorphizations are shared, but it is less effective because it cannot share monomorphizations between sibling crates:
```
A <--- defines `fn foo<T>() { .. }`
/ \
/ \
B C <--- both call `foo<u32>()`
\ /
\ /
D <--- calls `foo<u32>()` too
```
With `share-generics`, both `B` and `C` have to instantiate `foo<u32>` and only `D` can re-use it (from either `B` or `C`). With MIR-only RLIBs, `B` and `C` would not instantiate anything, and in `D` we would then only instantiate `foo<u32>` once.
On the other hand, when there are many leaf crates in the graph (e.g. when compiling many individual test binaries) then the `share-generics` approach will often be more effective.
### TODO
- [x] Add codegen test that makes sure monomorphizations can be internalized in non-Rust binaries.
- [x] Add codegen-units test that makes sure we share generics.
- [x] Add run-make test that makes sure we don't export any monomorphizations from non-Rust binaries.
- [x] Review for reproducible-builds implications.
|
|
|
|
|
|
|
|
|
