From 4eb9ab00adb2ed8d807343b7238c6fcb54c17d57 Mon Sep 17 00:00:00 2001 From: Robert Holt Date: Thu, 22 Mar 2018 23:43:20 -0700 Subject: [PATCH 1/8] Add #requires RFC draft --- 1-Draft/RFCNNNN-#Requires-Additions.md | 140 +++++++++++++++++++++++++ 1 file changed, 140 insertions(+) create mode 100644 1-Draft/RFCNNNN-#Requires-Additions.md diff --git a/1-Draft/RFCNNNN-#Requires-Additions.md b/1-Draft/RFCNNNN-#Requires-Additions.md new file mode 100644 index 00000000..a1ace0d1 --- /dev/null +++ b/1-Draft/RFCNNNN-#Requires-Additions.md @@ -0,0 +1,140 @@ +--- +RFC: RFC +Author: Robert Holt +Status: Draft +SupercededBy: +Version: +Area: \#requires +Comments Due: 2018-05-15 +Plan to implement: Yes +--- + +# \#Requires Additions + +Currently, PowerShell's `#requires` statement (or perhaps +pragma?) supports the following parameters: + +* `-Version [.]`, where a minimum PowerShell version can be specified +* `-PSSnapin [-Version ]`, where a required PowerShell Snapin can be specified +* `-Modules { | }`, where PowerShell modules that are required can be specified +* `-ShellId `, where the required Shell ID can be specified +* `-RunAsAdministrator`, where the script is required to be run as administrator + +These features are documented in [about_Requires](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_requires?view=powershell-6), along with the statement that: + +> You can use #Requires statements in any script. You +> cannot use them in functions, cmdlets, or snap-ins. + +Currently however, this is untrue, as `#requires` +statements are effectively hoisted to the top of any +script, no matter where they are placed in that script. + +This RFC proposes the following changes: + +* Only allow `#requires` at the top level of a script, + before any lines that are not comments (i.e. with the + intention that a hashbang can still work, just before + any executable PowerShell code). Placing `#requires` + anywhere will cause a parse-time error. This would be + a **breaking change**, albeit one that the documentation + already claims to be in force. +* Using `#requires` in the interactive console will cause + a parse-time error. This could be a **minor breaking + change**, since currently PowerShell throws a [pipeline + creation error](https://github.com/PowerShell/PowerShell/issues/3803). +* Add support for the following new parameters (each + independently up for discussion): + * `-OS {Windows | Linux | MacOS}`, where an + operating system (or possibly combination of them) can + be specified as required. See [this PowerShell issue](https://github.com/PowerShell/PowerShell/issues/3751). + * `-Assembly `, where a .NET assembly can + be specified as required. See [this PowerShell issue](https://github.com/PowerShell/PowerShell/issues/5022). + * `-MaxVersion [.]`, where a maximum PowerShell + version can be specified as required. See [this PowerShell issue](https://github.com/PowerShell/PowerShell/issues/2846). + +## Motivation + +> As a PowerShell user, I can be sure that all the +> `#requires` statements in a script come before any +> PowerShell code, so that it's clear they always +> execute first, and so they can all be found easily. + +> As a PowerShell user, I get feedback that `#requires` +> statements cannot be used in the interactive console, +> so that it's clear that they have no effect on an +> interactive session. + +> As a PowerShell user, I can specify that my script +> `#requires` being run on a specific operating system, +> so that I can effectively, efficiently and declaratively +> guarantee that it is used only on systems I designed it +> for. + +> As a PowerShell user, I can specify that my script +> `#requires` a given .NET Assembly to run in an +> efficient and declarative way, so that I don't have +> to do complex runtime logic to determine my script +> cannot run. + +> As a PowerShell user, I can specify that my script +> `#requires` to be run in a version of PowerShell +> lower than a given version, so that I can declaratively +> prevent it from being run in an environment where +> changes to PowerShell would cause unintended behavior. + +## Specification + +1. `#requires` statements must appear in scripts + above all executable PowerShell. Any `#requires` + statement placed after any PowerShell code causes + an unrecoverable parse-time error. +2. Any use of `#requires` in an interactive session causes + a specific parse-time error to be thrown, informing the + user that `#requires` may not be used in the interactive + console. +3. `#requires` can take an `-OS` parameter, with possible + arguments being `Windows`, `Linux` and `MacOS` (and + possibly some syntax for `or`-ing them). This check + succeeds if-and-only-if the correspoding runtime + PowerShell variable (`$IsWindows`, `$IsLinux` and + `$IsMacOS` is true). Requiring a given OS when the + corresponding runtime variable is false results in + a pre-execution error with a specific error message + stating that the script is required to be run on a + different operating system. +4. `#requires` can take an `-Assembly` parameter, with + possible arguments being exactly what a `using assembly` + statement will accept. If a required assembly is not + present on the executing system, a pre-execution error + is raised. +5. `#requires` can take a `-MaxVersion` parameter, with + a major version and optional minor version, to define + the maximum (inclusive) version of PowerShell it should + run on. The version given does not need to correspond to + any version of PowerShell, but will just be compared in + standard lexicographic tuple order. Executing a script + required to be on a version of PowerShell strictly lower + than the executing version results in a pre-execution + error. + +Finally, scripts with `#requires` in them should still +be editable in contexts that do not satisfy their +requirements. For example, a script with `#requires -OS +MacOS` at the top should still allow a full editing user +experience on Windows or Linux. For context, see [this +PowerShell issue](https://github.com/PowerShell/PowerShell/issues/4549). + +## Alternate Proposals and Considerations + +* An `-Assembly` parameter may be unneccessary, given the + possibility of using `using assembly `. +* Given the suite of proposed changes to `#requires`, any + other proposed parameters for `#requires` are worth + including and discussing in this RFC. Possible + considerations are: + * `-LanguageMode`, where a script must be run in a given + PowerShell language mode. + * `-Architecture`, where a script must be run on a + machine with a given processor architecture. + * `-Platform`, rather than trying to use combining + logic with `-OS`. \ No newline at end of file From 4c7c592bcf521076b73813cfaebbd6bc9d6e79a1 Mon Sep 17 00:00:00 2001 From: Robert Holt Date: Thu, 22 Mar 2018 23:44:35 -0700 Subject: [PATCH 2/8] Correct language area --- 1-Draft/RFCNNNN-#Requires-Additions.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/1-Draft/RFCNNNN-#Requires-Additions.md b/1-Draft/RFCNNNN-#Requires-Additions.md index a1ace0d1..36c9ae9e 100644 --- a/1-Draft/RFCNNNN-#Requires-Additions.md +++ b/1-Draft/RFCNNNN-#Requires-Additions.md @@ -4,7 +4,7 @@ Author: Robert Holt Status: Draft SupercededBy: Version: -Area: \#requires +Area: Hash-requires Comments Due: 2018-05-15 Plan to implement: Yes --- @@ -26,8 +26,9 @@ These features are documented in [about_Requires](https://docs.microsoft.com/en- > cannot use them in functions, cmdlets, or snap-ins. Currently however, this is untrue, as `#requires` -statements are effectively hoisted to the top of any -script, no matter where they are placed in that script. +statements are allowed by the parser/tokenizer anywhere in +a script and then effectively hoisted to the top of that +script, no matter where they are placed. This RFC proposes the following changes: From 0941a56ce99642dffddd76ab1745548ee90886d2 Mon Sep 17 00:00:00 2001 From: Robert Holt Date: Fri, 23 Mar 2018 11:28:03 -0700 Subject: [PATCH 3/8] More info on hashbangs --- 1-Draft/RFCNNNN-#Requires-Additions.md | 27 ++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/1-Draft/RFCNNNN-#Requires-Additions.md b/1-Draft/RFCNNNN-#Requires-Additions.md index 36c9ae9e..1e3586b9 100644 --- a/1-Draft/RFCNNNN-#Requires-Additions.md +++ b/1-Draft/RFCNNNN-#Requires-Additions.md @@ -27,18 +27,19 @@ These features are documented in [about_Requires](https://docs.microsoft.com/en- Currently however, this is untrue, as `#requires` statements are allowed by the parser/tokenizer anywhere in -a script and then effectively hoisted to the top of that -script, no matter where they are placed. +a script and then effectively hoisted to the top of that +script to be checked before any part of the script is +executed, no matter where they are placed. This RFC proposes the following changes: * Only allow `#requires` at the top level of a script, before any lines that are not comments (i.e. with the intention that a hashbang can still work, just before - any executable PowerShell code). Placing `#requires` - anywhere will cause a parse-time error. This would be - a **breaking change**, albeit one that the documentation - already claims to be in force. + any executable PowerShell code). Placing `#requires` anywhere + after will cause a parse-time error. This would be a **breaking + change**, albeit one that the documentation already claims to be + in force. * Using `#requires` in the interactive console will cause a parse-time error. This could be a **minor breaking change**, since currently PowerShell throws a [pipeline @@ -88,7 +89,12 @@ This RFC proposes the following changes: 1. `#requires` statements must appear in scripts above all executable PowerShell. Any `#requires` statement placed after any PowerShell code causes - an unrecoverable parse-time error. + an unrecoverable parse-time error. This new restriction + should not affect the usage of other comment-embedded + directives or pragmas, such as `#sig`, linter directives or + inline editor configurations. Specifically, the new `#requires` + placement restriction must not interfere with Unix-style + hashbangs (e.g. `#!/usr/bin/pwsh`). 2. Any use of `#requires` in an interactive session causes a specific parse-time error to be thrown, informing the user that `#requires` may not be used in the interactive @@ -138,4 +144,9 @@ PowerShell issue](https://github.com/PowerShell/PowerShell/issues/4549). * `-Architecture`, where a script must be run on a machine with a given processor architecture. * `-Platform`, rather than trying to use combining - logic with `-OS`. \ No newline at end of file + logic with `-OS`. +* Another requires parameter, `-PSEdition`, also seems to have + been added to the `#requires` functionality. However, it is + currently [undocumented](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_requires?view=powershell-6) and + there is an [open issue for it](https://github.com/PowerShell/PowerShell/issues/5908). It may + be worth discussing in this RFC. From 070e0db5b727ef8a105639498d33ef1528c7eb09 Mon Sep 17 00:00:00 2001 From: Robert Holt Date: Fri, 23 Mar 2018 11:29:54 -0700 Subject: [PATCH 4/8] Add PR info for interactive #requires --- 1-Draft/RFCNNNN-#Requires-Additions.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/1-Draft/RFCNNNN-#Requires-Additions.md b/1-Draft/RFCNNNN-#Requires-Additions.md index 1e3586b9..3b31db80 100644 --- a/1-Draft/RFCNNNN-#Requires-Additions.md +++ b/1-Draft/RFCNNNN-#Requires-Additions.md @@ -150,3 +150,6 @@ PowerShell issue](https://github.com/PowerShell/PowerShell/issues/4549). currently [undocumented](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_requires?view=powershell-6) and there is an [open issue for it](https://github.com/PowerShell/PowerShell/issues/5908). It may be worth discussing in this RFC. +* Because of the pipeline-crash behavior of the interactive + usage of `#requires`, there is already a PR open to change + the behavior to what is described in this RFC. From e83357853142c6a47eb4d78a4c3146875e63252c Mon Sep 17 00:00:00 2001 From: Robert Holt Date: Mon, 25 Feb 2019 17:10:02 -0800 Subject: [PATCH 5/8] Edit RFC inline with committee ruling --- 1-Draft/RFCNNNN-#Requires-Additions.md | 110 +++++++++++-------------- 1 file changed, 48 insertions(+), 62 deletions(-) diff --git a/1-Draft/RFCNNNN-#Requires-Additions.md b/1-Draft/RFCNNNN-#Requires-Additions.md index 3b31db80..e1944b4c 100644 --- a/1-Draft/RFCNNNN-#Requires-Additions.md +++ b/1-Draft/RFCNNNN-#Requires-Additions.md @@ -33,33 +33,40 @@ executed, no matter where they are placed. This RFC proposes the following changes: -* Only allow `#requires` at the top level of a script, +* Emit a warning when parsing scripts where the `#requires` + is not at the top, because of the hoisting behavior. +* Add support for the following new parameters (each + independently up for discussion): + * `-OS {Windows | Linux | MacOS}`, where an + operating system (or possibly combination of them) can + be specified as required. See [this PowerShell issue](https://github.com/PowerShell/PowerShell/issues/3751). + * `-MaximumPSVersion [.]`, where a maximum PowerShell + version can be specified as required. See [this PowerShell issue](https://github.com/PowerShell/PowerShell/issues/2846). + * `-MinimumPSVersion` as an alias of `-MinimumVersion`. + +* **Withdrawn**, in favor of `using` statements. + ~~`-Assembly `, where a .NET assembly can + be specified as required. See [this PowerShell issue](https://github.com/PowerShell/PowerShell/issues/5022).~~ +* **Withdrawn** on the basis that this could break many existing scripts. + ~~Only allow `#requires` at the top level of a script, before any lines that are not comments (i.e. with the intention that a hashbang can still work, just before any executable PowerShell code). Placing `#requires` anywhere after will cause a parse-time error. This would be a **breaking change**, albeit one that the documentation already claims to be - in force. -* Using `#requires` in the interactive console will cause + in force.~~ +* **Withdrawn** since this is difficult to implement with little gain + and it breaks the layering of the parser. + ~~Using `#requires` in the interactive console will cause a parse-time error. This could be a **minor breaking change**, since currently PowerShell throws a [pipeline - creation error](https://github.com/PowerShell/PowerShell/issues/3803). -* Add support for the following new parameters (each - independently up for discussion): - * `-OS {Windows | Linux | MacOS}`, where an - operating system (or possibly combination of them) can - be specified as required. See [this PowerShell issue](https://github.com/PowerShell/PowerShell/issues/3751). - * `-Assembly `, where a .NET assembly can - be specified as required. See [this PowerShell issue](https://github.com/PowerShell/PowerShell/issues/5022). - * `-MaxVersion [.]`, where a maximum PowerShell - version can be specified as required. See [this PowerShell issue](https://github.com/PowerShell/PowerShell/issues/2846). + creation error](https://github.com/PowerShell/PowerShell/issues/3803).~~ ## Motivation -> As a PowerShell user, I can be sure that all the -> `#requires` statements in a script come before any -> PowerShell code, so that it's clear they always -> execute first, and so they can all be found easily. +> As a PowerShell user, I will be warned about +> `#requires` statements that won't behave the +> way I might expect based on position. > As a PowerShell user, I get feedback that `#requires` > statements cannot be used in the interactive console, @@ -72,12 +79,6 @@ This RFC proposes the following changes: > guarantee that it is used only on systems I designed it > for. -> As a PowerShell user, I can specify that my script -> `#requires` a given .NET Assembly to run in an -> efficient and declarative way, so that I don't have -> to do complex runtime logic to determine my script -> cannot run. - > As a PowerShell user, I can specify that my script > `#requires` to be run in a version of PowerShell > lower than a given version, so that I can declaratively @@ -86,43 +87,31 @@ This RFC proposes the following changes: ## Specification -1. `#requires` statements must appear in scripts - above all executable PowerShell. Any `#requires` - statement placed after any PowerShell code causes - an unrecoverable parse-time error. This new restriction - should not affect the usage of other comment-embedded - directives or pragmas, such as `#sig`, linter directives or - inline editor configurations. Specifically, the new `#requires` - placement restriction must not interfere with Unix-style - hashbangs (e.g. `#!/usr/bin/pwsh`). -2. Any use of `#requires` in an interactive session causes - a specific parse-time error to be thrown, informing the - user that `#requires` may not be used in the interactive - console. -3. `#requires` can take an `-OS` parameter, with possible - arguments being `Windows`, `Linux` and `MacOS` (and - possibly some syntax for `or`-ing them). This check - succeeds if-and-only-if the correspoding runtime - PowerShell variable (`$IsWindows`, `$IsLinux` and - `$IsMacOS` is true). Requiring a given OS when the - corresponding runtime variable is false results in +1. `#requires` statements appearing before any + line that is not blank or a comment (i.e. any semantic statement) + will generate a warning at parse-time about being hoisted to the top of the script. + Other comments, such as hashbangs, and blank lines + preceing a `#requires` will not generate this warning. +2. `#requires` can take an `-OS` parameter, + with possible arguments being `Windows`, `Linux` and `MacOS`. + Multiple operating systems can be specified by providing arguments + in an array syntax, such as `#requires -OS 'Linux','MacOS'`, + with the meaning of **any** of the required operating systems. + The check for a given operating system succeeds + if-and-only-if the correspoding runtime PowerShell variable + (`$IsWindows`, `$IsLinux` and `$IsMacOS`) + executed on that system would be true. + Requiring a given OS when the corresponding runtime variable is false results in a pre-execution error with a specific error message stating that the script is required to be run on a different operating system. -4. `#requires` can take an `-Assembly` parameter, with - possible arguments being exactly what a `using assembly` - statement will accept. If a required assembly is not - present on the executing system, a pre-execution error - is raised. -5. `#requires` can take a `-MaxVersion` parameter, with - a major version and optional minor version, to define - the maximum (inclusive) version of PowerShell it should - run on. The version given does not need to correspond to - any version of PowerShell, but will just be compared in - standard lexicographic tuple order. Executing a script - required to be on a version of PowerShell strictly lower - than the executing version results in a pre-execution - error. +3. `#requires` can take a `-MaximumPSVersion` parameter, + with a major version and optional minor version, + to define the maximum (inclusive) version of PowerShell it should run on. + The version given does not need to correspond to any existing version of PowerShell, + but will be compared in standard PowerShell version comparison logic. + Executing a script required to be on a version of PowerShell strictly lower + than the executing version results in a pre-execution error. Finally, scripts with `#requires` in them should still be editable in contexts that do not satisfy their @@ -133,8 +122,8 @@ PowerShell issue](https://github.com/PowerShell/PowerShell/issues/4549). ## Alternate Proposals and Considerations -* An `-Assembly` parameter may be unneccessary, given the - possibility of using `using assembly `. +* **Withdrawn**. ~~An `-Assembly` parameter may be unneccessary, given the + possibility of using `using assembly `.~~ * Given the suite of proposed changes to `#requires`, any other proposed parameters for `#requires` are worth including and discussing in this RFC. Possible @@ -150,6 +139,3 @@ PowerShell issue](https://github.com/PowerShell/PowerShell/issues/4549). currently [undocumented](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_requires?view=powershell-6) and there is an [open issue for it](https://github.com/PowerShell/PowerShell/issues/5908). It may be worth discussing in this RFC. -* Because of the pipeline-crash behavior of the interactive - usage of `#requires`, there is already a PR open to change - the behavior to what is described in this RFC. From 3e974d478c36f145871acea4a035e981e7d29e10 Mon Sep 17 00:00:00 2001 From: Robert Holt Date: Mon, 15 Apr 2019 11:19:59 -0700 Subject: [PATCH 6/8] Move withdrwan proposals to the bottom --- 1-Draft/RFCNNNN-#Requires-Additions.md | 48 +++++++++++--------------- 1 file changed, 21 insertions(+), 27 deletions(-) diff --git a/1-Draft/RFCNNNN-#Requires-Additions.md b/1-Draft/RFCNNNN-#Requires-Additions.md index e1944b4c..392ae483 100644 --- a/1-Draft/RFCNNNN-#Requires-Additions.md +++ b/1-Draft/RFCNNNN-#Requires-Additions.md @@ -11,8 +11,7 @@ Plan to implement: Yes # \#Requires Additions -Currently, PowerShell's `#requires` statement (or perhaps -pragma?) supports the following parameters: +Currently, PowerShell's `#requires` statement (or pragma) supports the following parameters: * `-Version [.]`, where a minimum PowerShell version can be specified * `-PSSnapin [-Version ]`, where a required PowerShell Snapin can be specified @@ -44,35 +43,12 @@ This RFC proposes the following changes: version can be specified as required. See [this PowerShell issue](https://github.com/PowerShell/PowerShell/issues/2846). * `-MinimumPSVersion` as an alias of `-MinimumVersion`. -* **Withdrawn**, in favor of `using` statements. - ~~`-Assembly `, where a .NET assembly can - be specified as required. See [this PowerShell issue](https://github.com/PowerShell/PowerShell/issues/5022).~~ -* **Withdrawn** on the basis that this could break many existing scripts. - ~~Only allow `#requires` at the top level of a script, - before any lines that are not comments (i.e. with the - intention that a hashbang can still work, just before - any executable PowerShell code). Placing `#requires` anywhere - after will cause a parse-time error. This would be a **breaking - change**, albeit one that the documentation already claims to be - in force.~~ -* **Withdrawn** since this is difficult to implement with little gain - and it breaks the layering of the parser. - ~~Using `#requires` in the interactive console will cause - a parse-time error. This could be a **minor breaking - change**, since currently PowerShell throws a [pipeline - creation error](https://github.com/PowerShell/PowerShell/issues/3803).~~ - ## Motivation > As a PowerShell user, I will be warned about > `#requires` statements that won't behave the > way I might expect based on position. -> As a PowerShell user, I get feedback that `#requires` -> statements cannot be used in the interactive console, -> so that it's clear that they have no effect on an -> interactive session. - > As a PowerShell user, I can specify that my script > `#requires` being run on a specific operating system, > so that I can effectively, efficiently and declaratively @@ -122,8 +98,6 @@ PowerShell issue](https://github.com/PowerShell/PowerShell/issues/4549). ## Alternate Proposals and Considerations -* **Withdrawn**. ~~An `-Assembly` parameter may be unneccessary, given the - possibility of using `using assembly `.~~ * Given the suite of proposed changes to `#requires`, any other proposed parameters for `#requires` are worth including and discussing in this RFC. Possible @@ -139,3 +113,23 @@ PowerShell issue](https://github.com/PowerShell/PowerShell/issues/4549). currently [undocumented](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_requires?view=powershell-6) and there is an [open issue for it](https://github.com/PowerShell/PowerShell/issues/5908). It may be worth discussing in this RFC. + +### Withdrawn proposals + +* `-Assembly `, where a .NET assembly can + be specified as required. See [this PowerShell #5022](https://github.com/PowerShell/PowerShell/issues/5022). + **Withdrawn in favor of `using` statements.** +* Only allow `#requires` at the top level of a script, + before any lines that are not comments (i.e. with the + intention that a hashbang can still work, just before + any executable PowerShell code). Placing `#requires` anywhere + after will cause a parse-time error. This would be a **breaking + change**, albeit one that the documentation already claims to be + in force. + **Withdrawn on the basis that this could break many existing scripts.** + Instead, a warning is proposed. +* Using `#requires` in the interactive console will cause + a parse-time error. This could be a **minor breaking + change**, since currently PowerShell throws a [pipeline + creation error](https://github.com/PowerShell/PowerShell/issues/3803). + **Withdrawn since this is difficult to implement with little gain and breaks the layering of the parser.** \ No newline at end of file From 37a2dcdcfee8508c813daab649ceaece40965aaf Mon Sep 17 00:00:00 2001 From: Joey Aiello Date: Mon, 15 Apr 2019 13:24:42 -0700 Subject: [PATCH 7/8] Accept and merge RFC0035 on #requires additions --- .../RFC0035-#Requires-Additions.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename 1-Draft/RFCNNNN-#Requires-Additions.md => 2-Draft-Accepted/RFC0035-#Requires-Additions.md (98%) diff --git a/1-Draft/RFCNNNN-#Requires-Additions.md b/2-Draft-Accepted/RFC0035-#Requires-Additions.md similarity index 98% rename from 1-Draft/RFCNNNN-#Requires-Additions.md rename to 2-Draft-Accepted/RFC0035-#Requires-Additions.md index 392ae483..60e730af 100644 --- a/1-Draft/RFCNNNN-#Requires-Additions.md +++ b/2-Draft-Accepted/RFC0035-#Requires-Additions.md @@ -1,9 +1,9 @@ --- RFC: RFC Author: Robert Holt -Status: Draft +Status: Draft-Accepted SupercededBy: -Version: +Version: 0.2 Area: Hash-requires Comments Due: 2018-05-15 Plan to implement: Yes @@ -132,4 +132,4 @@ PowerShell issue](https://github.com/PowerShell/PowerShell/issues/4549). a parse-time error. This could be a **minor breaking change**, since currently PowerShell throws a [pipeline creation error](https://github.com/PowerShell/PowerShell/issues/3803). - **Withdrawn since this is difficult to implement with little gain and breaks the layering of the parser.** \ No newline at end of file + **Withdrawn since this is difficult to implement with little gain and breaks the layering of the parser.** From ae5a1036b676a30a882d79c0dda413d5f3d45233 Mon Sep 17 00:00:00 2001 From: Joey Aiello Date: Mon, 15 Apr 2019 13:26:47 -0700 Subject: [PATCH 8/8] Fix small typo in RFC0035 --- 2-Draft-Accepted/RFC0035-#Requires-Additions.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/2-Draft-Accepted/RFC0035-#Requires-Additions.md b/2-Draft-Accepted/RFC0035-#Requires-Additions.md index 60e730af..80d48661 100644 --- a/2-Draft-Accepted/RFC0035-#Requires-Additions.md +++ b/2-Draft-Accepted/RFC0035-#Requires-Additions.md @@ -63,11 +63,11 @@ This RFC proposes the following changes: ## Specification -1. `#requires` statements appearing before any +1. `#requires` statements appearing after any line that is not blank or a comment (i.e. any semantic statement) will generate a warning at parse-time about being hoisted to the top of the script. Other comments, such as hashbangs, and blank lines - preceing a `#requires` will not generate this warning. + preceding a `#requires` will not generate this warning. 2. `#requires` can take an `-OS` parameter, with possible arguments being `Windows`, `Linux` and `MacOS`. Multiple operating systems can be specified by providing arguments