jiebi/CodeConvo huggingface dataset:
Code change:
The expansion of and both currently cause code to fail the stability check because they expand to reveal unstable implementation details. A seemingly reasonable solution to this would be to just not run the analysis on any code that has been macro-expanded. cc
I definitely agree with this approach: we should be able to annotate a macro with a stability level, and that's what should count for its users. Do we have a way of telling what part of an AST was generated via macro expansion by the time we get to linting?
Mostly; there's the field of a : for normal code, for macro generated code (basically containing the backtrace of macro invocations that led to that point).
OK, that makes this sound like a pretty easy fix. I'll take a quick look at it tomorrow (unless wants to?)
Hm, this seems slightly subtle, since the contents of a macro would then never be checked for stability. This differs to a conventional function, e.g. given , won't warn, but the contents of is still checked, while where is just never checked. (Of course, macros and phasing are both feature gated so you have to opt-in to instability to use non-standard macros anyway.)
Good point. Also, it looks tricky with the current infrastructure to even lint on the macro invocation -- the backtrace of macro expansion does not appear to link to the def_id of the macro (or give any other way of getting at the macro's stability). Nevertheless, I think we should bail out of the lint when we hit the results of expansion; those should be checked, if anywhere, at the site of macro definition. One other question: do syntax extensions also produce the span information you mentioned above? I ask because original problematic cases are written syntax extensions. If not, is there some other way of telling that an expansion happened?
I have a patch ready that bails of out the lint on expanded code. This also seems to mask uses of . If y'all are ok with this strategy for now, I'll file a PR.
Sounds good to me. Thanks!
cc

Related discussion:
text: // aux-build:lint_stability.rs // aux-build:inherited_stability.rs <del> #![feature(globs)] </del> <ins> #![feature(globs, phase)] </ins> #![deny(unstable)] #![deny(deprecated)] #![deny(experimental)] #![allow(dead_code)] mod cross_crate { <ins> #[phase(plugin, link)] </ins> extern crate lint_stability; use self::lint_stability::*;
Code change:
The expansion of and both currently cause code to fail the stability check because they expand to reveal unstable implementation details. A seemingly reasonable solution to this would be to just not run the analysis on any code that has been macro-expanded. cc
I definitely agree with this approach: we should be able to annotate a macro with a stability level, and that's what should count for its users. Do we have a way of telling what part of an AST was generated via macro expansion by the time we get to linting?
Mostly; there's the field of a : for normal code, for macro generated code (basically containing the backtrace of macro invocations that led to that point).
OK, that makes this sound like a pretty easy fix. I'll take a quick look at it tomorrow (unless wants to?)
Hm, this seems slightly subtle, since the contents of a macro would then never be checked for stability. This differs to a conventional function, e.g. given , won't warn, but the contents of is still checked, while where is just never checked. (Of course, macros and phasing are both feature gated so you have to opt-in to instability to use non-standard macros anyway.)
Good point. Also, it looks tricky with the current infrastructure to even lint on the macro invocation -- the backtrace of macro expansion does not appear to link to the def_id of the macro (or give any other way of getting at the macro's stability). Nevertheless, I think we should bail out of the lint when we hit the results of expansion; those should be checked, if anywhere, at the site of macro definition. One other question: do syntax extensions also produce the span information you mentioned above? I ask because original problematic cases are written syntax extensions. If not, is there some other way of telling that an expansion happened?
I have a patch ready that bails of out the lint on expanded code. This also seems to mask uses of . If y'all are ok with this strategy for now, I'll file a PR.
Sounds good to me. Thanks!
cc

Related discussion:
text: foo.method_locked_text(); foo.trait_locked_text(); let _ = DeprecatedStruct { i: 0 }; //~ ERROR use of deprecated item let _ = ExperimentalStruct { i: 0 }; //~ ERROR use of experimental item let _ = UnstableStruct { i: 0 }; //~ ERROR use of unstable item
Code change:
The expansion of and both currently cause code to fail the stability check because they expand to reveal unstable implementation details. A seemingly reasonable solution to this would be to just not run the analysis on any code that has been macro-expanded. cc
I definitely agree with this approach: we should be able to annotate a macro with a stability level, and that's what should count for its users. Do we have a way of telling what part of an AST was generated via macro expansion by the time we get to linting?
Mostly; there's the field of a : for normal code, for macro generated code (basically containing the backtrace of macro invocations that led to that point).
OK, that makes this sound like a pretty easy fix. I'll take a quick look at it tomorrow (unless wants to?)
Hm, this seems slightly subtle, since the contents of a macro would then never be checked for stability. This differs to a conventional function, e.g. given , won't warn, but the contents of is still checked, while where is just never checked. (Of course, macros and phasing are both feature gated so you have to opt-in to instability to use non-standard macros anyway.)
Good point. Also, it looks tricky with the current infrastructure to even lint on the macro invocation -- the backtrace of macro expansion does not appear to link to the def_id of the macro (or give any other way of getting at the macro's stability). Nevertheless, I think we should bail out of the lint when we hit the results of expansion; those should be checked, if anywhere, at the site of macro definition. One other question: do syntax extensions also produce the span information you mentioned above? I ask because original problematic cases are written syntax extensions. If not, is there some other way of telling that an expansion happened?
I have a patch ready that bails of out the lint on expanded code. This also seems to mask uses of . If y'all are ok with this strategy for now, I'll file a PR.
Sounds good to me. Thanks!
cc

Related discussion:
text: let _ = StableTupleStruct (1); let _ = FrozenTupleStruct (1); let _ = LockedTupleStruct (1); <ins> // At the moment, the following just checks that the stability // level of expanded code does not trigger the // lint. Eventually, we will want to lint the contents of the // macro in the module *defining* it. Also, stability levels // on macros themselves are not yet linted. macro_test!(); </ins> } fn test_method_param<F: Trait>(foo: F) {
Code change:
Right now we are running 8-core/15GM VMs but only 2 builds at a time, usually with -j2. It seems like we could easily bump this to 3 builds at a time to improve our utilization.
We might also switch back to high-mem instances, which have 30GB RAM, but slightly slower CPU's. That would allow us many more builds.
I've bumped the builds per slave to 3.

Related discussion:
text: **Source:** https://github.com/rust-lang/rust-analyzer/blob/master/crates/rust-analyzer/src/config.rs[config.rs] <del> The <<_installation,Installation>> section contains details on configuration for some of the editors. </del> <ins> The <<installation,Installation>> section contains details on configuration for some of the editors. </ins> In general `rust-analyzer` is configured via LSP messages, which means that it's up to the editor to decide on the exact format and location of configuration files. Some clients, such as <<vs-code,VS Code>> or <<coc-rust-analyzer,COC plugin in Vim>> provide `rust-analyzer` specific configuration UIs. Others may require you to know a bit more about the interaction with `rust-analyzer`.
Code change:
Defining macros recursively like so will lead rustc to cause a stack overflow. It would be useful to improve the error message for that problem. There is currently no error message specified for that issue.
We already have a field in . We can copy it to libsyntax's and then track the recursion depth in .
I am looking into this issue. Howerver it seems like the same and are used for macro expansion, so it seems like recursion depth cannot be tracked naively.
The methods and already maintain a sort of stack of macro invocations. They can also maintain a counter so that we don't have to walk that stack on every check (it's a kind of indirect linked list).
Now that recursion depth is limited, is there anyway to configure it from the command line? The current depth setting (64?) is too aggressive for some macro magic I am working on, that recurses heavily.
I could at least increase it to 256 if that would help. Other than that someone else ( maybe) should look into it.
My patch did not include any method to customize the depth limit. I just used 64 because defaults to that as well. I am not aware of a command line interface to change session attributes, but I am not very familiar with rustc`s command line interface. Another way to customize the recursion depth for macro expansions could be using something like for macros which result in deeper recursions, but no in an infinite recursion. Anyhow, if there is a decision to do it one way or another, I'd be happy to work on a patch.
Could we at least for now bump the limit up to something much larger? The current setting of 64 is probably too low for macros that rely on reduction rules. (ie that match a portion of a statement and pass the remainder to another macro (often itself) for further expansion). I don't have a good handle on the expense of each macro expansion in terms of compiler memory/time ... but is there any reason for it not to be a number on a much larger scale, such as 1024?
I like the idea of a file/crate attribute to govern the recursion depth of macros expanded within that crate.
I will try to increase it to 2048. Someone else should maybe look into the attribute or command line argument thing.
Seems that 2048 is way to high and already causes stack overflows. If just the compiler wouldn't compile forever...
Seems surprising ... are you changing the to be 2048, or changing it at the level as well?
Just the ExpansionConfig limit, since the session limit won't go crazy way too far. I guess 1024 is still ok for macros. It is compiling and testing right now, so I can tell you more later.
Ah, I misunderstood you, I thought you meant the overflows were happening when compiling the compiler! You mean rather that an infinite recursion test will overflow before it hits the 2048 limit I think.
Yes
I got a workaround, but I guess it is not the best way. Sadly I got ill, so I won't be able to work on it further. Maybe someone else could go on? /cc ()

Related discussion:
text: pub exported_macros: Vec<P<ast::Item>>, pub syntax_env: SyntaxEnv, <ins> pub recursion_count: uint, </ins> } impl<'a> ExtCtxt<'a> {
Code change:
Defining macros recursively like so will lead rustc to cause a stack overflow. It would be useful to improve the error message for that problem. There is currently no error message specified for that issue.
We already have a field in . We can copy it to libsyntax's and then track the recursion depth in .
I am looking into this issue. Howerver it seems like the same and are used for macro expansion, so it seems like recursion depth cannot be tracked naively.
The methods and already maintain a sort of stack of macro invocations. They can also maintain a counter so that we don't have to walk that stack on every check (it's a kind of indirect linked list).
Now that recursion depth is limited, is there anyway to configure it from the command line? The current depth setting (64?) is too aggressive for some macro magic I am working on, that recurses heavily.
I could at least increase it to 256 if that would help. Other than that someone else ( maybe) should look into it.
My patch did not include any method to customize the depth limit. I just used 64 because defaults to that as well. I am not aware of a command line interface to change session attributes, but I am not very familiar with rustc`s command line interface. Another way to customize the recursion depth for macro expansions could be using something like for macros which result in deeper recursions, but no in an infinite recursion. Anyhow, if there is a decision to do it one way or another, I'd be happy to work on a patch.
Could we at least for now bump the limit up to something much larger? The current setting of 64 is probably too low for macros that rely on reduction rules. (ie that match a portion of a statement and pass the remainder to another macro (often itself) for further expansion). I don't have a good handle on the expense of each macro expansion in terms of compiler memory/time ... but is there any reason for it not to be a number on a much larger scale, such as 1024?
I like the idea of a file/crate attribute to govern the recursion depth of macros expanded within that crate.
I will try to increase it to 2048. Someone else should maybe look into the attribute or command line argument thing.
Seems that 2048 is way to high and already causes stack overflows. If just the compiler wouldn't compile forever...
Seems surprising ... are you changing the to be 2048, or changing it at the level as well?
Just the ExpansionConfig limit, since the session limit won't go crazy way too far. I guess 1024 is still ok for macros. It is compiling and testing right now, so I can tell you more later.
Ah, I misunderstood you, I thought you meant the overflows were happening when compiling the compiler! You mean rather that an infinite recursion test will overflow before it hits the 2048 limit I think.
Yes
I got a workaround, but I guess it is not the best way. Sadly I got ill, so I won't be able to work on it further. Maybe someone else could go on? /cc ()

Related discussion:
text: trace_mac: false, exported_macros: Vec::new(), syntax_env: env, <ins> recursion_count: 0, </ins> } }
Code change:
Defining macros recursively like so will lead rustc to cause a stack overflow. It would be useful to improve the error message for that problem. There is currently no error message specified for that issue.
We already have a field in . We can copy it to libsyntax's and then track the recursion depth in .
I am looking into this issue. Howerver it seems like the same and are used for macro expansion, so it seems like recursion depth cannot be tracked naively.
The methods and already maintain a sort of stack of macro invocations. They can also maintain a counter so that we don't have to walk that stack on every check (it's a kind of indirect linked list).
Now that recursion depth is limited, is there anyway to configure it from the command line? The current depth setting (64?) is too aggressive for some macro magic I am working on, that recurses heavily.
I could at least increase it to 256 if that would help. Other than that someone else ( maybe) should look into it.
My patch did not include any method to customize the depth limit. I just used 64 because defaults to that as well. I am not aware of a command line interface to change session attributes, but I am not very familiar with rustc`s command line interface. Another way to customize the recursion depth for macro expansions could be using something like for macros which result in deeper recursions, but no in an infinite recursion. Anyhow, if there is a decision to do it one way or another, I'd be happy to work on a patch.
Could we at least for now bump the limit up to something much larger? The current setting of 64 is probably too low for macros that rely on reduction rules. (ie that match a portion of a statement and pass the remainder to another macro (often itself) for further expansion). I don't have a good handle on the expense of each macro expansion in terms of compiler memory/time ... but is there any reason for it not to be a number on a much larger scale, such as 1024?
I like the idea of a file/crate attribute to govern the recursion depth of macros expanded within that crate.
I will try to increase it to 2048. Someone else should maybe look into the attribute or command line argument thing.
Seems that 2048 is way to high and already causes stack overflows. If just the compiler wouldn't compile forever...
Seems surprising ... are you changing the to be 2048, or changing it at the level as well?
Just the ExpansionConfig limit, since the session limit won't go crazy way too far. I guess 1024 is still ok for macros. It is compiling and testing right now, so I can tell you more later.
Ah, I misunderstood you, I thought you meant the overflows were happening when compiling the compiler! You mean rather that an infinite recursion test will overflow before it hits the 2048 limit I think.
Yes
I got a workaround, but I guess it is not the best way. Sadly I got ill, so I won't be able to work on it further. Maybe someone else could go on? /cc ()

Related discussion:
text: pub crate_name: String, pub deriving_hash_type_parameter: bool, pub enable_quotes: bool, <ins> pub recursion_limit: uint, </ins> } impl ExpansionConfig {
Code change:
Defining macros recursively like so will lead rustc to cause a stack overflow. It would be useful to improve the error message for that problem. There is currently no error message specified for that issue.
We already have a field in . We can copy it to libsyntax's and then track the recursion depth in .
I am looking into this issue. Howerver it seems like the same and are used for macro expansion, so it seems like recursion depth cannot be tracked naively.
The methods and already maintain a sort of stack of macro invocations. They can also maintain a counter so that we don't have to walk that stack on every check (it's a kind of indirect linked list).
Now that recursion depth is limited, is there anyway to configure it from the command line? The current depth setting (64?) is too aggressive for some macro magic I am working on, that recurses heavily.
I could at least increase it to 256 if that would help. Other than that someone else ( maybe) should look into it.
My patch did not include any method to customize the depth limit. I just used 64 because defaults to that as well. I am not aware of a command line interface to change session attributes, but I am not very familiar with rustc`s command line interface. Another way to customize the recursion depth for macro expansions could be using something like for macros which result in deeper recursions, but no in an infinite recursion. Anyhow, if there is a decision to do it one way or another, I'd be happy to work on a patch.
Could we at least for now bump the limit up to something much larger? The current setting of 64 is probably too low for macros that rely on reduction rules. (ie that match a portion of a statement and pass the remainder to another macro (often itself) for further expansion). I don't have a good handle on the expense of each macro expansion in terms of compiler memory/time ... but is there any reason for it not to be a number on a much larger scale, such as 1024?
I like the idea of a file/crate attribute to govern the recursion depth of macros expanded within that crate.
I will try to increase it to 2048. Someone else should maybe look into the attribute or command line argument thing.
Seems that 2048 is way to high and already causes stack overflows. If just the compiler wouldn't compile forever...
Seems surprising ... are you changing the to be 2048, or changing it at the level as well?
Just the ExpansionConfig limit, since the session limit won't go crazy way too far. I guess 1024 is still ok for macros. It is compiling and testing right now, so I can tell you more later.
Ah, I misunderstood you, I thought you meant the overflows were happening when compiling the compiler! You mean rather that an infinite recursion test will overflow before it hits the 2048 limit I think.
Yes
I got a workaround, but I guess it is not the best way. Sadly I got ill, so I won't be able to work on it further. Maybe someone else could go on? /cc ()

