| Age | Commit message (Collapse) | Author | Lines |
|---|
|
We now fetch source lines from the `external_src` member as a secondary
fallback if no regular source is present, that is, if the file map
belongs to an external crate and the source has been fetched from disk.
|
|
|
|
They are now handled in their own member to prevent mutating access to
the `src` member. This way, we can safely load external sources, while
keeping the mutation of local source strings off-limits.
|
|
The rationale is that BOM stripping is needed for lazy source loading
for external crates, and duplication can be avoided by moving the
corresponding functionality to libsyntax_pos.
|
|
We can use these to perform lazy loading of source files belonging to
external crates. That way we will be able to show the source code of
external spans that have been translated.
|
|
Speed up expansion
This reduces duplication, thereby increasing expansion speed. Based on tests with rust-uinput, this produces a 29x performance win (440 seconds to 15 seconds). I want to land this first, since it's a minimal patch, but with more changes to the macro parsing I can get down to 12 seconds locally.
There is one FIXME added to the code that I'll keep for now since changing it will spread outward and increase the patch size, I think.
Fixes #37074.
r? @jseyfried
cc @oberien
|
|
This reduces duplication, thereby increasing expansion speed.
|
|
|
|
qnighy:disallow-underscore-suffix-for-string-like-literals, r=nikomatsakis
Disallow underscore suffix for string-like literals.
This patch turns string/bytestring/char/byte literals followed by an underscore, like `"Foo"_`, to an error.
`scan_optional_raw_name` will parse `_` as a valid raw name, but it will be rejected by the parser. I also considered just stopping parsing when the suffix is `_`, but in that case `"Foo"_` will be lexed as two valid tokens.
Fixes the latter half of #41723.
|
|
|
|
Extend the unused macro lint to macros 2.0
Extends the unused macro lint (added in PR #41907) to macros 2.0 (added in PR #40847).
r? @jseyfried
|
|
Use callsite's span for macro calls on suggestion
When suggesting an appropriate mutability for a macro call, use the call
span instead of the expanded macro's span.
```
error[E0308]: mismatched types
--> $DIR/coerce-suggestions.rs:48:9
|
48 | s = format!("foo");
| ^^^^^^^^^^^^^^ expected mutable reference, found struct `std::string::String`
|
= note: expected type `&mut std::string::String`
found type `std::string::String`
= help: try with `&mut format!("foo")`
= note: this error originates in a macro outside of the current crate
```
Fix #41858.
|
|
Improve error message for const extern fn
It's currently ``error: unmatched visibility `pub` ``, which is a nonsensical error in this context.
|
|
When suggesting an appropriate mutability for a macro call, use the call
span instead of the expanded macro's span.
|
|
New error codes next
Part #42229.
To be merged after #42264.
cc @Susurrus
|
|
Turn sufficiently old compatibility lints into hard errors
It's been almost 7 months since https://github.com/rust-lang/rust/pull/36894 was merged, so it's time to take the next step.
[breaking-change], needs crater run.
PRs/issues submitted to affected crates:
https://github.com/alexcrichton/ctest/pull/17
https://github.com/Sean1708/rusty-cheddar/pull/55
https://github.com/m-r-r/helianto/pull/3
https://github.com/azdle/virgil/pull/1
https://github.com/rust-locale/rust-locale/issues/24
https://github.com/mneumann/acyclic-network-rs/pull/1
https://github.com/reem/rust-typemap/pull/38
cc https://internals.rust-lang.org/t/moving-forward-on-forward-compatibility-lints/4204
cc https://github.com/rust-lang/rust/issues/34537 https://github.com/rust-lang/rust/issues/36887
Closes https://github.com/rust-lang/rust/issues/36886
Closes https://github.com/rust-lang/rust/issues/36888
Closes https://github.com/rust-lang/rust/issues/36890
Closes https://github.com/rust-lang/rust/issues/36891
Closes https://github.com/rust-lang/rust/issues/36892
r? @nikomatsakis
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
incr.comp.: Track expanded spans instead of FileMaps.
This PR removes explicit tracking of FileMaps in response to #42101. The reasoning behind being able to just *not* track access to FileMaps is similar to why we don't track access to the `DefId->DefPath` map:
1. One can only get ahold of a `Span` value by accessing the HIR (for local things) or a `metadata::schema::Entry` (for things from external crates).
2. For both of these things we compute a hash that incorporates the *expanded spans*, that is, what we hash is in the (FileMap independent) format `filename:line:col`.
3. Consequently, everything that emits a span should already be tracked via its dependency to something that has the span included in its hash and changes would be detected via that hash.
One caveat here is that we have to be conservative when exporting things in metadata. A crate can be built without debuginfo and would thus by default not incorporate most spans into the metadata hashes. However, a downstream crate can make an inline copy of things in the upstream crate and span changes in the upstream crate would then go undetected, even if the downstream uses them (e.g. by emitting debuginfo for an inlined function). For this reason, we always incorporate spans into metadata hashes for now (there might be more efficient ways to handle this safely when red-green tracking is implemented).
r? @nikomatsakis
|
|
Remove all instances of fragment_infos and fragment sets
Remove unused fragment structs. This was suggested by @eddyb in IRC: [botbot link](https://botbot.me/mozilla/rustc/2017-05-23/?msg=86016574&page=2).
|
|
Stabilize non capturing closure to fn coercion
Stabilisation PR for non capturing closure to fn coercion.
closes #39817
|
|
trace_macro: Show both the macro call and its expansion. #42072.
See #42072 for the initial motivation behind this.
The change is not the minimal fix, but I want this behavior almost every time I use `trace_macros`.
|
|
|
|
add thiscall calling convention support
This support is needed for bindgen to work well on 32-bit Windows, and also enables people to begin experimenting with C++ FFI support on that platform.
Fixes #42044.
|
|
Initial implementation of declarative macros 2.0
Implement declarative macros 2.0 (rust-lang/rfcs#1584) behind `#![feature(decl_macro)]`.
Differences from `macro_rules!` include:
- new syntax: `macro m(..) { .. }` instead of `macro_rules! m { (..) => { .. } }`
- declarative macros are items:
```rust
// crate A:
pub mod foo {
m!(); // use before definition; declaration order is irrelevant
pub macro m() {} // `pub`, `pub(super)`, etc. work
}
fn main() {
foo::m!(); // named like other items
{ use foo::m as n; n!(); } // imported like other items
}
pub use foo::m; // re-exported like other items
// crate B:
extern crate A; // no need for `#[macro_use]`
A::foo::m!(); A::m!();
```
- Racket-like hygiene for items, imports, methods, fields, type parameters, privacy, etc.
- Intuitively, names in a macro definition are resolved in the macro definition's scope, not the scope in which the macro is used.
- This [explaination](http://beautifulracket.com/explainer/hygiene.html) of hygiene for Racket applies here (except for the "Breaking Hygiene" section). I wrote a similar [explanation](https://github.com/jseyfried/rfcs/blob/hygiene/text/0000-hygiene.md) for Rust.
- Generally speaking, if `fn f() { <body> }` resolves, `pub macro m() { <body> } ... m!()` also resolves, even if `m!()` is in a separate crate.
- `::foo::bar` in a `macro` behaves like `$crate::foo::bar` in a `macro_rules!`, except it can access everything visible from the `macro` (thus more permissive).
- See [`src/test/{run-pass, compile-fail}/hygiene`](https://github.com/rust-lang/rust/pull/40847/commits/afe7d89858fd72b983e24727d6f4058293153c19) for examples. Small example:
```rust
mod foo {
fn f() { println!("hello world"); }
pub macro m() { f(); }
}
fn main() { foo::m!(); }
```
Limitations:
- This does not address planned changes to matchers (`expr`,`ty`, etc.), c.f. #26361.
- Lints (including stability and deprecation) and `unsafe` are not hygienic.
- adding hygiene here will be mostly or entirely backwards compatible
- Nested macro definitions (a `macro` inside another `macro`) don't always work correctly when invoked from external crates.
- pending improvements in how we encode macro definitions in crate metadata
- There is no way to "escape" hygiene without using a procedural macro.
r? @nrc
|
|
|
|
|
|
Stabilize rfc 1506 - Clarified ADT Kinds
Closes #35626
Documentation:
- [ ] Reference rust-lang-nursery/reference#37
- [ ] Book?
- [ ] Rust by example?
|
|
|
|
|
|
|
|
|
|
remove "much" from unicode diagnostic
The English seems slightly awkward to me, and it's unnecessary.
|
|
Add an option to the parser to avoid parsing out of line modules
This is useful if parsing from stdin or a String and don't want to try and read in a module from another file. Instead we just leave a stub in the AST.
|
|
This support is needed for bindgen to work well on 32-bit Windows, and
also enables people to begin experimenting with C++ FFI support on that
platform.
Fixes #42044.
|
|
|
|
|
|
Stabilize the loop_break_value feature
Tracking issue: #37339.
Documentation PRs already sent to the various repositories.
|
|
Correct some stability versions
These were found by running tidy on stable versions of rust and finding
features stabilised with the wrong version numbers.
|
|
|
|
These were found by running tidy on stable versions of rust and finding
features stabilised with the wrong version numbers.
|
|
Fix ICE on `include!(line!())` (regression)
Fixes #41776.
r? @nrc
|
|
|
|
This is useful if parsing from stdin or a String and don't want to try and read in a module from another file. Instead we just leave a stub in the AST.
|
|
|
