| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
The collector was asserting a total absence of projections, but some
projections are expected, even in trans: in particular, projections
containing higher-ranked regions, which we don't currently normalize.
|
|
|
|
We were treating an associated type as unsized even when the concrete
instantiation was actually sized. Fix is to normalize before checking
if it is sized.
|
|
This fixes #35849, a regression introduced by the typeck refactoring
around TyNever/!.
|
|
Implement the `!` type
This implements the never type (`!`) and hides it behind the feature gate `#[feature(never_type)]`. With the feature gate off, things should build as normal (although some error messages may be different). With the gate on, `!` is usable as a type and diverging type variables (ie. types that are unconstrained by anything in the code) will default to `!` instead of `()`.
|
|
Take commandline arguments into account for incr. comp.
Implements the conservative strategy described in https://github.com/rust-lang/rust/issues/33727.
From now one, every time a new commandline option is added, one has to specify if it influences the incremental compilation cache. I've tried to implement this as automatic as possible: One just has to added either the `[TRACKED]` or the `[UNTRACKED]` marker next to the field. The `Options`, `CodegenOptions`, and `DebuggingOptions` definitions in `session::config` show plenty of examples.
The PR removes some cruft from `session::config::Options`, mostly unnecessary copies of flags also present in `DebuggingOptions` or `CodeGenOptions` in the same struct.
One notable removal is the `cfg` field that contained the values passed via `--cfg` commandline arguments. I chose to remove it because (1) its content is only a subset of what later is stored in `hir::Crate::config` and it's pretty likely that reading the cfgs from `Options` would not be what you wanted, and (2) we could not incorporate it into the dep-tracking hash of the `Options` struct because of how the test framework works, leaving us with a piece of untracked but vital data.
It is now recommended (just as before) to access the crate config via the `krate()` method in the HIR map.
Because the `cfg` field is not present in the `Options` struct any more, some methods in the `CompilerCalls` trait now take the crate config as an explicit parameter -- which might constitute a breaking change for plugin authors.
|
|
Update E0261 and E0262 to new error format
Fixes #35516 and #35517 . Part of #35233
r? @jonathandturner
|
|
Rollup of 30 pull requests
- Successful merges: #34941, #35392, #35444, #35447, #35491, #35533, #35539, #35558, #35573, #35574, #35577, #35586, #35588, #35594, #35596, #35597, #35598, #35606, #35611, #35615, #35616, #35620, #35622, #35640, #35643, #35644, #35646, #35647, #35648, #35661
- Failed merges: #35395, #35415
|
|
[MIR] Add Storage{Live,Dead} statements to emit llvm.lifetime.{start,end}.
Storage live ranges are tracked for all MIR variables and temporaries with a drop scope.
`StorageLive` is lowered to `llvm.lifetime.start` and `StorageDead` to `llvm.lifetime.end`.
There are some improvements possible here, such as:
* pack multiple storage liveness statements by using the index of first local + `u64` bitset
* enforce that locals are not directly accessed outside their storage live range
* shrink storage live ranges for never-borrowed locals to initialization -> last use
* emit storage liveness statements for *all* temporaries
* however, the remaining ones are *always* SSA immediates, so they'd be noop in MIR trans
* could have a flag on the temporary that its storage is irrelevant (a la C's old `register`)
* would also deny borrows if necessary
* this seems like an overcompliation and with packing & optimizations it may be pointless
Even in the current state, it helps stage2 `rustc` compile `boiler` without overflowing (see #35408).
A later addition fixes #26764 and closes #27372 by emitting `.section` directives for dylib metadata to avoid them being allocated into memory or read as `.note`. For this PR, those bugs were tripping valgrind.
|
|
Improve &-ptr printing
This PR replaces printing `&-ptr` with a more readable description. To do so it uses a few heuristics.
If the name of the type is unknown, too long (longer than just saying "reference"), or too complex (a type with explicit lifetime annotations), it will instead opt to print either "reference" or "mutable reference", depending on the mutability of the type.
Before:
```
error[E0308]: mismatched types
--> src/test/compile-fail/issue-7061.rs:14:46
|
14 | fn foo(&'a mut self) -> Box<BarStruct> { self }
| ^^^^ expected box, found &-ptr
|
= note: expected type `Box<BarStruct>`
= note: found type `&'a mut BarStruct`
error: aborting due to previous error
```
After:
```
error[E0308]: mismatched types
--> src/test/compile-fail/issue-7061.rs:14:46
|
14 | fn foo(&'a mut self) -> Box<BarStruct> { self }
| ^^^^ expected box, found mutable reference
|
= note: expected type `Box<BarStruct>`
= note: found type `&'a mut BarStruct`
error: aborting due to previous error
```
|
|
Update E0138 to new format
Part of #35233
Fix #35510
r? @jonathandturner
Question: How can I only underline the function name ? I have observed the debug output and the struct of item, but I can't find the `Span` for function name. Should I modify the struct I get to save function name's position or there is another way to get it ? (I can only find `Span`s for function attributes, inputs, outputs, blocks)
|
|
Make `private_in_public` compatibility lint deny-by-default
In accordance with the [plan](https://internals.rust-lang.org/t/fcp-for-various-future-compatibility-warnings/3590/5?u=petrochenkov).
r? @nikomatsakis
|
|
|
|
|
|
Default to either `!` or `()` depending on whether feature(never_type)
is on or not.
|
|
|
|
Split Ty::is_empty method into is_never and is_uninhabited
|
|
Mainly, remove mk_empty() method and replace with tcx.types.empty
|
|
Replace FnOutput with Ty
Replace FnConverging(ty) with ty
Purge FnDiverging, FunctionRetTy::NoReturn and FunctionRetTy::None
|
|
|
|
Parse -> ! as FnConverging(!)
Add AdjustEmptyToAny coercion to all ! expressions
Some fixes
|
|
|
|
Add `TyKind::Empty` and fix resulting build errors.
|
|
[MIR] Add explicit SetDiscriminant StatementKind for deaggregating enums
cc #35186
To deaggregate enums, we need to be able to explicitly set the discriminant. This PR implements a new StatementKind that does that.
I think some of the places that have `panics!` now could maybe do something smarter.
|
|
Err codes
r? @jonathandturner
|
|
|
|
|
|
|
|
methods.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 23 pull requests
- Successful merges: #35279, #35331, #35358, #35375, #35445, #35448, #35482, #35486, #35505, #35528, #35530, #35532, #35536, #35537, #35541, #35552, #35554, #35555, #35557, #35562, #35565, #35569, #35576
- Failed merges: #35395, #35415, #35563
|
|
|
|
|
|
The 'cfg' in the Options struct is only the commandline-specified
subset of the crate configuration and it's almost always wrong to
read that instead of the CrateConfig in HIR crate node.
|
|
Commandline arguments influence whether incremental compilation
can use its compilation cache and thus their changes relative to
previous compilation sessions need to be taking into account. This
commit makes sure that one has to specify for every commandline
argument whether it influences incremental compilation or not.
|
|
E0072 update error format
Part of #35233
Fixes #35506
r? @jonathandturner
The bonus for this issue currently seems to be impossible to do reliably, as the compiler seems to lack span information for item names alone, like `Foo` in `struct Foo { ... }`. It would be possible to hack something together by computing span offsets, but that seems like a solution that would be begging for trouble.
A proper solution to this would, of course, be to add span information to the right place (seems to be `rustc::hir::Item::name` but I may be wrong).
|
|
Update E0133 to new format
Part of #35233
Fix #35509
r? @jonathandturner
|
|
E0263 updated to new format.
Fixes #35518. Part of #35233.
r? @jonathandturner
|
|
Update E0038 to the new error format
Part of #35233
Addresses #35500
"r? @jonathandturner
This doesn't compile yet, and I need help. In my naive solution, adding the span label makes our error message a mutable `errors::DiagnosticBuilder` pointer.
```bash
python src/bootstrap/bootstrap.py --step check-cfail E0038 --stage 1
```
```
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Building stage0 test artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Compiling rustc v0.0.0 (file:///home/nash/code/rust/src/librustc)
src/librustc/traits/error_reporting.rs:735:9: 735:12 error: mismatched types [E0308]
src/librustc/traits/error_reporting.rs:735 err
^~~
src/librustc/traits/error_reporting.rs:735:9: 735:12 help: run `rustc --explain E0308` to see a detailed explanation
src/librustc/traits/error_reporting.rs:735:9: 735:12 note: expected type `core::option::Option<errors::DiagnosticBuilder<'tcx>>`
src/librustc/traits/error_reporting.rs:735:9: 735:12 note: found type `core::option::Option<&mut errors::DiagnosticBuilder<'_>>`
error: aborting due to previous error
error: Could not compile `rustc`.
To learn more, run the command again with --verbose.
command did not execute successfully: "/home/nash/code/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "-j" "4" "--target" "x86_64-unknown-linux-gnu" "--release" "--features" " jemalloc" "--manifest-path" "/home/nash/code/rust/src/rustc/Cargo.toml"
expected success, got: exit code: 101
```
|
|
refactor lvalue_ty to be method of lvalue
Currently `Mir` (and `MirContext`) implement a method `lvalue_ty` (and actually many more `foo_ty`). But this should be a method of `Lvalue`.
If you have an `lvalue` and you want to get its type, the natural thing to write is:
```
lvalue.ty()
```
Of course it needs context, but still:
```
lvalue.ty(mir, tcx)
```
Makes more sense than
```
mir.lvalue_ty(lvalue, tcx)
```
I actually think we should go a step farther and have traits so we could get the type of some value generically, but that's up for debate. The thing I'm running into a lot in the compiler is I have a value of type `Foo` and I know that there is some related type `Bar` which I can get through some combination of method calls, but it's often not as direct as I would imagine. Unless you already know the code, its not clear why you would look in `Mir` for a method to get the type of an `Lvalue`.
|
|
Add help for target CPUs, features, relocation and code models.
Fix for https://github.com/rust-lang/rust/issues/30961. Requires PR https://github.com/rust-lang/llvm/pull/45 to be accepted first, and the .gitmodules for llvm to be updated before this can be merged.
|
|
|
|
|
|
|
