FileCheck-3.6 - מקוון בענן

תָכְנִית:

שֵׁם

FileCheck - מאמת קבצים התאמת דפוסים גמישים

תַקצִיר

בדיקת קבצים match-filename [--check-prefix=XXX] [--מחמיר-רווח לבן]

תיאור

בדיקת קבצים קורא שני קבצים (אחד מקלט רגיל ואחד שצוין בשורת הפקודה)
ומשתמש באחד כדי לאמת את השני. התנהגות זו שימושית במיוחד עבור חבילת הבדיקות,
שרוצה לאמת שהפלט של כלי כלשהו (למשל llc) מכיל את הצפוי
מידע (לדוגמה, movsd מ-esp או כל מה שמעניין). זה דומה
לשימוש grep, אך הוא מותאם להתאמת מספר כניסות שונות בקובץ אחד ב-a
סדר ספציפי.

אל האני match-filename file מציין את הקובץ המכיל את התבניות שיתאימו. הקובץ
לאמת נקרא מקלט רגיל אלא אם כן --קובץ קלט נעשה שימוש באופציה.

אפשרויות

עזרה הדפס סיכום של אפשרויות שורת הפקודה.

--בדוק קידומת קידומת
FileCheck מחפש את התוכן של match-filename כדי שתבניות יתאימו. על ידי
ברירת מחדל, תבניות אלו מופיעות בקידמת "חשבון:". אם תרצה להשתמש ב-a
קידומת שונה (למשל בגלל שאותו קובץ קלט בודק מספר ערכים שונים
כלי או אפשרויות), ה --בדוק קידומת ארגומנט מאפשר לך לציין אחד או יותר
קידומות כדי להתאים. קידומות מרובות שימושיות עבור בדיקות שעשויות להשתנות עבור
אפשרויות ריצה שונות, אבל רוב הקווים נשארים זהים.

--קובץ קלט שם הקובץ
קובץ לבדיקה (ברירת המחדל היא stdin).

--מחמיר-רווח לבן
כברירת מחדל, FileCheck עושה קנוניזציה של רווח לבן אופקי של קלט (רווחים וטאבים)
מה שגורם לו להתעלם מההבדלים הללו (רווח יתאים לטאב). ה
--מחמיר-רווח לבן ארגומנט משבית התנהגות זו. רצפי סוף שורה הם
קנוניזציה בסגנון UNIX \n בכל המצבים.

--משתמע-בדוק-לא דפוס בדיקה
מוסיף בדיקות שליליות מרומזות עבור הדפוסים שצוינו בין בדיקות חיוביות.
האפשרות מאפשרת כתיבת מבחנים מחמירים יותר מבלי למלא אותם בדוק-לאs.

לדוגמה, "--משתמע-בדוק-לא אַזהָרָה:" יכול להיות שימושי בעת בדיקת אבחון
הודעות מכלים שאין להם אפשרות דומה לזה מקשקש -תאשר. עם זה
אפשרות FileCheck תוודא שהקלט אינו מכיל אזהרות שאינן מכוסות על ידי
כל חשבון: דפוסי.

-הפך
הצג את מספר הגרסה של תוכנית זו.

יְצִיאָה סטָטוּס

If בדיקת קבצים מוודא שהקובץ תואם לתוכן הצפוי, הוא יוצא עם 0.
אחרת, אם לא, או אם מתרחשת שגיאה, הוא ייצא עם ערך שאינו אפס.

הדרכה

בדרך כלל נעשה שימוש ב-FileCheck ממבחני רגרסיה של LLVM, המופעלים בשורת RUN של
המבחן. דוגמה פשוטה לשימוש ב- FileCheck משורת RUN נראית כך:

; RUN: llvm-as < %s | llc -march=x86-64 | FileCheck %s

התחביר הזה אומר להעביר את הקובץ הנוכחי ("%s") לתוך llvm-as, צינור את זה לתוך llc, לאחר מכן
צינור הפלט של llc אל תוך בדיקת קבצים. זה אומר ש-FileCheck יאמת את זה
קלט סטנדרטי (פלט llc) כנגד ארגומנט שם הקובץ שצוין (המקור .ll
הקובץ שצוין על ידי "%s"). כדי לראות איך זה עובד, בואו נסתכל על שאר ה .ll פילה
(אחרי שורת ה-RUN):

