| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 5 pull requests
- Successful merges: #42616, #42651, #42654, #42656, #42685
- Failed merges:
|
|
Remove struct_field_attributes feature gate
Part of #41681. ~This PR only removes the feature gate; this *does not* update any documentations.~ This PR removes the feature gate and the corresponding chapter of the Unstable Book.
I'm not very sure about the changes I made though... Just followed the stabilization guideline.
r? @nikomatsakis
|
|
Position span label correctly when it isn't last
Fix #42595.
Before:
```
15 | map.entry("e").or_insert(0) += 1;
| ---------------------------^^^^^ot use `+=` on type `&mut {integer}`
```
After:
```
15 | map.entry("e").or_insert(0) += 1;
| ---------------------------^^^^^
| |
| cannot use `+=` on type `&mut {integer}`
```
|
|
Learn to parse `a as usize < b`
Parsing `a as usize > b` always works, but `a as usize < b` was a
parsing error because the parser would think the `<` started a generic
type argument for `usize`. The parser now attempts to parse as before,
and if a DiagnosticError is returned, try to parse again as a type with
no generic arguments. If this fails, return the original
`DiagnosticError`.
Fix #22644.
|
|
|
|
- generate error instead of warning
- remove `RewindPoint` and just keep a copy of `Parser` to rewind state.
- `dont_parse_generics: bool` -> `parse_generics: bool`
- remove `eat_lt`
- move error handling code to separate method
|
|
|
|
Build instruction profiler runtime as part of compiler-rt
r? @alexcrichton
This is #38608 with some fixes.
Still missing:
- [x] testing with profiler enabled on some builders (on which ones? Should I add the option to some of the already existing configurations, or create a new configuration?);
- [x] enabling distribution (on which builders?);
- [x] documentation.
|
|
save-analysis: signatures for everything!
|
|
* In other places where the `src` member of a file map is accessed, we
now load and possibly work with external source as well.
|
|
```
warning: `<` is interpreted as a start of generic arguments for `usize`, not a comparison
--> $DIR/issue-22644.rs:16:33
|
16 | println!("{}", a as usize < b);
| - ^ interpreted as generic argument
| |
| not interpreted as comparison
|
help: if you want to compare the casted value then write:
| println!("{}", (a as usize) < b);
```
|
|
|
|
* The lazy loading mechanism has been moved to a more appropriate place.
* Return values from the functions invoked there are properly used.
* Documentation has gotten some minor improvements.
* Possibly some larger restructuring will need to take place still.
|
|
```
warning: `<` is interpreted as a start of generic arguments for `usize`, not comparison
--> $DIR/issue-22644.rs:16:33
|
16 | println!("{}", a as usize < b);
| ^ expected one of `!`, `(`, `+`, `,`, `::`, or `>` here
|
help: if you want to compare the casted value then write
| println!("{}", (a as usize) < b);
```
|
|
Generates signatures for use in Rustdoc and similar tools.
|
|
Parsing `a as usize > b` always works, but `a as usize < b` was a
parsing error because the parser would think the `<` started a generic
type argument for `usize`. The parser now attempts to parse as before,
and if a DiagnosticError is returned, try to parse again as a type with
no generic arguments. If this fails, return the original
`DiagnosticError`.
|
|
|
|
|
|
|
|
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
|
|
|
