Add "trace-macros" as a compiler flag #23703
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Now that we check the stability of fields, the fields of this struct should also be stable.
There have been some recent panics on the bots and this commit is an attempt to appease them. Previously it was considered invalid to run `rt::at_exit` after the handlers had already started running. Due to the multithreaded nature of applications, however, it is not always possible to guarantee this. For example [this program][ex] will show off the abort. [ex]: https://gist.github.com/alexcrichton/56300b87af6fa554e52d The semantics of the `rt::at_exit` function have been modified as such: * It is now legal to call `rt::at_exit` at any time. The return value now indicates whether the closure was successfully registered or not. Callers must now decide what to do with this information. * The `rt::at_exit` handlers will now be run for a fixed number of iterations. Common cases (such as the example shown) may end up registering a new handler while others are running perhaps once or twice, so this common condition is covered by re-running the handlers a fixed number of times, after which new registrations are forbidden. Some usage of `rt::at_exit` was updated to handle these new semantics, but deprecated or unstable libraries calling `rt::at_exit` were not updated.
impls. This requires: 1. modifying trait selection a bit so that when we synthesize impls for fn pointers and closures; 2. adding code to trans so that we can synthesize a `FnMut`/`FnOnce` impl for a `Fn` closure and so forth.
impls. This is a [breaking-change] (for gated code) in that when you implement `Fn` (`FnMut`) you must also implement `FnOnce`. This commit demonstrates how to fix it.
…ip page to make it more clear.
This is pretty basic, but it's nice to have something.
This commit alters the behavior of the `Read::read_to_end()` method to zero all memory instead of passing an uninitialized buffer to `read`. This change is motivated by the [discussion on the internals forum][discuss] where the conclusion has been that the standard library will not expose uninitialized memory. [discuss]: http://internals.rust-lang.org/t/uninitialized-memory/1652 Closes rust-lang#20314
This permits all coercions to be performed in casts, but adds lints to warn in those cases. Part of this patch moves cast checking to a later stage of type checking. We acquire obligations to check casts as part of type checking where we previously checked them. Once we have type checked a function or module, then we check any cast obligations which have been acquired. That means we have more type information available to check casts (this was crucial to making coercions work properly in place of some casts), but it means that casts cannot feed input into type inference. [breaking change] * Adds two new lints for trivial casts and trivial numeric casts, these are warn by default, but can cause errors if you build with warnings as errors. Previously, trivial numeric casts and casts to trait objects were allowed. * The unused casts lint has gone. * Interactions between casting and type inference have changed in subtle ways. Two ways this might manifest are: - You may need to 'direct' casts more with extra type information, for example, in some cases where `foo as _ as T` succeeded, you may now need to specify the type for `_` - Casts do not influence inference of integer types. E.g., the following used to type check: ``` let x = 42; let y = &x as *const u32; ``` Because the cast would inform inference that `x` must have type `u32`. This no longer applies and the compiler will fallback to `i32` for `x` and thus there will be a type error in the cast. The solution is to add more type information: ``` let x: u32 = 42; let y = &x as *const u32; ```
Makes Vec::push considerably smaller: 25 instructions, rather than 42, on x86_64.
Main access point of .split() and other similar methods are not using the StrExt trait anymore, so update the libcore docs to reflect this (because these docs are visible in libstd API documentation).
A lot has changed since this doc text was last touched up, and this is just a minor edit. I remove the trait section entirely since we don't use extension traits that much anymore, so there are no significant trait hilights for this module.
one of the helper method impls.
This was necessary to avoid specialized `Drop` impls for the two structs.
Main motivation was to update docs for the removal or "demotion" of certain extension traits. The update to the slice docs was larger, since the text was largely outdated.
…criminant The reassignment checker effectively only checks whether the last assignment in a body affects the discriminant, but it should of course check all the assignments. Fixes rust-lang#23698
Disable overflow checking on SIMD operations, fix rust-lang#23037
…matsakis `PathBuf::new` have been changed. Use `PathBuf::from` instead. Apply the same change for freebsd too, while here.
The reassignment checker effectively only checks whether the last assignment in a body affects the discriminant, but it should of course check all the assignments. Fixes rust-lang#23698
- Successful merges: rust-lang#23617, rust-lang#23664, rust-lang#23680, rust-lang#23684, rust-lang#23692, rust-lang#23693 - Failed merges:
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nrc (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see CONTRIBUTING.md for more information. |
| @@ -605,6 +605,8 @@ options! {DebuggingOptions, DebuggingSetter, basic_debugging_options, | |||
| "Print the size of enums and their variants"), | |||
| force_overflow_checks: Option<bool> = (None, parse_opt_bool, | |||
| "Force overflow checks on or off"), | |||
| trace_macros: bool = (false, parse_bool, | |||
| "Trace all macro invocations"), | |||
There was a problem hiding this comment.
Could this be a bit more descriptive? What is the user-visible effect of tracing?
|
The code looks good. Could you add a test please? r+ with that. Ping @kmcallister on the question of whether to remove the existing feature/macro. |
|
@nrc yes, I'll add a test |
Now that we check the stability of fields, the fields of this struct should also be stable.
…crichton 1. when mac-android cross compile and make-check , make it use gdb instead of lldb so as to it passes debuginfo tests. 2. ignore some tests on aarch64
It's considered an error to access stdout while a process is being shut down, so tweak this test a bit to actually wait for the child thread to exit.
It's considered an error to access stdout while a process is being shut down, so tweak this test a bit to actually wait for the child thread to exit. This was discovered with a recent [snap-mac3 failure](http://buildbot.rust-lang.org/builders/snap3-mac/builds/164/steps/test/logs/stdio)
I've started on refactoring the error handling code to avoid the need to reparse generated errors in `span_*`, but would rather land this incrementally as one monolithic PR (and have un-fond memories of merge conflicts from various other monoliths) r? @eddyb
|
☔ The latest upstream changes (presumably #23796) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Closing this for now - I seem to have messed it up somewhat, and I will not be able to work on it for the next week. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This takes care of #22619
Should the feature and macro be removed as well?