הגדר void @sub1(i32* %p, i32 %v) {
כְּנִיסָה:
; בדוק: sub1:
; CHECK: subl
%0 = tail call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %p, i32 %v)
בטל מחדש
}

הגדר void @inc4(i64* %p) {
כְּנִיסָה:
; בדוק: inc4:
; CHECK: incq
%0 = tail call i64 @llvm.atomic.load.add.i64.p0i64(i64* %p, i64 1)
בטל מחדש
}

כאן אתה יכול לראות כמה "חשבון:" שורות שצוינו בהערות. עכשיו אתה יכול לראות איך הקובץ
מוכנס לתוך llvm-as, לאחר מכן llc, ופלט קוד המכונה הוא מה שאנחנו מאמתים.
FileCheck בודק את פלט קוד המכונה כדי לוודא שהוא תואם את ה-"חשבון:" שורות
לפרט.

התחביר של ה"חשבון:" קווים פשוטים מאוד: הם מחרוזות קבועות שחייבות להופיע ב
להזמין. ברירת המחדל של FileCheck מתעלמת מהבדלי רווחים אופקיים (למשל רווח הוא
מותר להתאים לכרטיסייה) אבל אחרת, התוכן של "חשבון:"נדרש קו כדי
להתאים משהו בקובץ הבדיקה במדויק.

דבר נחמד אחד ב-FileCheck (בהשוואה ל-grep) הוא שהוא מאפשר מיזוג מקרי בדיקה
יחד לקבוצות הגיוניות. לדוגמה, מכיוון שהבדיקה למעלה בודקת את ה-
"תת 1:"ו"inc4:" תוויות, זה לא יתאים אלא אם כן יש "subl"בין אלה
תוויות. אם זה היה קיים במקום אחר בקובץ, זה לא נחשב: "grep subl"
מתאים אם "subl" קיים בכל מקום בקובץ.

אל האני בדיקת קבצים -צ'ק קידומת אוֹפְּצִיָה
ה-FileCheck -צ'ק קידומת האפשרות מאפשרת להפעיל מספר תצורות בדיקה
אחד .ll קוֹבֶץ. זה שימושי בנסיבות רבות, למשל, בדיקות שונות
וריאנטים אדריכליים עם llc. הנה דוגמה פשוטה:

; RUN: llvm-as < %s | llc -mtriple=i686-apple-darwin9 -mattr=sse41 \
; הפעלה: | FileCheck %s -check-prefix=X32
; RUN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin9 -mattr=sse41 \
; הפעלה: | FileCheck %s -check-prefix=X64

הגדר <4 x i32> @pinsrd_1(i32 %s, <4 x i32> %tmp) nounwind {
%tmp1 = insertelement <4 x i32>; %tmp, i32 %s, i32 1
ret <4 x i32> %tmp1
; X32: pinsrd_1:
; X32: pinsrd $1, 4(%esp), %xmm0

; X64: pinsrd_1:
; X64: pinsrd $1, %edi, %xmm0
}

במקרה זה, אנו בודקים שאנו מקבלים את יצירת הקוד הצפוי גם עם 32 סיביות וגם
יצירת קוד 64 סיביות.

אל האני בדוק-הבא: הוראה
לפעמים אתה רוצה להתאים קווים ותרצה לוודא שההתאמות מתרחשות בדיוק
שורות עוקבות ללא קווים אחרים ביניהם. במקרה זה, אתה יכול להשתמש ב"חשבון:"
ובדוק-הבא:" הנחיות לציון זה. אם ציינת קידומת בדיקה מותאמת אישית,
רק תשתמש "-הַבָּא:". לדוגמה, משהו כזה עובד כפי שהיית מצפה:

הגדר void @t2(<2 x double>* %r, <2 x double>* %A, double %B) {
%tmp3 = טען <2 x כפול>* %A, יישור 16
%tmp7 = insertelement <2 x double> undef, כפול %B, i32 0
%tmp9 = shufflevector <2 x double> %tmp3,
<2 x double> %tmp7,
<2 x i32> < i32 0, i32 2 >
אחסן <2 x double> %tmp9, <2 x double>* %r, יישר 16
בטל מחדש

; בדוק: t2:
; בדוק: movl 8(%esp), %eax
; CHECK-NEXT: movapd (%eax), %xmm0
; CHECK-NEXT: movhpd 12(%esp), %xmm0
; CHECK-NEXT: movl 4(%esp), %eax
; CHECK-NEXT: movapd %xmm0, (%eax)
; CHECK-NEXT: ret
}

