Due to macro expansion, its possible to end up with two distinct
`ExpnId`s that have the same `ExpnData` contents. This violates the
contract of `HashStable`, since two unequal `ExpnId`s will end up with
equal `Fingerprint`s.
This commit adds a `disambiguator` field to `ExpnData`, which is used to
force two otherwise-equivalent `ExpnData`s to be distinct.
Fix <unknown> queries and add more timing info to render_html
Closes https://github.com/rust-lang/rust/issues/81251.
## Fix `<unknown>` queries
This happened because `alloc_query_strings` was never called.
## Add more timing info to render_html
This still has some issues I'm not sure how to work out:
- `create_renderer` and `renderer_after_krate` aren't shown by default.
I want something like `verbose_generic_activity_with_arg`, but it doesn't exist.
I'm also not sure how to show activities that aren't on by default - I
tried `-Z self-profile -Z self-profile-args=all`, but it didn't show up.
r? `@wesleywiser`
This avoids each tool having to separately find and call
`self_profile_alloc_strings`.
- Don't compute the global context if it hasn't yet been computed
This avoids giving extraneous errors about unresolved names if an error
occurs during parsing.
avoid promoting division, modulo and indexing operations that could fail
For division, `x / y` will still be promoted if `y` is a non-zero integer literal; however, `1/(1+1)` will not be promoted any more.
While at it, also see if we can reject promoting floating-point arithmetic (which are [complicated](https://github.com/rust-lang/unsafe-code-guidelines/issues/237) so maybe we should not promote them).
This will need a crater run to see if there's code out there that relies on these things being promoted.
If we can land this, promoteds in `fn`/`const fn` cannot fail to evaluate any more, which should let us do some simplifications in codegen/Miri!
Cc https://github.com/rust-lang/rfcs/pull/3027
Fixes https://github.com/rust-lang/rust/issues/61821
r? `@oli-obk`
Improve diagnostics when parsing angle args
https://github.com/rust-lang/rust/pull/79266 introduced parsing of generic arguments in associated type constraints, this however resulted in possibly very confusing error messages in cases in which closing angle brackets were missing such as in `Vec<(u32, _, _) = vec![]`, which outputs an incorrectly parsed equality constraint error, as noted by `@cynecx.`
This PR tries to provide better error messages in such cases.
r? `@petrochenkov`
Refactor token collection to capture trailing token immediately
Split out from https://github.com/rust-lang/rust/pull/80689 - when we start capturing more information about attribute targets, we'll need to know in advance if we're capturing a trailing token or not.
r? `@ghost`
Gracefully handle loop labels missing leading `'` in different positions
Fix#81192.
* Account for labels when suggesting `loop` instead of `while true`
* Suggest `'a` when given `a` only when appropriate
* Add loop head span to hir
* Tweak error for invalid `break expr`
* Add more misspelled label tests
* Avoid emitting redundant "unused label" lint
* Parse loop labels missing a leading `'`
Each commit can be reviewed in isolation.
Fix formatting for removed lints
- Don't add backticks for the reason a lint was removed. This is almost
never a code block, and when it is the backticks should be in the reason
itself.
- Don't assume clippy is the only tool that needs to be checked for
backwards compatibility
I split this out of https://github.com/rust-lang/rust/pull/80527/ because it kept causing tests to fail, and it's a good change to have anyway.
r? `@flip1995`
When encountering a name `a` that isn't resolved, but a label `'a` is
found in the current ribs, only suggest `'a` if this name is the value
expression of a `break` statement.
Solve FIXME.
Force token collection to run when parsing nonterminals
Fixes#81007
Previously, we would fail to collect tokens in the proper place when
only builtin attributes were present. As a result, we would end up with
attribute tokens in the collected `TokenStream`, leading to duplication
when we attempted to prepend the attributes from the AST node.
We now explicitly track when token collection must be performed due to
nomterminal parsing.
Fix ICE in mir when evaluating SizeOf on unsized type
Not quite ready yet. This tries to fix#80742 as discussed on [Zulip topic][1],
by using `delay_span_bug`.
I don't understand what `delay_span_bug` does. It seems like my error message
is never used. With this patch, in this program:
```rust
#![allow(incomplete_features)]
#![feature(const_evaluatable_checked)]
#![feature(const_generics)]
use std::fmt::Debug;
use std::marker::PhantomData;
use std::mem::size_of;
struct Inline<T>
where
[u8; size_of::<T>() + 1]: ,
{
_phantom: PhantomData<T>,
buf: [u8; size_of::<T>() + 1],
}
impl<T> Inline<T>
where
[u8; size_of::<T>() + 1]: ,
{
pub fn new(val: T) -> Inline<T> {
todo!()
}
}
fn main() {
let dst = Inline::<dyn Debug>::new(0); // line 27
}
```
these errors are printed, both for line 27 (annotated line above):
- "no function or associated item named `new` found for struct `Inline<dyn
Debug>` in the current scope"
- "the size for values of type `dyn Debug` cannot be known at compilation time"
Second error makes sense, but I'm not sure about the first one and why it's
even printed.
Finally, I'm not sure about the span passing in `const_eval`.
[1]: https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/Help.20fixing.20.2380742
Fixes#81007
Previously, we would fail to collect tokens in the proper place when
only builtin attributes were present. As a result, we would end up with
attribute tokens in the collected `TokenStream`, leading to duplication
when we attempted to prepend the attributes from the AST node.
We now explicitly track when token collection must be performed due to
nomterminal parsing.
Serialize dependency graph directly from DepGraph
Reduce memory usage by serializing dep graph directly from `DepGraph`,
rather than copying it into `SerializedDepGraph` and serializing that.
