| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Implement `Debug`, `Display` and `Error` for `FatalError` and `ExplicitBug`
|
|
`s/([^\(\s]+\.)len\(\) [(?:!=)>] 0/!$1is_empty()/g`
|
|
`s/(?<!\{ self)(?<=\.)len\(\) == 0/is_empty()/g`
|
|
|
|
|
|
|
|
|
|
Just some minor patches I've been sitting on.
|
|
This is a little bit tricky, since with include_str!, we know that we
are including utf-8 content, so it's safe to store the source as a
String in a FileMap. We don't know that for include_bytes!, but I don't
think we actually need to track the contents anyways, so I'm passing "".
new_filemap does check for the zero length content, and it should be
reasonable, howeven I'm not sure if it would be better to pass None
instead of Some(Rc::new("")) as the src component of a FileMap.
Fixes bug #24348
|
|
|
|
This commit entirely removes the old I/O, path, and rand modules. All
functionality has been deprecated and unstable for quite some time now!
|
|
Fixes #22953.
|
|
Fixes #22619
|
|
As i proposed in #24262 (and found acceptance in the IRC channel), added a compiler warning for wrong escaping of curly braces.
|
|
|
|
|
|
in a format string if a wrongly escaped one is detected in a string.
|
|
There are syntax extensions that call `std::rt::begin_unwind` passing it a `usize`. I updated the syntax extension to instead pass `u32`, but for bootstrapping reasons, I needed to create a `#[cfg(stage0)]` version of `std::rt::begin_unwind` and therefore also `panic!`.
|
|
`format_args!` uses `#[allow_internal_unstable]` to access internal
functions and structs that are marked unstable. For this to work, the
spans on AST nodes referencing unstable internals must be equal (same
lo/hi values) to the `format_args!` call site, so that the stability
checker can recognize that the AST node was generated by the macro.
|
|
|
|
* In `noop_fold_expr`, call `new_span` in these cases:
- `ExprMethodCall`'s identifier
- `ExprField`'s identifier
- `ExprTupField`'s integer
Calling `new_span` for `ExprMethodCall`'s identifier is necessary to print
an acceptable diagnostic for `write!(&2, "")`. We see this error:
```
<std macros>:2:20: 2:66 error: type `&mut _` does not implement any method in scope named `write_fmt`
<std macros>:2 ( & mut * $ dst ) . write_fmt ( format_args ! ( $ ( $ arg ) * ) ) )
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
With this change, we also see a macro expansion backtrace leading to
the `write!(&2, "")` call site.
* After fully expanding a macro, we replace the expansion expression's
span with the original span. Call `fld.new_span` to add a backtrace to
this span. (Note that I'm call `new_span` after `bt.pop()`, so the macro
just expanded isn't on the backtrace.)
The motivating example for this change is `println!("{}")`. The format
string literal is `concat!($fmt, "arg")` and is inside the libstd macro.
We need to see the backtrace to find the `println!` call site.
* Add a backtrace to the `format_args!` format expression span.
r? alexcrichton
Addresses #23459
|
|
|
|
We provide tools to tell what exact symbols to emit for any fn or static, but
don’t quite check if that won’t cause any issues later on. Some of the issues
include LLVM mangling our names again and our names pointing to wrong locations,
us generating dumb foreign call wrappers, linker errors, extern functions
resolving to different symbols altogether (`extern {fn fail();} fail();` in some
cases calling `fail1()`), etc.
Before the commit we had a function called `note_unique_llvm_symbol`, so it is
clear somebody was aware of the issue at some point, but the function was barely
used, mostly in irrelevant locations.
Along with working on it I took liberty to start refactoring trans/base into
a few smaller modules. The refactoring is incomplete and I hope I will find some
motivation to carry on with it.
This is possibly a [breaking-change] because it makes dumbly written code
properly invalid.
This fixes all those issues about incorrect use of #[no_mangle] being not reported/misreported/ICEd by the compiler.
NB. This PR does not attempt to tackle the parallel codegen issue that was mentioned in https://github.com/rust-lang/rust/pull/22811, but I believe it should be very straightforward in a follow up PR by modifying `trans::declare::get_defined_value` to look at all the contexts.
cc @alexcrichton @huonw @nrc because you commented on the original RFC issue.
EDIT: wow, this became much bigger than I initially intended.
|
|
It was added in 2011-08-05 and reduced to a no-op ten days later.
|
|
|
|
* In noop_fold_expr, call new_span in these cases:
- ExprMethodCall's identifier
- ExprField's identifier
- ExprTupField's integer
Calling new_span for ExprMethodCall's identifier is necessary to print
an acceptable diagnostic for write!(&2, ""). We see this error:
<std macros>:2:20: 2:66 error: type `&mut _` does not implement any method in scope named `write_fmt`
<std macros>:2 ( & mut * $ dst ) . write_fmt ( format_args ! ( $ ( $ arg ) * ) ) )
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
With this change, we also see a macro expansion backtrace leading to
the write!(&2, "") call site.
* After fully expanding a macro, we replace the expansion expression's
span with the original span. Call fld.new_span to add a backtrace to
this span. (Note that I'm call new_span after bt.pop(), so the macro
just expanded isn't on the backtrace.)
The motivating example for this change is println!("{}"). The format
string literal is concat!($fmt, "arg") and is inside the libstd macro.
We need to see the backtrace to find the println! call site.
* Add a backtrace to the format_args! format expression span.
Addresses #23459
|
|
Example showing sample inputs, old message, new message:
https://gist.github.com/nikomatsakis/11126784ac678b7eb6ba
Also adds infrastructure for reporting suggestions \"in situ\" and does some (minor) cleanups to `CodeMap`.
r? @brson
|
|
|
|
Statement macros are now treated somewhat like item macros, in that a statement macro can now expand into a series of statements, rather than just a single statement.
This allows statement macros to be nested inside other kinds of macros and expand properly, where previously the expansion would only work when no nesting was present.
See:
- `src/test/run-pass/macro-stmt_macro_in_expr_macro.rs`
- `src/test/run-pass/macro-nested_stmt_macro.rs`
This changes the interface of the MacResult trait. make_stmt has become make_stmts and now returns a vector, rather than a single item. Plugin writers who were implementing MacResult will have breakage, as well as anyone using MacEager::stmt.
See:
- `src/libsyntax/ext/base.rs`
This also causes a minor difference in behavior to the diagnostics produced by certain malformed macros.
See:
- `src/test/compile-fail/macro-incomplete-parse.rs`
|
|
|
|
SmallVector::pop no longer worries about converting a Many repr downward
to One or Zero.
expand_stmt makes use of `if let` for style purposes.
|
|
|
|
Implements pop() on SmallVector, and uses it to expand the final semicolon
in a statement macro expansion more efficiently.
Corrects the placement of the call to fld.cx.bt_pop(). It must run
unconditionally to reverse the corresponding push.
|
|
|
|
remove out of date fixme.
|
|
|
|
Fix #15523.
|
|
of text (perhaps obtained by span_snippet) and then splice that edited
form back into the original file in the form of a suggestion.
|
|
columns within a line, not just the line numbers. Also try to clarify
and use the term `line_index` when 0-based.
|
|
"highlight end" and instead add a variant to `RenderSpan`
|
|
|
|
|
|
|
|
~~I believe this should fix the issue. Opening a PR to ensure noone duplicates effort, I'm running check now.~~
Closes #24091
|
|
Closes #23909
r? @nikomatsakis (or anyone else, really)
|
|
Closes #24091
|
|
Statement macros are now treated somewhat like item macros, in that a
statement macro can now expand into a series of statements, rather than
just a single statement.
This allows statement macros to be nested inside other kinds of macros and
expand properly, where previously the expansion would only work when no
nesting was present.
See: src/test/run-pass/macro-stmt_macro_in_expr_macro.rs
src/test/run-pass/macro-nested_stmt_macro.rs
This changes the interface of the MacResult trait. make_stmt has become
make_stmts and now returns a vector, rather than a single item. Plugin
writers who were implementing MacResult will have breakage, as well as
anyone using MacEager::stmt.
See: src/libsyntax/ext/base.rs
This also causes a minor difference in behavior to the diagnostics
produced by certain malformed macros.
See: src/test/compile-fail/macro-incomplete-parse.rs
|
|
Issue #22425
|
|
|