"בדוק-הבא:" הנחיות דוחות את הקלט אלא אם יש בדיוק שורה חדשה אחת בינה
וההנחיה הקודמת. א "בדוק-הבא:" לא יכולה להיות ההנחיה הראשונה בקובץ.

אל האני בדוק לא: הוראה
ה "בדוק לא:" ההנחיה משמשת כדי לוודא שמחרוזת אינה מופיעה בין שניים
משחקים (או לפני המשחק הראשון, או אחרי המשחק האחרון). למשל, כדי לוודא זאת
עומס מוסר על ידי טרנספורמציה, ניתן להשתמש בבדיקה כזו:

הגדרת i8 @coerce_offset0(i32 %V, i32* %P) {
חנות i32 %V, i32* %P

%P2 = bitcast i32* %P ל-i8*
%P3 = getelementptr i8* %P2, i32 2

%A = טען i8* %P3
ret i8 %A
; בדוק: @coerce_offset0
; CHECK-NOT: טען
; בדוק: ret i8
}

אל האני CHECK-DAG: הוראה
אם יש צורך להתאים מחרוזות שאינן מופיעות בסדר רציף בהחלט,
"CHECK-DAG:"יכול לשמש כדי לאמת אותם בין שני התאמות (או לפני המשחק הראשון,
או אחרי המשחק האחרון). לדוגמה, clang פולט גלובלים של vtable בסדר הפוך. באמצעות
CHECK-DAG:, נוכל לשמור את ההמחאות בסדר הטבעי:

// RUN: %clang_cc1 %s -emit-llvm -o - | FileCheck %s

struct Foo { Virtual void method(); };
פו פ; // emit vtable
// CHECK-DAG: @_ZTV3Foo =

struct Bar { Virtual void method(); };
בר ב;
// CHECK-DAG: @_ZTV3Bar =

בדוק לא: אפשר לערבב הנחיות CHECK-DAG: הנחיות לאי הכללת מחרוזות ביניהן
את הסביבה CHECK-DAG: הנחיות. כתוצאה מכך, הסביבה CHECK-DAG: הנחיות
לא ניתן לסדר מחדש, כלומר כל ההתרחשויות תואמות CHECK-DAG: לפני בדוק לא: אסור לי
ליפול מאחור התאמת התרחשויות CHECK-DAG: לאחר בדוק לא:. לדוגמה,

; CHECK-DAG: לפני
; בדוק לא: לא
; CHECK-DAG: אחרי

מקרה זה ידחה מחרוזות קלט איפה לפני מתרחשת לאחר לאחר.

עם משתנים שנלכדו, CHECK-DAG: מסוגל להתאים סדרים טופולוגיים תקפים של DAG
עם קצוות מהגדרת המשתנה ועד השימוש בו. זה שימושי, למשל, כאשר שלך
מקרי בדיקה צריכים להתאים רצפי פלט שונים מתזמן ההוראות. ל
דוגמא,

; CHECK-DAG: הוסף [[REG1:r[0-9]+]], r1, r2
; CHECK-DAG: הוסף [[REG2:r[0-9]+]], r3, r4
; בדוק: mul r5, [[REG1]], [[REG2]]

במקרה זה, כל סדר של שני אלה להוסיף יתאפשר הוראות.

אם אתה מגדיר ו שימוש במשתנים באותו CHECK-DAG: לחסום, שים לב לכך שה
כלל ההגדרה יכול להתאים לאחר השימוש של זה.

אז, למשל, הקוד שלהלן יעבור:

; CHECK-DAG: vmov.32 [[REG2:d[0-9]+]][0]
; CHECK-DAG: vmov.32 [[REG2]][1]
vmov.32 d0[1]
vmov.32 d0[0]

בעוד שקוד אחר זה לא יעשה:

