ICH: Handle MacroDef HIR instances.
As of recently, `hir::MacroDef` instances are exported in crate metadata, which means we also store their ICH when doing incremental compilation. Even though exported macro definitions should not (yet) interact with incremental compilation, the ICH is also used for the general purpose crate hash, where macros should be included.
This PR implements ICH computation for `MacroDef`. In theory, the ICH of these MacroDefs is less stable than that of other HIR items, since I opted to just call the compiler-generated `Hash::hash()` for `Token::Interpolated` variants. `Token::Interpolated` contains AST data structures and it would have been a lot of effort to expand ICH computation to the AST too. Since quasi-quoting is rarely used *and* it would only make a difference if incremental compilation was extended to macros, the simpler implementation seemed like a good idea.
This fixes the problem reported in https://github.com/rust-lang/rust/issues/37756. The test still fails because of broken codegen-unit support though.
r? @nikomatsakis
Tidy is not the right place to do this. Tidy is for running lints.
We should instead be running the lexer/grammar tests as part of the test
suite.
This may fix nightly breakage, but I don't know why.
Improvements to the #[should_panic] feature
Add more error checking for the `#[should_panic]` attribute, and print the expected panic string when it does not match.
Fixes https://github.com/rust-lang/rust/issues/29000
Eg:
```running 3 tests
test test2 ... ok
test test1 ... FAILED
: Panic did not include expected string 'foo'
test test3 ... FAILED
failures:
---- test1 stdout ----
thread 'test1' panicked at 'bar', test.rs:7
note: Run with `RUST_BACKTRACE=1` for a backtrace.
---- test3 stdout ----
thread 'test3' panicked at 'bar', test.rs:18
```
rustbuild: Allow configuration of python interpreter
Add a configuration key to `config.toml`, read it from `./configure`, and add
auto-detection if none of those were specified.
Closes#35760
rustdoc: add cli argument `--playground-url`
Add a new cli argument `--playground-url` for rustdoc:
`rustdoc lib.rs --playground-url="https://play.rust-lang.org/"`
`rustdoc book.md --playground-url="https://play.rust-lang.org/"`
This makes it possible for tools like https://docs.rs to generate crate docs that can submit samples code to run at https://play.rust-lang.org, even if the crate's author *forgot* putting `#![doc(html_playground_url = "https://play.rust-lang.org/")]` to crate root. By the way, I'd like to say, many crate authors are not aware of existing of `#![doc(html_playground_url = "https://play.rust-lang.org/")]`.
`--playground-url` may be reset by `--markdown-playground-url` or `#![doc(html_playground_url=...)]`, so it's backward compatible.
@alexcrichton since you implemented playground-url related features.
Separate impl items from the parent impl
This change separates impl item bodies out of the impl itself. This gives incremental more resolution. In so doing, it refactors how the visitors work, and cleans up a bit of the collect/check logic (mostly by moving things out of collect that didn't really belong there, because they were just checking conditions).
However, this is not as effective as I expected, for a kind of frustrating reason. In particular, when invoking `foo.bar()` you still wind up with dependencies on private items. The problem is that the method resolution code scans that list for methods with the name `bar` -- and this winds up touching *all* the methods, even private ones.
I can imagine two obvious ways to fix this:
- separating fn bodies from fn sigs (#35078, currently being pursued by @flodiebold)
- a more aggressive model of incremental that @michaelwoerister has been advocating, in which we hash the intermediate results (e.g., the outputs of collect) so that we can see that the intermediate result hasn't changed, even if a particular impl item has changed.
So all in all I'm not quite sure whether to land this or not. =) It still seems like it has to be a win in some cases, but not with the test cases we have just now. I can try to gin up some test cases, but I'm not sure if they will be totally realistic. On the other hand, some of the early refactorings to the visitor trait seem worthwhile to me regardless.
cc #36349 -- well, this is basically a fix for that issue, I guess
r? @michaelwoerister
NB: Based atop of @eddyb's PR https://github.com/rust-lang/rust/pull/37402; don't land until that lands.
Improved error reporting when target sysroot is missing.
Attempts to resolve#37131.
This is my first pull request on rust, so I would greatly appreciate any feedback you have on this.
Thanks!
Before, when we created an AssociatedItem for impl item X, we would read
the impl item itself. Now we instead load up the impl I that contains X
and read the data from the `ImplItemRef` for X; actually, we do it for
all impl items in I pre-emptively.
This kills the last source of edges between a method X and a call to a
method Y defined in the same impl.
Fixes#37121
add test for #37765
Adds a test for #37765, a path parsing fix which removes the need for a parenthesis workaround.
Closes#37765.
cc #37290 @withoutboats
r? @petrochenkov
Add semicolon to "perhaps add a `use` for one of them" help
Similar to pull request #37430, this makes the message more copy-paste
friendly and aligns it with other messages like:
help: you can import it into scope: use foo::Bar;
r? @eddyb
coherence: skip impls with an erroneous trait ref
Impls with a erroneous trait ref are already ignored in the first part
of coherence, so ignore them in the second part too. This avoids
cascading coherence errors when 1 impl of a trait has an error.
r? @nikomatsakis
Support `use`ing externally defined macros behind `#![feature(use_extern_macros)]`
With `#![feature(use_extern_macros)]`,
- A name collision between macros from different upstream crates is much less of an issue since we can `use` the macros in different submodules or rename with `as`.
- We can reexport macros with `pub use`, so `#![feature(macro_reexport)]` is no longer needed.
- These reexports are allowed in any module, so crates can expose a macro-modular interface.
If a macro invocation can resolve to both a `use` import and a `macro_rules!` or `#[macro_use]`, it is an ambiguity error.
r? @nrc
Refactoring towards region obligation
Two refactorings towards the intermediate goal of propagating region obligations through the `InferOk` structure (which in turn leads to the possibility of lazy normalization).
1. Remove `TypeOrigin` and add `ObligationCause`
- as we converge subtyping and obligations and so forth, the ability to keep these types distinct gets harder
2. Propagate obligations from `InferOk` into the surrounding fulfillment context
After these land, I have a separate branch (which still needs a bit of work) that can make the actual change to stop directly adding subregion edges and instead propagate obligations. (This should also make it easier to fix the unsoundness in specialization around lifetimes.)
r? @eddyb
Fix grammar verification
* Use make check-lexer to verify the grammar.
* Extend grammar/README
* Add make clean-grammar rule
* Add target check-build-lexer-verifier to make tidy, so it will build the verifier with every build and catch future errors
This is the continuation of #34994
r? @steveklabnik @jonathandturner @alexcrichton
