This commit introduces 128-bit integers. Stage 2 builds and produces a working compiler which
understands and supports 128-bit integers throughout.
The general strategy used is to have rustc_i128 module which provides aliases for iu128, equal to
iu64 in stage9 and iu128 later. Since nowhere in rustc we rely on large numbers being supported,
this strategy is good enough to get past the first bootstrap stages to end up with a fully working
128-bit capable compiler.
In order for this strategy to work, number of locations had to be changed to use associated
max_value/min_value instead of MAX/MIN constants as well as the min_value (or was it max_value?)
had to be changed to use xor instead of shift so both 64-bit and 128-bit based consteval works
(former not necessarily producing the right results in stage1).
This commit includes manual merge conflict resolution changes from a rebase by @est31.
Use `DefId`s instead of `NodeId`s for `pub(restricted)` visibilities
This is groundwork for hygiene 2.0, specifically privacy checking hygienic intercrate name resolutions.
r? @nrc
The Markdown engine used by the book can cope with a single leading space
on the list marker:
Like this:
* List item
Rather than like this:
* List item
… but it’s not the typical convention employed in the book, and moreover
the Markdown engine used for producing the error index *can’t* cope with
it (its behaviour looks like a bug, as it appears to lose one of the two
line breaks as well, but that’s immaterial here).
So, we shift to a single convention which doesn’t trigger bugs in the
Markdown renderer.
We now do two phases. First, we gather up the list of candidates with
suitable return types and extract their names. Then we filter those to
see which are applicable and we return that.
It might be nice to do the "filter by return type" as a second step,
but this is ok for now.
After the fix of #37453 in PR #37369, instead of pointing at only the
cast type, point at the full cast span when a cast needs a dereference:
```
error: casting `&{float}` as `f32` is invalid
--> ../../../src/test/ui/mismatched_types/cast-rfc0401.rs:81:30
|
81 | vec![0.0].iter().map(|s| s as f32).collect::<Vec<f32>>();
| ^^^^^^^^ cannot cast `&{float}` as `f32`
|
help: did you mean `*s`?
--> ../../../src/test/ui/mismatched_types/cast-rfc0401.rs:81:30
|
81 | vec![0.0].iter().map(|s| s as f32).collect::<Vec<f32>>();
| ^
```
instead of
```
error: casting `&{float}` as `f32` is invalid
--> ../../../src/test/ui/mismatched_types/cast-rfc0401.rs:81:35
|
81 | vec![0.0].iter().map(|s| s as f32).collect::<Vec<f32>>();
| - ^^^
| |
| |
| did you mean `*s`?
| cannot cast `&{float}` as `f32`
```
Simplify calling find_implied_output_region.
@nnethercote added the optimization that find_implied_output_region
takes a closure as an optimization in #37014, but passing an iterator is
simpler, and more ergonomic for callers.
@nnethercote added the optimization that find_implied_output_region
takes a closure as an optimization in #37014, but passing an iterator is
simpler, and more ergonomic for callers.
Point arg num mismatch errors back to their definition
This PR updates the arg num errors (like E0061) to point back at the function definition where they were defined.
Before:
```
error[E0061]: this function takes 2 parameters but 1 parameter was supplied
--> E0061.rs:18:7
|
18 | f(0);
| ^
|
= note: the following parameter types were expected:
= note: u16, &str
```
Now:
```
error[E0061]: this function takes 2 parameters but 1 parameter was supplied
--> E0061.rs:18:7
|
11 | fn f(a: u16, b: &str) {}
| ------------------------ defined here
...
18 | f(0);
| ^ expected 2 parameters
```
This is an incremental improvement. We probably want to underline only the function name and also have support for functions defined in crates outside of the current crate.
r? @nikomatsakis
Show `Trait` instead of `<Struct as Trait>` in E0323
For a given file
```
trait Foo {
fn bar(&self);
}
pub struct FooConstForMethod;
impl Foo for FooConstForMethod {
const bar: u64 = 1;
}
```
show
```
error[E0323]: item `bar` is an associated const, which doesn't match its trait `Foo`
```
instead of
```
error[E0323]: item `bar` is an associated const, which doesn't match its trait `<FooConstForMethod as Foo>`
```
Fix#37618
Refactor one_bound_for_assoc_type to take an Iterator instead of Vec
I doubt the performance implications will be serious, but it will avoid allocating one-element Vecs for the successful case (and avoid allocating vecs at all for any case, too).
`--stage 2` tests passed locally.
