This commit removes some ThinLTO/codegen unit cruft primarily only needed during
the initial phase where we were adding ThinLTO support to rustc itself. The
current bootstrap compiler knows about ThinLTO and has it enabled by default for
multi-CGU builds which are also enabled by default. One CGU builds (aka
disabling ThinLTO) can be achieved by configuring the number of codegen units to
1 for a particular builds.
This also changes the defaults for our dist builders to go back to multiple
CGUs. Unfortunately we're seriously bleeding for cycle time on the bots right
now so we need to recover any time we can.
Warn about ignored generic bounds in `for`
This adds a new lint to fix#42181. For consistency and to avoid code duplication, I also moved the existing "bounds in type aliases are ignored" here.
Questions to the reviewer:
* Is it okay to just remove a diagnostic error code like this? Should I instead keep the warning about type aliases where it is? The old code provided a detailed explanation of what's going on when asked, that information is now lost. On the other hand, `span_warn!` seems deprecated (after this patch, it has exactly one user left!).
* Did I miss any syntactic construct that can appear as `for` in the surface syntax? I covered function types (`for<'a> fn(...)`), generic traits (`for <'a> Fn(...)`, can appear both as bounds as as trait objects) and bounds (`for<'a> F: ...`).
* For the sake of backwards compatibility, this adds a warning, not an error. @nikomatsakis suggested an error in https://github.com/rust-lang/rust/issues/42181#issuecomment-306924389, but I feel that can only happen in a new epoch -- right?
Cc @eddyb
Modify part of `column!` documentation.
Just like `line!` documentation, I've replaced:
> The returned column is not the invocation of the `column!` macro itself
By
> The returned column is *not necessarily* the line of the `column!` invocation itself
See #46997.
Modify part of `line!` documentation.
In accordance with #46997, I've replaced:
> The returned line is not the invocation of the line! macro itself [...]
By
> The returned line is *not necessarily* the line of the `line!` invocation itself [...]
rustc: Migrate to `termcolor` crate from `term`
This crate moves the compiler's error reporting to using the `termcolor` crate
from crates.io. Previously rustc used a super-old version of the `term` crate
in-tree which is basically unmaintained at this point, but Cargo has been using
`termcolor` for some time now and tools like `rg` are using `termcolor` as well,
so it seems like a good strategy to take!
Note that the `term` crate remains in-tree for libtest. Changing libtest will be
a bit tricky due to how the build works, but we can always tackle that later.
cc #45728
in which parentheses are suggested for should-have-been-tuple-patterns
Programmers used to working in some other languages (such as Python or
Go) might expect to be able to destructure values with comma-separated
identifiers but no parentheses on the left side of an assignment.
Previously, the first name in such code would get parsed as a
single-indentifier pattern—recognizing, for example, the
`let a` in `let a, b = (1, 2);`—whereupon we would have a fatal syntax
error on seeing an unexpected comma rather than the expected semicolon
(all the way nearer to the end of `parse_full_stmt`).
Instead, let's look for that comma when parsing the pattern, and if we
see it, make-believe that we're parsing the remaining elements in a
tuple pattern, so that we can suggest wrapping it all in parentheses. We
need to do this in a separate wrapper method called on a "top-level"
pattern, rather than within
`parse_pat` itself, because `parse_pat` gets called recursively to parse
the sub-patterns within a tuple pattern.
~~We could also do this for `match` arms, `if let`, and `while let`, but
we elect not to in this patch, as it seems less likely for users to make
the mistake in those contexts.~~
Resolves#48492.
r? @petrochenkov
Just like `line!` documentation, I've replaced:
> The returned column is not the invocation of the `column!` macro itself
By
> The returned column is *not necessarily* the line of the `column!` invocation itself
See #46997.
In accordance with #46997, I've replaced:
> The returned line is not the invocation of the line! macro itself [...]
By
> The returned line is *not necessarily* the line of the `line!` invocation itself [...]
Programmers used to working in some other languages (such as Python or
Go) might expect to be able to destructure values with comma-separated
identifiers but no parentheses on the left side of an assignment.
Previously, the first name in such code would get parsed as a
single-indentifier pattern—recognizing, for example, the
`let a` in `let a, b = (1, 2);`—whereupon we would have a fatal syntax
error on seeing an unexpected comma rather than the expected semicolon
(all the way nearer to the end of `parse_full_stmt`).
Instead, let's look for that comma when parsing the pattern, and if we
see it, momentarily make-believe that we're parsing the remaining
elements in a tuple pattern, so that we can suggest wrapping it all in
parentheses. We need to do this in a separate wrapper method called on
the top-level pattern (or `|`-patterns) in a `let` statement, `for`
loop, `if`- or `while let` expression, or match arm rather than within
`parse_pat` itself, because `parse_pat` gets called recursively to parse
the sub-patterns within a tuple pattern.
Resolves#48492.
rustc: Fix ICE with `#[target_feature]` on module
This commit fixes an ICE in rustc when `#[target_feature]` was applied to items
other than functions due to the way the feature was validated.
Add a potential cause raising `ParseIntError`.
Initially, I wanted to add it directly to the documentation of `str. parse()` method, I finally found that it was more relevant (I hope so?) to directly document the structure in question. I've added a scenario, in which we could all get caught at least once, to make it easier to diagnose the problem when parsing integers.
Replace iterator structures with `impl Trait`.
Two commits:
* Replace iterator structures with `impl Trait`.
* Run rustfmt on `src/librustc_data_structures/graph/mod.rs`.
Replace all const evaluation with miri
* error reporting in constants prints a stacktrace through all called const fns
* Trivial constant propagation and folding in MIR (always active, irrelevant of the optimization level)
* can now use floating constants in patterns (previously only floating point literals were allowed)
* the future compat lint is still produced for both cases
* can index into constant arrays during const eval (previously feature gated)
* can create a constant union value with field `a` and read from field `b`
* can dereference references into constants
* can create references inside constants (`const X: &u32 = &22`)
* Tuple struct constructors can be used in constants
* regression in const eval errors spans (some of these need improvements in mir debug info)
* can cast floats to ints and vice versa (in constants, and even nan/inf constants)
* Mir dump prints false/true instead of 0u8/1u8
* `1i8 >> [8][0]` does not lint about exceeding bitshifts anymore.
* Needs const propagation across projections
* `foo[I]` produces a const eval lint if `foo: [T; N]` and `N < I`
* Essentially all builtin panics produce lints if they can be statically proven to trigger at runtime. This is on a best effort basis, so there might be some complex cases that don't trigger. (The runtime panic stays there, irrelevant of whether the lint is produced or not)
* can use `union`s to implement `transmute` for `Copy` types in constants without a feature gate. With all the greatness and nasal demons that come with this.
* can convert integers to `&'static T` in constants (useful for embedded)
fixes#34997 (stack overflow with many constants)
fixes#25574 (deref byte strings in patterns)
fixes#27918 (broken mir ICE)
fixes#46114 (ICE on struct constructors in patterns)
fixes#37448 (`SomeStruct { foo } as SomeStruct`)
fixes#43754 (`return` in const fn)
fixes#41898 (tuple struct constructors)
fixes#31364 (infinite recursion with const fn, fixed by miri's recursion limit)
closes#29947 (const indexing stabilization)
fixes#45044 (pattern matching repeat expressions)
fixes#47971 (ICE on const fn + references)
fixes#48081 (ICE on cyclic assoc const error)
fixes#48746 (nonhelpful error message with unions)
r? @eddyb
even though 1k loc are added in tests, this PR reduces the loc in this repository by 700