; CHECK-DAG: vmov.32 [[REG2:d[0-9]+]][0]
; CHECK-DAG: vmov.32 [[REG2]][1]
vmov.32 d1[1]
vmov.32 d0[0]

למרות שזה יכול להיות מאוד שימושי, זה גם מסוכן, כי במקרה של רישום
רצף, עליך להיות בעל סדר חזק (קרא לפני כתיבה, העתקה לפני שימוש וכו'). אם ה
ההגדרה שהבדיקה שלך מחפשת אינה תואמת (בגלל באג במהדר), היא
עשוי להתאים רחוק יותר מהשימוש, ולהסוות באגים אמיתיים.

במקרים אלה, כדי לאכוף את הצו, השתמש בהנחיה שאינה DAG בין בלוקים של DAG.

אל האני תווית ביקורת: הוראה
לפעמים בקובץ המכיל מספר בדיקות המחולקות לבלוקים לוגיים, אחד או יותר
חשבון: הנחיות עלולות להצליח בטעות על ידי התאמת שורות בבלוק מאוחר יותר. בעוד א
בדרך כלל תיווצר שגיאה בסופו של דבר, ייתכן שהמחאה מסומנת כגורמת לשגיאה
למעשה יש קשר כלשהו למקור הבעיה בפועל.

על מנת להפיק הודעות שגיאה טובות יותר במקרים אלה, "תווית ביקורת:"הנחיה יכולה
לשמש. זה מטופל באופן זהה לרגיל לבדוק ההנחיה פרט לכך ש-FileCheck עושה
הנחה נוספת שלא ניתן להתאים גם קו התואם בהנחיה
כל צ'ק אחר קיים match-filename; זה נועד לשמש עבור קווים
המכיל תוויות או מזהים ייחודיים אחרים. מבחינה קונספטואלית, הנוכחות של CHECK-LABEL
מחלק את זרם הקלט לבלוקים נפרדים, שכל אחד מהם מעובד באופן עצמאי,
מניעת א חשבון: הוראה בבלוק אחד התואמת שורה בבלוק אחר. לדוגמה,

הגדר %struct.C* @C_ctor_base(%struct.C* %this, i32 %x) {
כְּנִיסָה:
; CHECK-LABEL: C_ctor_base:
; בדוק: mov [[SAVETHIS:r[0-9]+]], r0
; בדוק: bl A_ctor_base
; בדוק: mov r0, [[SAVETHIS]]
%0 = bitcast %struct.C* %this to %struct.A*
%call = tail call %struct.A* @A_ctor_base(%struct.A* %0)
%1 = bitcast %struct.C* %this to %struct.B*
%call2 = tail call %struct.B* @B_ctor_base(%struct.B* %1, i32 %x)
ret %struct.C* %this
}

הגדר %struct.D* @D_ctor_base(%struct.D* %this, i32 %x) {
כְּנִיסָה:
; CHECK-LABEL: D_ctor_base:

השימוש של תווית ביקורת: הנחיות במקרה זה מבטיחות שהשלושה חשבון: הנחיות
קבל רק קווים המתאימים לגוף של @C_ctor_base פונקציה, גם אם ה
דפוסים תואמים קווים שנמצאו מאוחר יותר בקובץ. יתר על כן, אם אחד משלושת אלה חשבון:
הנחיות נכשלות, FileCheck יתאושש על ידי המשך לבלוק הבא, ויאפשר ריבוי
כשלים בבדיקה שיתגלו בהזמנה אחת.

אין דרישה לכך תווית ביקורת: הנחיות מכילות מחרוזות המתאימות ל
תוויות תחביריות בפועל בשפת מקור או פלט: עליהן פשוט להתאים באופן ייחודי ל-a
שורה בודדת בקובץ המאומת.

תווית ביקורת: הנחיות אינן יכולות להכיל הגדרות או שימושים משתנים.

בדיקת קבצים תבנית תואם תחביר
ה "חשבון:"ו"בדוק לא:" שתיהן נוקטות תבנית שתתאים. לרוב השימושים של
FileCheck, התאמת מחרוזת קבועה מספיקה לחלוטין. עבור דברים מסוימים, יותר
רצוי צורה גמישה של התאמה. כדי לתמוך בכך, FileCheck מאפשר לך לציין
ביטויים רגולריים במיתרים תואמים, מוקפים בסוגרים כפולים: {{yourregex}}.
מכיוון שאנו רוצים להשתמש בהתאמת מחרוזת קבועה עבור רוב מה שאנו עושים, ל-FileCheck יש
תוכנן כדי לתמוך בערבוב והתאמת מיתרים קבועים עם רגיל
ביטויים. זה מאפשר לך לכתוב דברים כמו זה:

; בדוק: movhpd {{[0-9]+}}(%esp), {{%xmm[0-7]}}

במקרה זה, כל קיזוז מאוגר ה-ESP יתאפשר, וכל אוגר xmm יאושר
להיות מורשה.

מכיוון שביטויים רגולריים מוקפים בסוגרים כפולים, הם נבדלים ויזואלית,
ואתה לא צריך להשתמש בדמויות בריחה בתוך הסוגרים הכפולים כמו ב-C.
במקרה הנדיר שאתה רוצה להתאים פלטה כפולה במפורש מהקלט, אתה יכול
להשתמש במשהו מכוער כמו {{[{][{]}} כתבנית שלך.

בדיקת קבצים משתנים
לעתים קרובות שימושי להתאים דפוס ולאחר מכן לוודא שהוא מתרחש שוב מאוחר יותר
קוֹבֶץ. עבור בדיקות קודגן, זה יכול להיות שימושי כדי לאפשר כל רישום, אבל ודא שכן
רישום משמש באופן עקבי מאוחר יותר. כדי לעשות זאת, בדיקת קבצים מאפשר למשתנים בעלי שם להיות
מוגדרים ומוחלפים לדפוסים. הנה דוגמה פשוטה:

; בדוק: test5:
; בדוק: לא [[REGISTER:%[az]+]]
; בדוק: andw {{.*}}[[רישום]]

שורת הסימון הראשונה תואמת לביטוי רגולרי %[az]+ ולוכדת אותו לתוך המשתנה להירשם.
השורה השנייה מאמתת שכל מה שנמצא בפנים להירשם מתרחשת מאוחר יותר בקובץ לאחר an
"andw". בדיקת קבצים הפניות משתנות כלולות תמיד ב [[ ]] זוגות, ושלהם
ניתן ליצור שמות עם הביטוי הרגולרי [a-zA-Z][a-zA-Z0-9]*. אם נקודתיים אחרי השם,
אז זו הגדרה של המשתנה; אחרת, זה שימוש.

בדיקת קבצים ניתן להגדיר משתנים מספר פעמים, ושימושים תמיד מקבלים את הערך העדכני ביותר.
ניתן להשתמש במשתנים גם מאוחר יותר באותו קו שבו הם הוגדרו. לדוגמה:

; CHECK: op [[REG:r[0-9]+]], [[REG]]

יכול להיות שימושי אם אתה רוצה את האופרנדים של op להיות אותו רישום, ולא אכפת לו
באיזה רישום בדיוק מדובר.

בדיקת קבצים ביטויים
לפעמים יש צורך לאמת פלט המתייחס למספרי השורות של קובץ ההתאמה,
למשל בעת בדיקת אבחון מהדר. זה מציג שבריריות מסוימת של המשחק
מבנה קובץ, כמו "חשבון:" שורות מכילות מספרי שורה מוחלטים באותו קובץ, אשר
יש לעדכן בכל פעם שמספרי שורות משתנים עקב הוספה או מחיקה של טקסט.

כדי לתמוך במקרה זה, FileCheck מאפשר שימוש [[@קַו]], [[@LINE+ ]],
[[@קַו- ]] ביטויים בתבניות. ביטויים אלה מתרחבים למספר של
קו היכן ממוקמת תבנית (עם היסט מספר שלם אופציונלי).

בדרך זו ניתן לשים דפוסי התאמה ליד קווי הבדיקה הרלוונטיים ולכלול קו יחסי
הפניות למספרים, למשל:

// CHECK: test.cpp:[[@LINE+4]]:6: error: צפוי ';' אחרי מצהיר ברמה העליונה
// CHECK-NEXT: {{^int a}}
// CHECK-NEXT: {{^ \^}}
// CHECK-NEXT: {{^ ;}}
int a

השתמש ב- FileCheck-3.6 באופן מקוון באמצעות שירותי onworks.net