Related discussion:
text: crate_name: crate_name, deriving_hash_type_parameter: false, enable_quotes: false, <ins> recursion_limit: 64, </ins> } } }
Code change:
Currently a macro cannot create a pub fn. It can however create a regular fn. Fails with:
This is a problem with methods specifically, it works fine if is used to define a normal top-level function (i.e. not inside an ).
Dupe of ?
thanks.

Related discussion:
text: **Source:** https://github.com/rust-lang/rust-analyzer/blob/master/crates/rust-analyzer/src/config.rs[config.rs] <del> The <<_installation,Installation>> section contains details on configuration for some of the editors. </del> <ins> The <<installation,Installation>> section contains details on configuration for some of the editors. </ins> In general `rust-analyzer` is configured via LSP messages, which means that it's up to the editor to decide on the exact format and location of configuration files. Some clients, such as <<vs-code,VS Code>> or <<coc-rust-analyzer,COC plugin in Vim>> provide `rust-analyzer` specific configuration UIs. Others may require you to know a bit more about the interaction with `rust-analyzer`.
Code change:
Here I'm using a fully-realized type that should be FFI safe, but rustc continues to complain:
Closing until I have an example that's actually correct.

Related discussion:
text: **Source:** https://github.com/rust-lang/rust-analyzer/blob/master/crates/rust-analyzer/src/config.rs[config.rs] <del> The <<_installation,Installation>> section contains details on configuration for some of the editors. </del> <ins> The <<installation,Installation>> section contains details on configuration for some of the editors. </ins> In general `rust-analyzer` is configured via LSP messages, which means that it's up to the editor to decide on the exact format and location of configuration files. Some clients, such as <<vs-code,VS Code>> or <<coc-rust-analyzer,COC plugin in Vim>> provide `rust-analyzer` specific configuration UIs. Others may require you to know a bit more about the interaction with `rust-analyzer`.
Code change:
If I'm not mistaken, . It won't terminate the program. It's or unwraps the value. Also, wouldn't a call to the IoResult's  be more direct? Although the custom failure message would be lost.
I thought this was already fixed :/

Related discussion:
text: **Source:** https://github.com/rust-lang/rust-analyzer/blob/master/crates/rust-analyzer/src/config.rs[config.rs] <del> The <<_installation,Installation>> section contains details on configuration for some of the editors. </del> <ins> The <<installation,Installation>> section contains details on configuration for some of the editors. </ins> In general `rust-analyzer` is configured via LSP messages, which means that it's up to the editor to decide on the exact format and location of configuration files. Some clients, such as <<vs-code,VS Code>> or <<coc-rust-analyzer,COC plugin in Vim>> provide `rust-analyzer` specific configuration UIs. Others may require you to know a bit more about the interaction with `rust-analyzer`.
Code change:
If I'm not mistaken, . It won't terminate the program. It's or unwraps the value. Also, wouldn't a call to the IoResult's  be more direct? Although the custom failure message would be lost.
I thought this was already fixed :/

Related discussion:
text: # } fn compute_area(shape: &Shape) -> f64 { match *shape { <del> Circle(_, radius) => 2.0 * std::f64::consts::PI * radius * radius, </del> <ins> Circle(_, radius) => std::f64::consts::PI * radius * radius, </ins> Rectangle(_, ref size) => size.w * size.h } }